Agile methode: waterval negeren
12 februari 2015
De letterlijke vertaling van agile is lenig, vlug, behendig. In de IT betekent het dat software wordt ontwikkelt binnen een zeer korte periode (iteratie genoemd), zoals een maand of week. Bij een “agile ontwikkelteam” is het idee dat er intensief wordt samengewerkt, met zowel het team als derden. Het doel is altijd om na een iteratie bruikbare software te hebben geleverd.
Dat is agile software in een notendop. Maar waarom is het handig en/of waarom juist niet? Maar wat is de agile methode nou eigenlijk precies?
De agile methode
Voor de komst van de agile methode was de selectie van een leverancier makkelijker. Projecten hadden een duidelijke vooraf besproken prijs en ontwikkelingsduur waarbij zwart op wit stond wat het eindresultaat behoort te zijn. De scope was helder. Door het in kaart brengen van de eisen (requirements in IT terminologie) en de verwachtingen is duidelijk wat er wordt ingekocht. Deze methode wordt ook wel de waterval methode genoemd: de afbeelding hieronder illustreert duidelijk waarom is gekozen voor deze naam. Maar om compleet in kaart te brengen wat de scope is, is zeer lastig, zo niet onmogelijk. Zo zijn er zaken die over het hoofd kunnen worden gezien of minste verwachten zijn, die invloed hebben op de scope en daarmee het budget en de doorlooptijd.
De eerste stap van het waterval model wordt bij agile overgeslagen. De requirements worden vooraf niet heel gedetailleerd gedocumenteerd. Agile gaat uit van het principe dat vooraf niet te bepalen is wat het benodigde eindresultaat is. Hier wordt dan ook weinig tijd aan besteedt. De focus ligt meer op de doorlooptijd dan op de scope. Het grote voordeel hiervan is dat er tijdens een lopend project heel goed kan worden ingespeeld op nieuwe inzichten, wat bij de waterval methode lastiger is. Gefundeerd door een transparante, goede en vertrouwelijk samenwerking is de agile methode ontwikkelt voor juiste omgang met steeds veranderende omstandigheden. Vandaar de naam agile; lenig, vlug, behendig.
Geen requirements betekent niet: we zien wel
Dat dit de selectie van een software leverancier niet eenvoudiger maakt, is duidelijk. Want hoe kan met een leverancier een goede afspraak worden gemaakt als niet duidelijk is wat de scope en het gewenste eindresultaat is? Dit is op te lossen door, in plaats van afspraken te maken over te leveren kwaliteit, een inspanningsverplichting op te stellen. De leverancier kan namelijk geen garantie geven op de kwaliteit van het eindproduct, maar wel op de moeite die deze er in gaat steken. Dit wordt dan ondersteund door rapportages over geboekte vooruitgang. Dit klinkt wellicht vreemd, maar eigenlijk is deze methode niet heel ongebruikelijk. Zo is het aannemen van personeel of bijvoorbeeld het inhuren van een advocaat vergelijkbaar. Tijd en kosten staan vast, maar wat voor inspanning precies nodig is om tot het gewenste resultaat te komen is nog niet helemaal duidelijk.
Dit betekent natuurlijk niet dat de leverancier helemaal naar eigen wens en inzicht zijn werkzaamheden (en daar aan gekoppelde, door u te betalen facturen) kan invullen. Er wordt een afspraak gemaakt over de te leveren inspanning. Deze moet uiteraard ook verantwoord worden. Dit gebeurt door onder andere door regelmatige rapportages over de voortgang en de tot dan toe behaalde resultaten.
Bron: Frankwatching
Meer informatie over agile?
Vragen over agile of andere methodieken?
Neem contact op met Jaap Lucas voor een vrijblijvend gesprek.
Of bel direct: 0318-745010