Projektmodeller, frihed og risiko for overraskelser

I princippet er det muligt at beskrive samtlige krav til et stykke software på forhånd, lave et detaljeret design og derefter hurtigt implementere det. Hvis det altså er muligt at beskrive hele opgaven på forhånd, før den bliver udført. Hvis der bare ikke kan dukke nogle uforudsete begrænsninger op.

Det svarer til den type byggeri som vandfaldsmodellen egentlig er udsprunget af. Når en entreprenør skal bygge et hus fra grunden - og har sikret sig at den kan bære det - giver det god mening at bruge en faseopdelt model hvor der først laves tegninger, så en detaljeret plan for hvordan byggeriet skal gennemføres, grave grunden ud, støbe fundament og fortsætte opefter.

Det er bare undtagelsen i softwareudvikling i dag, hvor arbejdet som regel er baseret på en platform med nogle indbyggede begrænsninger, og hvor det selv i bedste fald er nærmest umuligt at vide på forhånd hvordan de vil påvirke implementeringen af det planlagte projekt.

Moderne softwareudvikling ligner mere opgaven med at sætte et gammelt hus i stand. Det er muligt at beskrive nogle overordnede behov i planlægningen, for eksempel at taget skal skiftes, men det er umuligt at planlægge på forhånd hvad der skal laves. Det kan først afgøres efterhånden som arbejdet skrider frem.

Der er altså ikke tale om at agil udvikling altid er bedre end andre modeller, den er blot mere velegnet til de udfordringer som moderne softwareudvikling ofte står overfor.

Vi kan også se moderne softwareudvikling ud fra Perrows tanker om kompleksitet. Der er så mange uundgåelige sammenhænge på kryds og tværs, at det er umuligt at lave en model af hvordan den færdige software vil opføre sig når den kommer i brug. I den situation er udviklerne nødt til at prøve sig frem, indtil gevinsten ved yderligere forbedringer er mindre end hvad det koster at lave dem.

En af konsekvenserne er, at det ofte er umuligt at lave en system som lever op til samtlige en kundes ønsker. I stedet er vi nødt til at tale om sandsynligheden for at en bestemt procentdel af ønsker kan opfyldes indenfor en given tid og pris.

En anden er, at det kan være en god ide at vurdere på forhånd om en bestemt platform kan opfylde tilstrækkeligt mange af kundens behov. Problemet er bare, at det helst skal gøres før udviklingsarbejdet starter, og altså før der er nogen chance for at lære hvor mange behov platformen er i stand til at opfylde.

En mulighed kan være at undersøge andre anvendelser af den samme platform, hvor godt den har opfyldt behovene, og hvilke forskelle der er mellem dem og behovene i det ønskede system. Igen uden nogen garanti, der kan kun være tale om en sandsynlighed for at en bestemt andel af behovene kan opfyldes. På den anden side er det bedre end et system som ikke kommer i drift, før det braser sammen under sin egen kompleksitet.

Litteratur: Charles Perrow: Normal Accidents