SCRUM och agil utveckling Johan Åberg johan.aberg@liu.se
Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Agile Manifesto, 2001
Scrum Projektledningsmetod för agil programutveckling Egenskaper Levande backlog av features Korta iterationer eller sprints Kort dagligt möte, sk Scrum-möte Kontinuerlig processförbättring, sk retrospectives
Sprint
Roller Scrum team Litet självorganiserande team som utför utvecklingsarbetet Fullständig auktoritet att ta nödvändiga åtgärder för att uppnå åtagandena ca 7 personer inklusive analytiker, designer, kvalitetsansvariga, programmerare
Roller Utvecklare Programmerar Testar
Roller Produktägare Representerar kunden och styr mot affärsperspektivet Administrerar product backlog Är ofta en kund, men kan vara en del av den interna organisationen Rollen kräver kunskap om engineering, marknadsföring, och affärsprocesser
Roller Scrum master En kombination av coach & fixare Träffar teamet dagligen i Scrum möten Försöker få scrum teamet att kunna jobba i lugn & ro Fokuserar alltid på att ge teamet bästa möjliga förutsättningar för att uppnå målen med sprinten Efter varje sprint håller scrum master ett utvärderingsmöte med teamet sprint retrospective
Dokument Product backlog Högnivådokument för hela projektet Innehåller övergripande beskrivningar av alla nödvändiga features, önskelistefeatures etc Är öppen och editerbar av alla Innehåller grova tidsuppskattningar, i dagar
Dokument Sprint backlog Detaljerat dokument om hur teamet ska implementera kraven för kommande sprint Tasks bryts ner i timmar, med en maxgräns på 16h Ingen tilldelas tasks i sprint backlog, teammedlemmarna väljer själva
Lappar för user stories & tasks
Scrum board Ritas på whiteboard Burn-down chart Speglar återstående tid för sprintens tasks Progresstabell Rader En rad per user story Kolumner Not Started Started Ready for Review Done
Burn down chart 49 25 x x x x x Varje x markerar uppskattade totaltiden för ingående tasks som ännu ej slutförts under sprinten. x prickas i efter varje scrum-möte. x x x x 0 x
Progresstabell Not Started Started Ready for Review Done
Steg i processen Sprint 0 Före sprint start Sprint start Dagligt scrum-möte Sprint end Demo Retrospective
Sprint 0 Kick off Bekanta sig med projektet Designarbete Teknik-spikes Kom överens med kund Kommunikationsrutiner, etc Upprätta scrum board
Före sprint start Scrum master Uppdatera backlog Se till att material finns Whiteboard pennor, postits, Kund/teamet Förbered nya user stories Placera i backlog Kund Prioritera user stories i backlog Teamet Tidsuppskatta user stories i backlog
Sprint start Teamet Välj ut user stories i prioriteringsordning Totaltiden ska matcha tillgänglig tid Bryt ner user stories i tasks Tidsestimera alla tasks med Planning Poker Kund Finns tillhands för frågor Scrum master Placera alla lappar på scrum board User stories Tasks Rita upp ny burn-down chart Teamet Börja utveckla!
Beräkning av tillgänglig tid för stories Tillgänglig tid: 35h/pers/sprint Antal pers: 4 Parprogrammering 2 par Velocity: 70% Tillgänglig tid: 35h/pers/sprint Antal pers: 5 Parprogrammering 3 par Velocity: 70% Total tillgänglig tid för stories? (35*2) * 0.7 = 49h Total tillgänglig tid för stories? (35* 3) * 0.7 = 73.5h
Planning poker Alla i teamet estimerar en story/task Väljer ett kort/skriver en siffra Alla visar upp sitt val samtidigt Den som valt minst tid och den som valt mest tid diskuterar och enas om en estimering Finns varianter
Progresstabell Not Started Started Ready for Review Done
Burn down chart 49 25 x x x x x Varje x markerar uppskattade totaltiden för ingående tasks som ännu ej slutförts under sprinten. x prickas i efter varje scrum-möte. x x x x 0 x
Dagligt Scrum-möte Mötesriktlinjer Startar exakt i tid, med överenskomna straff för försening Max 15 minuter oavsett teamstorlek All deltagare står upp, scrum master leder Alla utvecklare Vad har du gjort sedan förra mötet? Vad åtar du dig till kommande möte? Är det något som hindrar dig i ditt åtagande? Alla utvecklare Uppdaterar tidsuppskattningen för pågående tasks Scrum master Uppdaterar burn-down chart Hanterar avvikelse, t.ex. kontakt med kund
Sprint end - demo Teamet Demar systemet för kundens representant Kunden Gör accept/reject på sprintens user stories Scrum master Justerar user stories som fått reject, lägger i backlog
Sprint end - retrospective Ca 1 timme Scrum master Gå igenom sprinten Teamet Skriv post-its med plus & delta Scrum master Gå igenom alla post-its Gruppera och sätt upp på whiteboard Led diskussionen Teamet Rösta om viktigaste delta Scrum master Välj tre viktigaste delta Sätt upp på scrum board Scrum master Räkna ut velocity Räkna ut total tillgänglig tid för nästa sprint
Beräkning av velocity Tillgänglig tid för stories, ej inräknat velocity 70h Uppskattad totaltid för godkänd stories 38h Velocity 38/70 = 0,54 (54%) Tillgänglig tid för stories, ej inräknat velocity 105h Uppskattad totaltid för godkända stories 38h Velocity 38/105 = 0,36 = (36%)
Agila metoder Möjligheter Fokus på förändring och processförbättring Kundinvolvering Löser problem med vattenfallsmodellen Kravspecar alltid fel Designarbete tidigt och sedan ej förändringsbart Slutanvändaren bortglömd Risker Programmerarcentrerat ID och användbarhet en sidoeffekt av kodandet -> går emot 30 års erfarenhet av UCD Helheten tappas bort -> lapptäcke Kund = användare?
Böcker Litteratur Pieter Jongerius et al. Get Agile! Scrum for UX, design & development. BIS Publishers, 2013. Henrik Kniberg. Lean from the Trenches. The Pragmatic Programmers, 2011. Forskningsartiklar Williams, L., Kessler, R.R., Cunningham, W., Jeffries, R. Strengthening the case for pair programming, IEEE Software, 17(4), pp. 19-25, 2000. Jones, D.L., and Fleming, S.D. What use is a backseat driver? A qualitative investigation of pair programming. In Proceedings pf the IEEE Symposium on Visual Languages and Human-Centric Computing, pp. 103-110, 15-19 September, 2013. Kai Stapel, Eric Knauss, Kurt Schneider, and Matthias Becker. Towards Understanding Communication Structure in Pair Programming. In Agile Processes in Software Engineering and Extreme Programming, Lecture Notes in Business Information Processing Volume 48, pp. 117-131, 2010. Kjetil Molokken-Ostvold, Nils Christian Haugen, Hans Christian Benestad. Using planning poker for combining expert estimates in software projects, The Journal of Systems and Software 81, pp. 2106-2117, 2008. Siva Dorairaj, James Noble, and Petra Malik. Understanding Team Dynamics in Distributed Agile Software Development. In Agile Processes in Software Engineering and Extreme Programming Lecture Notes in Business Information Processing Volume 111, pp. 47-61, 2012.
Frågor?