reviews2

När jag började arbeta med mjukvaruutveckling 1996 var det självklart att arbeta med plandriven utveckling. ”Alla” använde vattenfallsmodellen och Gantt-scheman. Det var tunga processer, med mängder av dokument och planer som skulle produceras. IEEE hade (och har ännu) en uppsjö av standarder som beskriver hur man skall skriva projektplaner, testdokument, QA-planer och till och med standarder för hur man skall skriva användardokumentation. Jag själv jobbade då på Ericsson med att specificera testfall i ett helt år. Under detta år genomfördes inte ett enda av testfallen. Vi skulle vänta med själva testningen tills hela specifikationen var klar. Och framför allt skulle vi vänta med testningen tills all kodning var klar..

Den Agila världen gillar dokumentation men inte omfattande dokumentation.

Förutom tung och omfattande dokumentation så arbetade de flesta med prediktiv planering, dvs att man först gör planen och sedan genomför man planen. Problemet med att först planera hela arbetet och sedan genomföra planen är att man måste prediktera framtiden, dvs man måste förutsäga och gissa hur framtiden kommer att se ut. Hur lätt är det idag? Den predikterade planen skall sedan följas till varje pris och lyckas man följa planen så är det ett lyckat projekt, oavsett om användaren/beställaren blir nöjd eller ej vid leverans. Definitionen av ett lyckat projekt är att vi följer planen och håller budget. Men produkten då? Kundnöjdheten då? Räknas inte det?

Lyckat == i tid && inom budget

Det har visat sig att just inom mjukvarubranschen så funkar inte det plandrivna sättet att arbeta på så bra. För det första så är det människorna som är den viktigaste tillgången i ett mjukvaruprojekt (inte maskiner). Och människor är inte alls predikterbara. För det andra så kan en predikterad plan bara hållas om den predikterade framtiden blev som vi förutsåg. Dvs framtiden får inte förändras. Och om framtiden inte får förändras så får inte heller kraven förändras.

För att en prediktiv plan skall hålla måste alla krav, som i början ställdes, förbli stabila

Och det vet ju alla som utvecklat mjukvara att kraven aldrig någonsin är stabila. Och kan vi inte ha stabila krav (och arbetar med plandriven utveckling) så kan vi inte ha stabil design, och då kan vi inte ha stabil implementation o.s.v. Det är ganska självklart. Eller som Martin Fowler säger att "om vi inte kan ha stabila krav så är allt efterföljande också instabilt. Så hela mjuvaruprocessen blir instabil".

Den Agila världen säger att vi skall ändra så att mjukvaruutvecklingsprocessen INTE är beroende av stabila krav och hitta på processer som är toleranta mot föränderliga krav.

Den Agila världen planerar, men inte bara i början, utan ständigt. Agila planer planeras om och om och om igen i cykler. Oftast planeras det varje dag och runt detta planeras det varje vecka och planen justeras beroende på var vi är just nu. Precis som en termostat: vi vrider den lite, känner efter hur det blev och sedan justerar vi den för att få rätt värme. Eller som vi styr ett skepp som beger sig ut på ett stort öppet okänt och opredikterbart hav, fyllt med förändringar som kan göra att vi kommer fram tryggare. Detta kallas för adaptiv planering.