Een bekend probleem; IT projecten die over het budget heengaan. Je hebt bijvoorbeeld vast wel eens gehoord van de mislukte en te dure projecten bij de overheid.
De grote vraag is natuurlijk: “hoe voorkom je te dure en mislukte ICT projecten?”.
Maak een minimaal werkende versie van de software en breidt deze incrementeel uit in kleine stapjes!
Laat je systeem ontwikkelen in stappen
Je houdt de kosten en voortgang van de ontwikkeling van je systeem onder controle door te beginnen met een minimaal werkend product (een demoversie of “Proof of concept” van de website of software) en daarna kun je dit in korte periodes, van bijvoorbeeld 2 weken of een maand, aanpassen en uitbreiden.
Hierdoor houd je de kosten en de voortgang strak onder controle, en kun je voortdurend terugkoppeling van de uiteindelijke gebruikers en andere stakeholders in het systeem verwerken. Je hebt immers slechts de kosten van 2 weken of een maand development, en je krijgt meteen een versimpelde, werkende versie van je eindproduct te zien, waarop je meteen feedback kunt geven. Deze methode wordt ook wel agile development genoemd. Agile development houdt nog meer in dan alleen dit, maar dat is niet belangrijk voor dit artikel.
Je kunt je voorstellen dat de kans hierdoor een stuk groter is, dat het opgeleverde systeem uiteindelijk ook echt doet wat jij als opdrachtgever in gedachten had.
Wat gaat er vaak fout bij mislukte projecten?
Het grootste probleem bij de meeste mislukte of te dure projecten is de manier van werken. Er wordt gewerkt via de zogenaamde waterval-methode, waar het systeem in het begin helemaal wordt uitgedacht en daarna wordt geïmplementeerd.
Hierbij is er vaak onderweg, net zoals bij een waterval, geen weg meer terug. Zelfs als blijkt dat het uitgedachte systeem niet helemaal goed is uitgedacht, of dat misschien de organisatie is veranderd en inmiddels behoefte heeft aan een ander soort systeem.
Bij incrementeel werken omzeil je dit probleem, en veranderen de requirements en je software met jouw inzichten en veranderingen mee!
Hoe ziet zo’n project in stappen er dan ongeveer uit?
Laten we als voorbeeld een “het bouwen van een tekst editor” nemen (vergelijkbaar met bijvoorbeeld Microsoft Word). We besluiten iteraties van 2 weken te hanteren, en maken voor het voorbeeld 3 versies.
Versie 1: Een simpele text editor waarin je tekst kan typen en opslaan
Deze versie is belangrijk, zodat we meteen feedback van alle stakeholders kunnen verwerken. Is dit inderdaad ongeveer wat de bedoeling was, een desktop tekstverwerker? Werkt het misschien niet toch handiger als we een web versie maken die via internet beschikbaar is? Et cetera.
Voor dit voorbeeld gaan we er vanuit dat dit inderdaad ongeveer de bedoeling was. We nemen de op- en aanmerkingen en nieuwe requirements mee naar de volgende iteratie.
Versie 2: Uitbreiding van de user interface en mogelijkheid voor tekstopmaak
Er bleek behoefte aan een mooiere user interface en de mogelijkheid om de tekst in bepaalde opmaak weer te geven. Na de implementatie wordt bijvoorbeeld het volgende opgeleverd:
Dit was inderdaad de bedoeling, het programma ziet er mooier uit, en er is meer functionaliteit voor de tekstopmaak toegevoegd. Ook de stijl wordt goedgekeurd door de opdrachtgever, nu kan er verder gewerkt worden aan een uitbreiding met mooie knoppen en geavanceerde functionaliteit om de tekst op te maken.
Versie 3: Final versie met uitgebreide user interface
Deze versie is klaar voor een eerste release! Het moge duidelijk zijn dat dit slechts een voorbeeld was, maar het illustreert kort het idee van iteratief werken in een software project en de voordelen daarvan.
Men had bij versie 1 ook kunnen besluiten n.a.v. feedback van de klant om een webversie te bouwen. Was dit pas bij de uiteindelijke uitgebreide versie aan het licht gekomen (met de waterval-methode), dan waren er een hoop onnodige kosten gemaakt en was er kostbare tijd verloren gegaan!
Bespaar kosten en werk iteratief
Bovenstaande illustreert de voordelen van iteratief, of agile, werken in IT projecten:
- Snel een werkende demo, waardoor snel feedback van de klant verwerkt kan worden.
- Makkelijk bijsturen in het geval van veranderde requirements.
- Snel kunnen ingrijpen als het idee door de IT-afdeling verkeerd geïnterpreteerd is.
- Bespaar kostbare tijd door op tijd fouten en pijnpunten in je project te identificeren.
- Voorkom mislukte projecten, de kans van slagen is vele malen groter met deze werkwijze.
- Voorkom onnodige kosten door development van features die uiteindelijk niet gebruikt zullen worden omdat ze niet (meer) nodig zijn.