Det agila manifestets fyra hörnstenar
– Värdera individer och interaktion, högre än processer och verktyg.
– Värdera fungerande mjukvara, högre än omfattande dokumentation.
– Värdera samarbete med kunden, högre än att förhandla kontrakt.
– Värdera att reagera på förändringar, högre än att följa en uppgjord plan.
Här är elva bra exempel!
Omplanering är omöjligt att undvika.
Att inse det omöjliga i att skapa den perfekta planen reducerar nervositeten som ett sådant mål medför. Vad man däremot kan göra är att skapa en andvändbar plan som fungerar då.
Klicka för en större bild!
Estimera storlek och innehåll separat.
En vanlig brist i planeringen, både i traditionella och agila team är att blanda ihop esimeringen av storlek med innehåll. Storlek och innehåll är olika saker, ser man en tjock bok kan man utgå ifrån dess storlek att den kommer ta lång tid att läsa, men du vet inte förrän du har öppnat den och läst några sidor. Kanske har boken väldigt liten text, eller kanske väldigt stor text? Kanske är den full med svåra ord eller saker som man måste läsa två gånger för att riktigt förstå?
Storlek och tid är givetvis relaterade, men det är extremt svårt att estimera när ett projekt blir färdigställt baserat endast på dess antydda storlek, det tillkommer alltid förändringar i planen.
Planer skapas på olika nivåer.
Agila planeringar täcker tre olika nivåer, release-datumet, iterationen (fasen) och den nuvarande dagen. Detta har två födelar, för det första klargör det att varje plan är utformad för ett enskilt syfte. Den dagliga planen är förpliktigad i de involverade i gruppen och är ganska precis. Den itera planen är inte så specifik eftersom den utvecklas i och med kundens önskemål och dialogen med kunden. Slutligen, release-datumet är det minst precisa av allt, den innehåller endast en lista med prioriteringar baserad på användarkrav och en eller flera estimerade utskrifter om sannolikheten kring den önskade varans release.
En annan fördel med att planera på olika nivåer är att det hjälper teamet att se projektet från flera perspektiv, skulle ett team arbeta sig igenom fas efter fast utan att se till helheten och det stora slutgiltiga målet är det stor risk att haka upp sig på detaljer. Detaljer är sådant som vi kan ta bort utan att det kommer påverka produkten i sig, tillägg helt enkelt.
Planer baserade på egenskaper, inte uppgifter.
En agil plan fokuserar på de grundläggande dragen till en produkt istället för att snöa in sig på detaljer, i och med att grunden läggs det vill säga fokus på de ‘’stora’’ detaljerna betyder det att det sedan blir enklare att peka ut detaljerna som förklarar produkten som helt färdig efter kundens slutgiltiga förfrågan. Egenskaperna är det som fulländar produkten, du kan inte skapa en skog av enbart kvistar och löv, däremot kan du gärna lägga till kvistarna och löven när du väl har dina träd.
Små processer håller igång arbetet.
Cykeln är den tid det tar för en prdukt att röra sig från början av en process till slutet av en process. För ett mjukvaru företag är cycleln den tid det tar för teamet att börja använda på en funkttion till det att den är ‘’användarvänlig’’.
Ombytligheten är en nyckelfaktor i utvecklingen av en programvara, ett av sätten för att reducera denna osäkerhet är att dela upp arbetet i små och ungefär lika stora delar.
Arbetsuppgifter blir eliminerade för varje ny fas.
Stora mängder arbete i omlopp bromsar gruppens process. I ett mjukvaru-projekt existerar ‘’arbete i process’’ i varje del som gruppen har startat på men som inte är slutförd, ju mer arbete som är i process här desto längre tid kommer det ta för nästa del att utvecklas, detta eftersom de är beroende av varandra. Tänk ett torn, det kan inte stå utan grund. Detta är en av anledningarna till att agilt arbetssätt är så effektivt, nämligen att arbete i process elimineras efter varje iteration.
Målföljning sker på teamets nivå.
Traditionella tillvägagångsätt till att estimera och planera mäter ut och belönar varje enskild medlems process på dennes nivå, detta leder till en hel del problem. Ett av dessa är att om att en uppgift klaras av tidigt kommer detta resultera i att personen i fråga blir anklagad för att ha gett en otillräcklig estimering av uppgiften vilket i sin tur leder till att denne inte kommer att lämna in arbete för tidigt i framtiden utan vänta tills deadline. Agil estimering och planering är framgångsrikt när det gäller just detta eftersom gruppens totala progress är i fokus och inte individens, detta kommer också minska sannolikheten att enskila individer blir utbrända. Genom att ha hela teamet arbetandes koordinerat och synkat blir det också enklare att estimera sluttiden för målet istället för att behöva estimera målet utifrån varje enskild individs process. Detta förutsätter förstås att gruppen arbetar i en jämn takt och att ingen tar sig an några speciella uppgifter under den fasen i arbetet.
Obestämdhet vidkänns och planeras in.
Många traditionella, normativa planer gör misstaget att tro att arbetets olika faser kan bli säkrade och låsta så fort de är klara, detta är fel eftersom man senare kan upptäcka att dessa ‘’avklarade’’ delar är antingen ouppdaterade eller oönskade. När vi skapar en plan tidigt i ett projekt och inte uppdaterar den låser vi oss för eventuella förändringar vilket i sin tur gör att vi tappar verklighetsförankringen i planen, detta kan leda till att slutprodukten inte alls blir som vi eller kunden önskat.
Leverera något i varje fas.
Ett bra exempel finns i programvarubranschen. Viktigare än att varje fas bästämda längd är att teamet har omvandlat flera (även oprecisa) kravfaktorer till färdigställd och potentiellt transportbar vara.Teamen kommer inte behöva leverera resultat till sina användare i varje fas, men man strävar mot att kunna göra det. Detta betyder i sin tur innebära att teamen kommer att göra framsteg baserade på att lägga till små inslag till sina redan existerande dock färdigställda grunder (vad de måste se till är dock att varan alltid är redo för release).
Granska och anpassa.
Agila team ser varje förändring som något som erbjuder både en möjlighet att updatera sin plan och att ge en bättre uppfattning om nuvarande situationen, reaktionen är dock annorlunda från team till team, vissa är betydligt uppmärksamma än andra.
Kundsamarbete.
Agila team demonstrerar åtaganden till arbetsprioriteringar på två sätt, det första är att leverera delar av produktbeställningen i den specifierade ordningen angiven av produktägaren, som i sin tur förväntas prioritera och kombinera dessa delar i ett releasedatum som optimerar återbäringen i organisationens investering av projektet. Här är det viktigt att försöka ge produktägaren så kompletta varor som möjlig, speciellt när de är beroende av varandra för att fungera, detta är dock givetvis inte alltid möjligt.
För det andra fokuserar agila team på att färdigställa och leverera användarvänliga uppgifter mer än att färdigställa enskilda uppgifter (som senare hade blivit användarvänliga sådana ). Ett bra sätt att beskriva dessa är att göra så kallade ‘’användarberättelser ‘’, en kort samanfattning om funktionaliteten som den uppfattas av användaren eller kunden till systemet. Detta är dock inte en obligatorisk sammanställning av en användarberättelse;
“Som en <typ av användare>, vill jag kunna <kapacitet> så att jag kan <projektets mål>.
Exempel: ”Som den boknörd jag är vill jag kunna söka efter en böcker med Hitta-Bok.se så att jag kan hitta rätt bok snabbt.”
Anpassa de olika inslagen i processen. Det är lättare att planera i korta drag än i långa.
Prioritera i planeringen, arbeta på de grundläggande faktorerna i projektet först för att nå den totala standarden i projektet så snart som möjligt. Ska du bygga ett hus är det fördelaktigt att ha grunden klar först!
Basera alla beräkningar på fakta om verkligheten och nuet. Skjut på att fatta beslut tills du har den grundläggande faktan till att fatta ett korrekt beslut, gör detta till största kapacitet.
Planera inte att använda 100% av varje gruppmedlems tid för varje fas, om gruppens tid är upptagen till 100% kommer dess fulla kapacitet bli begränsad, har de tid över kommer de däremot lyckas hålla en jämn takt tiden ut. Detta är precis som på en motorväg, när den är full blir den plötsligt inte speciellt snabb längre.
Koordinera flera team genom framförhållning, genom att göra detta kan man dela ut egenskaper i god tid för teamen att anpassa sig till, detta på ett rullande schema.
The Agile Project 