Följande innehåll är hämtat från det populära whitepaperet "Agile Project Management: Vad är historien?" skriven av Jerry Manas. Den är så god att vi ville göra den gratis för våra läsare och ge den ett evigt liv på vår blogg för din skull.
Innan du läser vidare rekommenderar vi att du läser del ett av denna serie om varför du bör anta en samarbetsbaserad och iterativ strategi.
Agilitet är ett helt annat sätt att tänka, och därför är terminologin också annorlunda, vilket inte är förvånande. Nedan följer en sammanfattning av hur Agile fungerar, tillsammans med relevant terminologi:
- Funktioner definieras i berättelser , som identifierar användare, åtgärder och fördelar för funktionen (som en analogi kan man tänka på berättelser i skönlitteratur: de omfattar karaktär, handling och motiv).
- Användarberättelser uppskattas i relativa poäng (även om vissa organisationer använder idealiska dagar). Story Points är ett mått på relativ komplexitet och ansträngning. När arbetet slutförs kan teamet "tjäna" poäng för de färdiga berättelserna.
- Användarberättelser prioriteras så att de mest värdefulla funktionerna eller de som möjliggör funktionerna levereras så snart som möjligt. Teamet arbetar tillsammans med prioriterade berättelser från en backlog i iterationer med bestämd tid, vanligtvis 1 till 4 veckor långa (i Agile Scrum-metodiken, som är populär inom programvaruutveckling, kallas dessa iterationer för sprintar ).
- Teamet träffas regelbundet för att utbyta information och framsteg. I den agila Scrum-metodiken är detta dagliga 15-minuters standup-möten. Nyckeln är att hålla sig borta från gräset. Det finns inga möten för att lösa problem.
- Efter varje iteration/sprint träffas teamet och intressenterna för att bedöma framstegen, göra justeringar och planera nästa steg (dvs. evolutionär planering). Detta kallas ofta retrospektivt . Den skiljer sig från den traditionella granskningen efter genomförandet, som vanligtvis görs långt efter projektet och alldeles för sent för att göra någon skillnad för det aktuella projektet.
- Framstegen följs upp via burndown diagram, som visar det arbete som återstår över tiden (i form av planerade story points jämfört med uppnådda story points).
- Velocity mäter de story points som avslutas per iteration/fjäder (dvs. hastigheten med vilken värdet levereras).
En produktutgåva består i allmänhet av flera iterationer/utgåvor. Ofta finns det en planeringsprint i början av varje utgåva för att planera berättelserna för den utgåvan.
Agila roller
I agila projekt måste projektledarens roll omprövas. Detta beror på att:
- Baslinjer är irrelevanta - En baslinje är meningslös om hela konceptet med Agile är att planera och anpassa funktionerna så att de passar in i iterationer med fast tid och kostnad.
- Formella krav i förväg gäller inte - Kundernas behov måste förstås, men detaljerade krav är inte alla fastställda i förväg; kraven utvecklas med lärdomar från varje sprint.
- Djävulen ligger i detaljerna - Agila projekt lyckas eller misslyckas tack vare ömsesidig förståelse för kundens behov och tekniska kapacitet. Ledare för agila projekt måste därför förstå detaljerna.
- Allt handlar om produkten - Till skillnad från traditionella projekt, där fokus ligger på att hantera omfattning, tidsplan och budget, handlar agila projekt om produkten och inte om projektet. Poster som tidsplan och budget är fastställda.
- Agila projekt är gemenskapsdrivna - I agila projekt kommunicerar utvecklare, analytiker, produktägare och kunder ständigt med varandra. Om de inte gör det, följs inte den agila metoden. Till skillnad från traditionella projekt är projektledaren inte den primära kommunikationskällan.
- Agila projekt har relativt låg risk - Om det rör sig om ett stort, komplext projekt med många involverade team och rörliga delar är det inte säkert att Agile är det bästa sättet att arbeta. Agilitet används ofta inom programvaruutveckling och andra kunskapsbaserade projekt som kan tåla någon form av tolerans för osäkerhet och där ett enskilt team kan arbeta i snabb takt.
Med allt detta i åtanke kan vissa ställa den oundvikliga frågan: Vad har då en projektledare att göra? Det är en berättigad fråga, och organisationer har valt olika tillvägagångssätt, från att inte ha någon projektledare alls till att använda projektledaren som en förmedlare mellan produktägaren, kunderna och utvecklarna. I vissa organisationer fungerar Scrum Master som projektledare.
Nedan beskrivs typiska roller i ett agilt projekt:
- Product Manager/Owner - fastställer produktvisionen och ser till att de funktioner som anges i backloggen prioriteras och förstås; tillhandahåller användarberättelser (användare/åtgärder/fördelar).
- Kund - övervakar utvecklingen och ger input för värdefulla leveranser (Obs: Produktchefen fungerar vanligtvis som kundens ombud när det gäller att elektroniskt registrera kommentarer och input).
- Development Manager/SCRUM Master/Project Manager - fyller på sprintar från projektets backlog och uppdaterar story points baserat på planering av sprintar; underlättar dagliga möten och sprintdemonstrationer.
- Utvecklare - tilldelas berättelser och gör testanteckningar mot berättelser; rapporterar ansträngning för kostnadsspårning.
- Resource Managers - optimera resursutnyttjandet i flera projekt och se till att resurserna finns tillgängliga i kritiska projekt.
- QA/QE Manager/Testers - fokuserar på kvalitetssäkring/teknik, inklusive processförbättringar, testning och mätning.
Har du fyllt dessa roller i din organisation? Det kan ta tid att anpassa sig till detta tankesätt, särskilt om det är nytt för era team, men fördelarna är värda alla problem. Besök https://www.planview.com/lean-agile-delivery/ för att lära dig hur våra lösningar kan hjälpa din organisation att anpassa sig, och registrera dig för en kostnadsfri demo av vår lösning Lean and Agile Delivery för att själv uppleva fördelarna. I den sista delen av den här serien kommer vi att undersöka de farhågor som många människor har när de byter till en agil metodik.
