Gebruik van agile in projecten
In een klassiek softwaremodel is het zaak om van tevoren, via uitgebreide informatie analyse, functionele ontwerpen en technische ontwerpen de volledige scope van een ontwikkelproject in kaart te brengen. In de agile methodologie wordt uitgegaan van het zo snel mogelijk ontwikkelen en vermarkten van software in kleine iteratieve processen. Hier ligt geen dichtgetimmerd functioneel ontwerp aan ten grondslag, maar intensieve communicatie met stakeholders zodat prioriteiten voortdurend kunnen worden bijgesteld.
Jeff Sutherland, een van de oprichters van de Agile-beweging, zou graag zien dat de betere prestaties van Agile teams worden erkend en beloond. In zijn presentatie “Money for Nothing and Your Change for Free: Agile Contracts” wees hij erop dat klanten moe worden van leveranciers die contracten binnenhalen met bodemprijzen en vervolgens incasseren via change requests. Agile zou ook hier oplossingen kunnen bieden, maar kun je klanten overtuigen om in zee te gaan met een software ontwikkelaar zonder dat alle functionaliteit van te voren tot in detail is vastgelegd. Jeff Sutherland heeft een oplossing voor zowel klant als leverancier:
- Leg een lijst aan met alle features die nog ontwikkeld moeten worden. Geef prioriteiten aan op basis van business value (bijvoorbeeld de verwachte ROI).
Biedt een standaard contract aan tegen een vaste prijs, waarin tijd en materiaal (T&M) is opgenomen voor wijzigingen. - Voeg een clausule toe die het de klant toestaat een verandering te introduceren in ruil voor features van de onderkant van de lijst. De totale hoeveelheid werk (de projectgrootte) verandert hierdoor niet; de leverancier neemt het risico van verlate levering.
- Als een klant geen zin heeft minder belangrijke features van de lijst te halen, valt het contract terug op een standaard T&M-schema voor de veranderingen.
Deze benadering biedt veel mogelijkheden voor de klant omdat het ervan uitgaat dat de belangrijkste features het eerst worden opgeleverd en het de klant de mogelijkheid geeft om binnen de scope van het project veranderingen door te voeren.
Notitie van mijzelf
In deze punten wordt er impliciet nog van uitgegaan dat alle features op de lijst ook daadwerkelijk gemaakt moeten worden binnen het gestelde budget. Hiermee houd je de illusie in stand dat alle features van tevoren precies kunnen worden begroot. Liever zou ik zien dat in het project niet wordt geprobeerd al deze ontwikkeling in één contract onder te brengen, maar dat wordt gewerkt met een raamovereenkomst en aparte contracten per (sub)release. De klant kan dan, na elke release, bepalen of de leverancier in voldoende mate aan zijn verplichtingen heeft voldaan alvorens een nieuw contract uit te geven. Dit principe past, denk ik, bij het uitgangspunt van een agile werkwijze waarbij de klant aan het stuur gezet wordt van zijn eigen project.
Iemand anders aanvullingen?
(Source: computerworld.nl)
