Igår kom mitt första inlägg på
Projektbloggen upp. Det är en omskrivning av en artikel jag skrev 2007.
---------------------------------------------------
Scrum sägs vara en enkel metod för att hantera komplexa projekt. Det stämmer väldigt bra. Grunderna i Scrum är enkla att beskriva och enkla att förstå. Svårigheten är kanske att veta hur man ska använda den i ett verkligt projekt. Hur använder man Scrum i en organisation som annars kanske jobbar enligt vattenfallsmetoden? Hur anpassar man sig till en organisation som har en fungerande releasehantering enligt t.ex. ITIL?
En del i enkelheten i Scrum är att det bara finns tre olika roller: Scrum master, produktägare och utvecklare.
• Scrum mastern ansvarar för att processen följs och agerar mentor eller coach till teamet och produktägaren.
• Produktägaren är den person som prioriterar kraven efter affärsvärde och styr vad som ska utvecklas i produkten eller systemet.
• Utvecklare är medlemmarna i teamet som ansvarar för att leverera. Det spelar ingen roll om din expertis är inom programmering, arkitektur eller test, i Scrum benämns du ändå som utvecklare.
Sprintar All utveckling inom Scrum sker inkrementellt i iterationer som kallas för sprintar. Längden på en sprint är individuell men mellan 14 och 30 dagar. I början av projektet kan man experimentera med olika sprintlängder. Det är dock viktigt att sedan bestämma sig och hålla sig till samma sprintlängd. Anledning till att jag tycker att man ska hålla en given sprintlängd är för att man vill ge teamet en känsla över hur långt man ska ha kommit efter en viss tid in i sprinten. Det underlättar också när man estimerar då man enklare kan använda sig av teamets hastighet.
Den första dagen i en sprint spenderar teamet tillsammans med produktägare och Scrum master för att komma fram till vad teamet ska leverera när sprinten är slut. Dagen är uppdelad på två möten, ett där teamet och produktägaren förhandlar om innehållet och ett där teamet tidsuppskattar och bryter ned kraven till uppgifter. Efter dag ett lämnar Scrum över kontrollen till teamet och kräver bara att en gång per dag få status om hur projektet går. Detta sker genom ett dagligt möte som varar max 15 minuter där teamet lämnar status till varandra om hur arbetet fortskrider.
Nu ska teamet börja jobba. Klockan tickar… Bara 29 dagar kvar till en potentiellt levererbar produkt ska vara klar. Vad ska vi göra nu? Hur ska vi kunna leverera den kvalitet som förväntas? Hur ska vi kunna testa den här funktionen som har beroende mot andra externa system som vi inte har tillgång till? Frågorna hopar sig och som sagt… tick tack, tick tack...
Fokus och ostördhetI det här läget är det många som tar hjälp av eXtreme Programming för att t.ex. få till automatiserade byggen, enhetstester och kontinuerlig integrering. Scrum säger väldigt lite om vad som händer i sprinten, utan betonar att teamet ska lämnas ostört och få möjlighet att fokusera på leveransen. Scrum och XP fungerar väldigt bra tillsammans även om XP i sig är en helt komplett metod. Det som skiljer XP från många andra agila metoder är att den ger väldigt många rekomendationer till vad teamet kan göra under en iternation.
UtbildningarPå marknaden idag finns det en del utbildningar som riktar sig mot Scrum masters men få som riktar sig mot utvecklare i ett Scrum-projekt. Då menar jag inte själva utvecklingen i C#, VB.NET eller Java, utan snarare vad man kan göra för att förbättra kvaliteten och öka produktiviteten i leveranserna. För just produktivitet betonas väldigt tydligt i Scrum.
Ett exemple på en sådan utbildning är Scrum i Praktiken på Addskills. Den kursen riktar in sig mot just teammedlemmar i ett Scrum-projekt. Första dagen handlar om Scrum och om estimering och andra dagen handlar om practises från XP.
Själv gick jag min Scrum Master-utbildning på Citerus i Uppsala med Tobias Fors och Mikael Lundgren och det var en helt fantastisk kurs som jag varmt kan rekomendera.
Någon som har gått eller sett någon annan utbildning i Scrum som inte är någon av de officiella Certified Scrum *-utbildningar?