Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Agile doe je niet zomaar…

 

Computable Expert

ing. Ruud Hochstenbach
Business Development Manager, OUTSYSTEMS. Expert van Computable voor de topics Management, Development en Beheer.

Agile ontwikkelen raakt meer en meer bekend. Maar er bestaan nog veel vooroordelen over de techniek. Een van de hardnekkige misverstanden is dat Agile gelijk staat aan anarchie. Er zou niet gestructureerd, niet gedocumenteerd en ongedisciplineerd gewerkt worden in Agile-ontwikkelprojecten. Niets is minder waar.

Veel mensen vinden Agile ontwikkelen maar eng, omdat vooraf niet tot drie cijfers achter de komma vastgelegd wordt wat er in een project gebeuren gaat. Vaak wordt op basis van die angst gekozen voor een traditioneel ontwikkelproject. Hierbij wordt dan voor lief genomen dat het budget èn de deadline met aan zekerheid grenzende waarschijnlijkheid overschreden zullen worden.

Wie kiest voor een traditioneel project, onderhandelt uitgebreid met zijn opdrachtnemer aan de andere kant van de tafel, tekent een vaak vuistdik contract en ziet de ontwikkelaar vervolgens pas weer terug aan het eind van het traject. De opdrachtgever krijgt op dat moment een doos met een prachtige strik erop overhandigt, die na het uitpakken een applicatie blijkt te bevatten die niet meer aansluit op de inmiddels veranderde businesseisen. Uit onderzoek dat gepubliceerd is door de Standish Group, blijkt dat meer dan de helft van de functionaliteit in traditioneel ontwikkelde applicatie nooit of zeer zelden gebruikt wordt. Dat is echt schrikbarend veel, als je bedenkt dat voor al die functionaliteit wel betaald wordt.

Bij een Agile-ontwikkelproject zitten opdrachtgever en –nemer niet tegenover, maar naast elkaar aan tafel. En treffen ze elkaar op een veel groter aantal momenten dan bij een traditioneel traject. Vooraf wordt globaal besproken wat voor soort applicatie ontwikkeld zal worden, wanneer die klaar moet zijn en in hoeveel stappen (iteraties) er ontwikkeld gaat worden. Vervolgens begint de ontwikkelaar aan zijn eerste “sprint”, waarbij de meest urgente functionaliteit in de applicatie geplaatst wordt. Aan het einde van iedere iteratie, na een vooraf bepaalde termijn, komen opdrachtgever en –nemer weer bij elkaar voor een demo van de tot dan toe beschikbare functionaliteit en bespreken ze de scope voor de volgende sprint.

Omdat de applicatie na iedere sprint getest wordt door een business- / key user die deel uitmaakt van het projectteam en er dus regelmatig feedback gegeven wordt, worden opdrachtgever- en nemer echt gezamenlijk verantwoordelijk voor het eindresultaat. Een ander voordeel is dat nieuwe eisen die zich tijdens het ontwikkelproces vormen, eenvoudig meegenomen kunnen worden in de volgende sprint. Die worden dan uitgewisseld tegen minder belangrijke functionaliteit. In tegenstelling tot traditionele trajecten kost zo’n wijziging niet meer tijd of geld. De opleverdatum van de applicatie komt dus niet in gevaar.
De uitgewisselde functionaliteit wordt geparkeerd. Nadat er voldoende ervaring opgedaan is met de applicatie wordt opnieuw gekeken naar het belang van die functionaliteit. Dan wordt bekeken of die in de volgende release van de applicatie alsnog meegenomen moet en kan worden.

Het is niet zo dat alle projecten geschikt zijn voor Agile ontwikkelen. Soms is het belangrijk om het gewenste eindresultaat wel tot in detail vast te leggen in dat vuistdikke contract waar ik het eerder over had, omdat het project te gecompliceerd is voor de Agile-methode. Wie een spaceshuttle bouwt, verandert namelijk ook niet halverwege van mening over de plaats waar de vleugel komt.

Maar bij het overgrote deel van de it-projecten is Agile ontwikkelen een heel goed alternatief voor een traditionele werkwijze. Om succesvol Agile projecten te doen zijn er wel een aantal spelregels die gevolgd moeten worden. Zo is het cruciaal dat er een zeer sterke betrokkenheid van de business is en dat alle tussentijdse testen met echte praktijkdata uitgevoerd worden, moeten zowel opdrachtgever als –nemer goed kunnen communiceren, moet het volledige mandaat over het project binnen het projectteam liggen en moet voor iedereen die meewerkt aan het project de afgesproken deadline heilig zijn.

Mocht u nog niet overtuigd zijn van de betrouwbaarheid van Agile ontwikkelen, sla er dan eens een Engels-Nederlands woordenboek op na. U zult zien dat er niets staat over anarchisme, ongestructureerd, ongedisciplineerd of ongedocumenteerd werken. Agile betekent: beweeglijk, vlug of lenig. Ik moedig u aan om – rekening houdend met de spelregels - uw eerste Agile project te gaan uitvoeren!

Ruud Hochstenbach
Account/Partner Manager OutSystems

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4232097). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Het is zeker de moeite waard om te kijken of de agile ontwikkelmethode binnen je eigen bedrijf toegepast kan worden. Zorg er echter voor dat je goed beslagen ten ijs komt. Volg een training met je team om je de agile werkwijze eigen te maken. Vooral het efficient uitvoeren van de dagelijkse scrum meeting moet je leren. Zaken als hoe om te gaan met inhoudelijke discussies en aannames als de requirements onvoldoende duidelijk zijn moeten getraind worden.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×