in products / boostrapping

Niet té agile, aub…

Agile software ontwikkeling is een mooi principe. Het principe zegt dat je snel van start gaat met programmeren, snel iets oplevert (ook al is dat nog niet 100% af), op basis daarvan feedback verzamelt van de klant, en op basis van die feedback de ontwikkeling bijstuurt. Dit herhaal je. Door regelmatig feedback te verzamelen en bij te sturen groeit het project letterlijk in de juiste richting.

Zoals overal, zijn er ook in software development veel dingen kan je onmogelijk op voorhand plannen. Denk maar even aan de renovatiewerken die je ooit hebt laten uitvoeren, of de bouw van je huis. Zelfs niet met een 300 pagina’s dikke functionele design en technische analyse kan je heel het project uitstippelen. En dat is precies het probleem dat agile ontwikkeling wil aanpakken. Planning is guessing. De weg die je op voorhand uitstippelt aan de hand van een gedetailleerde functionele design wordt toch nooit bewandeld. Er zijn onderweg altijd bijsturingen nodig. Die vangen we op door onderweg feedback te vragen en bij te sturen. We proberen niet eens om de weg uit te stippelen. Agile software ontwikkeling.

Daarnaast is het zo dat gaandeweg een project, zeker bij grotere projecten, de functionele vereisten wijzigen. Dit omdat het in het begin nog niet helemaal duidelijk was wat nu eigenlijk de bedoeling was van de software, omdat er nieuwe elementen opduiken die invloed hebben op de uiteindelijke vereisten. Agile ontwikkeling speelt hier mooi op in, aangezien de functionele vereisten pas gaandeweg worden bepaald.

Echter, ik vind het een probleem als Agile ontwikkeling een excuus wordt om helemaal geen functionele of technische analyse te doen. Er zijn namelijk een heel aantal zaken die je wél perfect op voorhand kan uitstippelen. Agile ontwikkeling is geen reden om de functionele design over te slaan. Een document van een paar pagina’s met een redelijk gedetailleerde uitwerking van de gewenste functionaliteiten is niet overbodig. Agile ontwikkeling is geen reden om helemaal geen technische analyse te doen. Bepaalde belangrijke technische keuzes kunnen pas correct gemaakt worden als er wél een volledig helikopter overzicht is van de volledige scope. Het is dus heus niet overbodig om de data die je ter beschikking hebt en de business logica die later met die data zal werken, even nader te bekijken.

Een goede functionele en technische analyse zorgen ervoor dat je koers zet in de juiste richting, zonder over details te praten. Agile ontwikkeling kan/moet gaandeweg die koers nog bijsturen. Maar als je op basis van “gevoel” en “Agile-we-zien-wel-na-de-eerste-iteratie” je koers kiest, kan je wel eens de verkeerde koers kiezen. Ik geloof dat een deftige functionele en technische analyse vòòr de eerste letter code het project serieus kunnen inperken qua tijd, kost, frustratie en misverstand. Ik geloof ook dat agile ontwikkeling nodig is om het project, na de eerste letter code, op koers te houden, en rekening te houden met onvoorziene omstandigheden die tijdens de functionele en technische analyse niet duidelijk waren.

scrum-sprint

Write a Comment

Comment

  1. Heel juist Pieter… Nu begrijp ik bepaalde projecten vanuit het verleden net iets beter… het was allemaal iets te agile…