Smidig systemutvikling og innføring i Scrum Forelesning, Systemutvikling 22. januar 2008 Torgeir Dingsøyr Førsteamanuensis II, IDI, NTNU 1
Agenda Smidig utvikling Hva er smidighet Hvilke metoder finnes Balansere smidighet og disiplin Innføring i Scrum Hva er Scrum Prosessmodell og roller i Scrum Roller i Scrum Artefakter i Scrum Prosesser i Scrum 2
Tilpasning av utviklingsmodell Personnel (% Level 1B) (% Level 2&3) 40 15 30 20 20 25 Criticality (Loss due to impact of defects) 10 30 Dynamism (% Requirements-change/month) Many Lives Single Life Essential Funds 0 Discretionary Funds Comfort 35 50 30 10 5 1 3 90 Agile Disciplined 10 70 30 50 100 30 Size (# of personnel) Kilde: Cockburn, gjengitt i Boehm & Turner, 2003 300 10 Culture (% thriving on chaos vs. order) 3
Life cycle support (smidige metoder) New directions on agile methods: a comparative analysis: Abrahamsson, P.; Warsta, J.; Siponen, M.T.; Ronkainen, J.; Software Engineering, 2003. Proceedings. 25th International Conference on Software Engineering, May 2003 Page(s):244-254 4
Praksiser i ekstremprogrammering (XP) The Planning Game Small releases Metaphor Simple design Testing Refactoring Pair programming Collective ownership Continuous integration 40-hour-week On-site customer Coding standards Beck, K., Extreme Programming Explained. 2000: Addison-Wesley. 190 pages. 5
Scrum 6
Scrum En metode for prosjektstyring og prosjektkontroll Viktige konsepter er: Kontinuerlig utvikling av kravforståelsen Kunden/brukeren er en viktig aktør Inkrementell utvikling av resultatet Ekstremt høy synlighet av Progresjon/status på resultat Ressurssituasjonen Problemer/hindringer 7
The New New Product Development Game Six pieces in a jigsaw puzzle: Built-in instability Self-organizing teams Overlapping development fases Multilearning Subtle control Organizational transfer of learning Teamet får en tøff utfordring, men også stor frihet i hvordan den løses. Teamet er selvstyrt, kan se bort fra tradisjonelle løsninger, og søke kunnskap på tvers av fagområder. Overlappende faser forbedrer samarbeid, sprer kompetanse og forbedrer ressursutnyttelse, men kan også komplisere eksterne avhengigheter. Spredning av erfaringer i organisasjonen ved å bruke folk i nye prosjekter. Ledelsen avgir direkte kontroll, men får egenkontroll, gruppekontroll og annen subtil kontroll gjennom å opptre støttende og belønne teamets resulater. Siden teamet selv må søke informasjon for å finne svaret på utfordringen vil læring foregå mellom organisasjonsnivåer og ulike funksjoner. Kilde: Kjetil Jørgensen Dahl, NOS Clearing ASA 8
Scrum origins Scrum Jeff Sutherland Initial Scrums at Easel Corp in 1993 IDX and nearly 600 people doing Scrum Not just for trivial projects FDA-approved, life-critical software for x-rays and MRIs Ken Schwaber ADM Initial definitions of Scrum at OOPSLA 96 with Sutherland Mike Beedle Scrum patterns in PLOPD4 Kilde:Introduction to Scrum, Mountain Goat Software 9
Tilpasning Scrum må tilpasses settingen den skal brukes i! Laget for profesjonelle utviklere som bruker mesteparten av tiden i et prosjekt 10
Scrum prosessmodell Kilde: www.controlchaos.com 11
Elementer i Scrum Prosesser Sprint Planning Meeting Sprint Daily Scrum Meeting Sprint Review Meeting Sprint Retrospective Meeting Artifakter Vision Product Backlog Sprint Backlog Burndown Chart Roller Product Owner Scrum Team ScrumMaster (Stakeholders) Kilde: Kjetil Jørgensen Dahl, NOS Clearing ASA 12
Project team in a daily stand-up meeting Customers and project managers working together 13
Roller i Scrum Product owner Definerer hvilke features et produkt skal ha Prioriterer features Kan akseptere eller forkaste resultater Scrum master Ansvar for at teamet fungerer Tar tak i problemer og sørger for løsning Skjermer teamet fra forstyrrelser Teamet Kryssfunksjonelt, lite team Selvorganiserende Viser resultater til product owner 14
Artefakter i Scrum Vision - visjon for produktet (hva skal stå på boksen programvaren kommer i?) Product backlog en prioritert liste med alle krav. Oppdateres hele tiden av en product owner. Sprint backlog scrum-teamets egen liste over hva som skal gjøres i denne sprinten. Burndown chart - graf over gjenstående tid på oppgavene i sprinten. 15
A sample product backlog Backlog item Estimate Allow a guest to make a reservation 3 As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a reservation. 3 As a hotel employee, I can run RevPAR reports (revenueper-available-room) 8 Improve exception handling 8... 30... 50 Kilde: Mountain Goat Software 16
A sprint backlog Tasks Mon Tues Wed Thur Fri Code the user interface 8 4 8 Code the middle tier 16 12 10 4 Test the middle tier 8 16 16 11 8 Write online help 12 Write the foo class 8 8 8 8 8 Add error logging 8 4 Kilde: Mountain Goat Software 17
A sprint burndown chart Hours Kilde: Mountain Goat Software 18
Tasks Code the user interface Code the middle tier Test the middle tier Write online help Mon 8 16 8 12 Tues Wed Thur Fri 4 8 12 10 7 16 16 11 8 50 40 Hours 30 20 10 0 Mon Tue Wed Thu Fri 19
Prosesser i Scrum Sprint planning Daily Scrum Sprint Review Sprint Retrospective 20
Team capacity Product backlog Business conditions Current product Technology Sprint planning meeting Sprint prioritization Analyze and evaluate product backlog Select sprint goal Sprint planning Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours Sprint goal Sprint backlog Kilde: Mountain Goat Software 21
Sprint planning Team selects items from the product backlog they can commit to completing Sprint backlog is created Tasks are identified and each is estimated (1-16 hours) Collaboratively, not done alone by the ScrumMaster High-level design is considered As a vacation planner, I want to see photos of the hotels. Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4) Kilde: Mountain Goat Software 22
Brukerhistorier Mange skriver brukerhistorier på kort Kort: Som en <rolle> ønsker jeg <funksjon> slik at <mål> Fordel mer fysisk kort Synlighet. Kan henges på vegg. Kan flyttes for å markere prioritering. Lett å legge til info Testkriterier Tidsestimat Tid brukt 23
Kort Kilde: Helen Sharp: Collaboration and Co-ordination in mature XP teams 24
Vegg Mange bruker en vegg hvor de henger opp brukerhistorier Kortene grupperes etter: Ikke startet Under arbeid Ferdig Dersom man ikke har mulighet til å ha kort hengede på en vegg går det an å bruke en flip-over som man ruller sammen etter arbeidsøkten 25
Konkretisering over tid Kilde: Nils Christian Haugen: Brukerhistorier, innlegg på dataforeningen-faggruppe Smidig utvikling, 13. November 2007. 26
Daily scrum Parameters Daily 15-minutes Stand-up Not for problem solving Whole world is invited Only team members, ScrumMaster, product owner, can talk Helps avoid other unnecessary meetings Kilde: Mountain Goat Software 27
Everyone answers 3 questions What did you do yesterday? 1 What will you do today? Is anything in your way? 2 3 These are not status for the ScrumMaster They are commitments in front of peers Kilde: Mountain Goat Software 28
The sprint review Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal 2-hour prep time rule No slides Whole team participates Invite the world Kilde: Mountain Goat Software 29
Sprint retrospective Periodically take a look at what is and is not working Typically 15 30 minutes Done after every sprint Whole team participates ScrumMaster Product owner Team Possibly customers and others Kilde: Mountain Goat Software 30
Start / Stop / Continue Whole team gathers and discusses what they d like to: Start doing Stop doing This is just one of many ways to do a sprint retrospective. Continue doing Kilde: Mountain Goat Software 31
Scrum oppsummering 32
Verktøy Mange kommersielle prosjektstyringsverktøy som følger scrum Freeware: ScrumWorks Basic 33
34
Referanser Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm and Richard Turner 35
Referanser Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J. Agile software development methods - Review and analysis. VTT Publications 478, VTT Electronics, 2002. Boehm, B., Get Ready for Agile Methods, with Care, in IEEE Computer. 2002. p. 64-69. Cohen, D., M. Lindvall, and P. Costa, An Introduction to Agile Methods, in Advances in Computers, Advances in Software Engineering, M.V. Zelkowitz, Editor. 2004, Elsevier: Amsterdam. Dybå, T. and T. Dingsøyr, Empirical Studies of Agile Software Development: A Systematic Review. Submitted to Information and Software Technology, 2008. Nerur, S., R. Mahapatra, and G. Mangalaraj, Challenges of migrating to agile methodologies. Communications of the ACM, 2005. May: p. 72-78. Takeuchi, H. and Nonaka, I. The New New Product Development Game. Harward Buisiness Review, (1986) www.agilealliance.org www.agilemanifesto.org www.extremeprogramming.org www.controlchaos.com 36