Scrum

Generellt upplägg för Scrum.

 Kräver:

En produktägare/productowner

En scrum-master/projektledare

Ett team

Först behövs ett mål/produkt. Hur ska denna produkt se ut? Den information samlas in från produktägaren, användarundersökningar, chefer etc – från relevanta källor med andra ord. Alla önskningar/features hamnar i en product backlog, som helt enkelt är en samling för features. Exempelvis, om spelet vore Super Mario Bros, skulle en product backlog se ut såhär:

Product Backlog för Super Mario Bros:
En huvudkaraktär som kan hoppa.
En story.
Karaktärsdesign.
Programmering om hur en eldblomma fungerar.
Slutgiltig design på eldblomma.
Ett automatvapen för Mario.
Hur upplägget på banorna ser ut.
Betatestning.

Sedan sker en prioritering kring vad som är nödvändigt för produkten och hamnar i något som kallas för release backlog. Nu är det så att Mario aldrig har något automatvapen, men vem vet om det fanns förslag på det som feature från exempelvis en betatestare? Huvudsaken är att det som är mest relevant prioriteras och produktägaren stryker eventuellt det som inte ska vara med – kort sagt, produktägaren säger vad som inte ska vara med, och vad som ska vara det. Förutom prioritering så schemalägger man hur lång tid varje funktion tar. För att schemalägga funktioner, kräver det givetvis att man frågar rätt kompetens, för rätt estimat. Gruppen räknar ut antal timmar/storypoints som krävs för att göra klart varje uppgift i varje sprint. Målet är att varje sprint ska ha samma mängd arbetstimmar/storypoints. Storypoints just här, kan eventuellt vara att föredra, eller liknande, som avser ett jämförelseestimat istället för specifik tid.

Release backlog för Super Mario Bros.
1. Huvudkaraktär som kan hoppa.
2. Karaktärsdesign.
3. Hur upplägget på banorna ser ut.
4. Programmering om hur en eldblomma fungerar.
5. Slutgiltig design på eldblomma.
6. Betatestning.
7. En story..

Scrummaster har sedan koll på tidsestimat, schemaläggning, möten samt att se till att teamet som arbetar på uppgifterna har vad som krävs för att dessa skall vara självgående så bra som möjligt. En scrummaster kallar även in teamet för Daily Scrum (dagliga korta möten) där man går igenom gårdagens effektivitet, vad som ska göras idag samt om några problem existerar.

Efter det så delas release backloggen upp i sprints/etapper. Som handskas efter prioritering. I det här exemplet kan vi förutsätta att varje feature är värd 10 storypoints (vilket jag tar upp längre ner). T.ex:

Sprint 1.
Feature 1. Huvudkaraktär som kan hoppa. =  10 storypoints
Feature 2. Karaktärsdesign. = 10 storypoints, osv..

Sprint 2.
3. Hur upplägget på banorna ser ut.
4. Programmering om hur en eldblomma fungerar. 

Sprint 3.
5. Slutgiltig design på eldblomma.
6. Betatestning.

Sprint 4.
7. En story.
8. Avsatt tid för att fixa buggar/stabilisering.

 

En sprint är mellan 3-30 dagar. Varje sprint ska vara testad och leveransklar när den är färdig. För att hålla kolla på arbetet använder scrummaster en s.k. burndown chart som i grund och botten är ett diagram som sakta men säkert ska smälta neråt efter progressen i arbetet, efter specifika tidsestimatet. Med hjälp av detta diagram, kan man på sätt och vis förutspå när målet kommer att nås, beroende på hur många timmar som ”bränner” ner varje dag. Hur många timmar som bränns ner varje dag ändras och uppdateras kontinuerligt av teamet. Buggar som stöts på i en sprint, ska avhandlas omedelbart innan man kan säger att sprinten är färdig. Dessutom kan det vara bra med specifika sprints, endast för att ta bort buggar.

Efter varje sprint, vet alla inblandade exempelvis: “vi klarade 3 av 4 uppgifter vilket är lika med 15 av 20 storypoints”, och kan därefter omvärdera nästa sprint, att klara 15 storypoints, istället för 20 stycken – för ett mer säkert resultat. Velocity är med andra ord estimatet om vad gruppen tror sig klara av efter en sprint.

Källa: http://agilefaq.wordpress.com/2007/11/03/what-is-velocity-in-a-scrum-team/
http://www.versionone.com/Agile101/velocity.asp

Stående möten, på daily scrums är att föredra (typ 15 minuter), då det är jobbigt att stå upp, och folk vill hellre börja jobba, än att ha ont i benen. Bör införas straff om folk är försenade till de högt prioriterade daily scrums, är bra om medarbetaren då böter en peng. Det svider, men viktigt att folk förstår innebörden av att vara med i den dagliga statusuppdateringen.

Källa: http://www.youtube.com/watch?v=Q5k7a9YEoUI&feature=player_embedded

Övrigt:
Scrum har applicerats sedan tidigt 90tal, kommer från sporten rugby (som är momentet när bollen sätts i spel) och är skapat av Jeff Sutherland & Ken Schwaber. Går att likna scrum vid rugby, precis som ett rugbylag sakta gör progress framåt med bollen.

Källa: http://www.mountaingoatsoftware.com

Kritik mot Scrum: http://www.idg.se/2.1085/1.187182/kritiken-mot-scrum-vaxer

Tydligen verkar folk som använder Scrum undvika just återblickar, sprint reviews, där man utvärderar arbetet. Detta medför ett direkt problem, då återblickarna måste vara där, för att se vad som kan effektiviseras, och hur det kan effektiviseras. Eftersom det i princip kräver en återblick/utvärdering var tredje vecka, är det tämligen dödligt för ett längre projekt, om arbete inte effektiviseras.