Welke software ontwikkelingsmethode kies jij?

Lekker scrummen, lean, kanban, feature-driven of toch de waterval methode? Kies een software ontwikkelingsmethode om project chaos te voorkomen! Ieder project dat meer dan enkele weken in beslag neemt kan wel wat structuur gebruiken. Anders is de kans groot dat je in een app ontwikkeltraject na verloop van tijd door de bomen het bos niet meer ziet. Het kiezen van en vasthouden aan een software ontwikkelmethode die past bij je organisatie is daarom een goed idee.

In de afgelopen decennia is er een oerwoud aan verschillende methoden ontstaan die allemaal hun voor- en tegens hebben. Maar belangrijker om te weten is wat de grote lijn is en welke software ontwikkelmethoden écht van deze tijd zijn.

Drie hoofdstromen
In principe zijn alle software ontwikkelingsmethoden in te delen naar deze drie hoofdstromen: 

• Waterval
• Iteratief 
• Spiraal

Het basisprincipe van de waterval methode is dat het ontwikkeltraject in verschillende fases is ingedeeld. Er wordt pas gestart met ontwikkelen als alle vereisten duidelijk zijn. Iedere fase moet eerst volledig afgerond worden, voordat het traject verder gaat naar de volgende fase. Vandaar de naam waterval, er ontstaat als het ware eerst een stuwmeer van informatie die daarna wordt ‘gestort’ in de volgende fase.

In de iteratieve stroming staat het snel ontwikkelen van een prototype centraal. Er wordt vanuit gegaan dat we eigenlijk nog niet zo goed weten wat we uiteindelijk willen. Het prototype dient er voor om dit te ontdekken.  Iteratieve modellen volgen een cyclus van ontwikkelen, verbeteren en demonsteren. Centraal in deze methode staat daarom het verwerken van feedback die we krijgen na het demonstreren van het prototype.

Het spiraal model combineert elementen van beide methodieken. Het probeert daarmee te profiteren van de voordelen die zowel een top down (waterval) als bottom-up up (iteratief) aanpak bieden. Deze stroming wordt voornamelijk gebruikt als meerdere jaren aan een product wordt gewerkt. Er wordt vele malen - als in een cirkel - door dezelfde fases van het projectmodel gelopen, waarbij het project uiteindelijk steeds groter wordt.

Populaire ontwikkelingsmethoden
Uit een onderzoek van Assembla en Usersnap uit 2016 onder bijna 1.000 ontwikkelbedrijven, blijkt welke ontwikkelingsmethoden op dit moment het meest worden ingezet:

Agile en Scrum worden beiden afzonderlijk genoemd, maar eigenlijk is Agile de benaming van een overkoepelende iteratieve stroming. Feature-driven development, dat in bijna een derde van alle projecten wordt gebruikt is ook een iteratieve methode, evenals de iets minder populaire Kanban en Lean methoden. Het klassieke waterval model blijkt ook nog steeds in bijna een kwart van alle projecten te worden gebruikt. Maar het is wel duidelijk dat tegenwoordig iteratieve software ontwikkeling de standaard is. Ook voor apps zijn deze methoden goed bruikbaar.

De belangrijkste principes van iedere methode zit ik hierna uiteen.

Scrum
Even lekker scrummen! Het lijkt wel of dat ieder bedrijf tegenwoordig in de ochtend bij de koffie automaat zijn dagelijkse opstart meeting heeft. Binnen Scrum werken multidisciplinaire teams samen,  die in korte sprints met een vaste lengte van 1 tot 4 weken, werkende software producten opleveren.

Scrum kent de volgende rollen voor teamleden: 

• product owner (klant of opdrachtgever)
• ontwikkelteam (levert de software)
• scrummaster (leidt de vergaderingen) 

Daarnaast zijn er een aantal standaard contactmomenten om het software ontwikkelingsproces in goede banen te leiden.

1. Daily scrum
Vergadering van ongeveer 15 minuten aan het begin van de dag. Ieder teamlid vertelt wat hij gisteren gedaan heeft, vandaag gaat doen en welke problemen en uitdagingen hij tegenkomt.

2. Backlog refinement
Alle ideeën worden in een backlog geplaatst en daarna verder uitgewerkt in user stories. Het is belangrijk om te begrijpen wat de product eigenaar precies wil en dat wordt in deze meeting nader bepaald en verder georganiseerd.

3. Scrum of scrums
Als er meerdere scrum teams zijn, is er ook een overleg tussen deze teams nodig. Het gaat daarbij dan om punten aan te laten sluiten waarbij men met elkaar te maken heeft. Dit overleg wordt normaal gesproken aansluitend op de daily scrum gehouden. Elk team stuurt dan een vertegenwoordiger.

4. Sprint planning
Aan het begin van iedere sprint is er een overleg om te plannen. De belangrijkste user stories worden daarbij in een volgende sprint opgenomen. De teamleden bepalen hoeveel taken in de volgende sprint mee kunnen en zijn zelf verantwoordelijk voor het verdelen van die taken.

5. Sprint review
Een product demo aan het eind van een sprint waarin het team toont wat afgerond is. Het belangrijkste doel van de scrum methode is het opleveren van werkende software aan het eind van een sprint. Dit overleg duurt maximaal 4 uur.

6. Evaluatie
Bedoeld om te leren wat er goed en fout ging. Het overleg duurt maximaal drie uur. Het is niet de bedoeling om teamleden de schuld in de schoenen te schuiven als er iets fout ging. Het belangrijkste doel is om te leren en als team nog beter te worden in de toekomst. Het scheppen van een sfeer van onderlinge waardering is de belangrijkste uitdaging voor de scrummaster in deze fase.

Ondanks het feit dat scrum op dit moment erg populair is, kent het een valkuil dat de methode uiteindelijk uitmondt in Scrum In Name Only (SINO). Daarbij vervalt scrum tot een steeds langer wordende dagelijkse opstart meeting waarbij de overige onderdelen volledig worden vergeten.   

Feature-driven development
Feature-driven development (FDD) is een ontwikkelmethode die uit vijf basistaken bestaat. De eerste drie worden opeenvolgend doorlopen en daarmee wordt een globaal model gemaakt. De laatste twee taken worden voor iedere te ontwikkelen feature continu herhaald: 

1. Ontwikkelen overall model
2. Samenstellen feature lijst
3. Plannen features
4. Ontwerpen feature
5. Bouwen feature

In de eerste fase worden voornamelijk voorbereidingen getroffen zoals het samenstellen van het team, vooronderzoek en het bepalen van de hoofdonderdelen van het project. Daarna wordt een feature lijst gemaakt die in de tijd gepland wordt in de vorm van een ontwikkelplan. Daarin wordt ook bepaald wie waarvoor verantwoordelijk is. Binnen FDD worden features in korte sprints van ongeveer twee weken ontwikkeld, nadat ze eerst goed zijn uitgedacht. 

Waterval
De waterval methode is de meest klassieke vorm van software ontwikkeling. In deze methode wordt achtereenvolgens - als in een waterval - door de verschillende fases van het software ontwikkelingsproces heen gegaan. 

1. Definitie & analyse (doel)
2. Basisontwerp (wat)
3. Technisch ontwerp (hoe)
4. Bouw & implementatie
5. Testen
6. Integratie
7. Beheer & onderhoud

Het watervalmodel is afgeleid van de traditionele manier van werken in grote projecten in de constructiebouw. Aan een volgende fase wordt niet begonnen wanneer een voorgaande nog niet is afgesloten. En wanneer in één van de fases een fout ontdekt wordt, gaat men helemaal terug om die fase te corrigeren en de daaropvolgende stappen opnieuw uit te voeren.

De laatste jaren is met de opkomt van meer Agile methoden de waterval methode steeds minder populair geworden. De reden daarvoor is dat veel grote software projecten die sterk leunden op de waterval methode nog al eens de neiging hadden om uit de planning en het budget te lopen. 

Kanban
Ondanks dat de methode nu nog steeds populair is, dateert Kanban eigenlijk al uit de jaren 40, toen Toyota haar just in time productieproces introduceerde. In de Kanban methode ligt de nadruk op het continu opleveren van features. De voortgang van het werk wordt bijgehouden op het Kanban bord. Dit is simpelweg een visuele weergave van taken onder de kopjes todo, doing en done. De taken en een simpele omschrijving daarvan worden op kaartjes geschreven. De kaartjes worden verplaatst op het bord naarmate het werk vordert.

Kanban is de meest losse van de hier beschreven software ontwikkelingsmethoden. Er kan namelijk op ieder moment geswitcht worden in de planning en de methode kent in tegenstelling tot scrum geen vaste oplevermomenten. Wel wordt bijgehouden wat de gemiddelde doorlooptijd is van features, zodat een toekomstige werkplanning hierop afgestemd kan worden.

Lean
Lean softwareontwikkeling (LSD) kan worden samengevat in zeven principes, die erg lijken op de principes uit de lean productie in industriële omgevingen. 

1. Voorkom verspilling
2. Versterk het leereffect
3. Beslis zo laat mogelijk
4. Lever zo snel mogelijk
5. Geef het team verantwoordelijkheid
6. Kwaliteit
7. Zie het geheel

Alles wat geen waarde toevoegt voor de klant wordt in Lean gezien als verspilling. Denk daarbij bijvoorbeeld aan bureaucratische processen. Door veel samen te werken en zo vroeg mogelijk te testen wordt het opstapelen van fouten voorkomen. Beslissingen worden in de Lean methode soms uitgesteld door een meersporenbeleid te hanteren. Zo kunnen belangrijke keuzes gebaseerd worden op feiten in plaats van aannames.

Lean werkt ook met korte iteraties. Taken worden omgezet in user stories waarbij teamleden zelf het werk organiseren door middel van een self pulling systeem. Daarbij worden nieuwe taken in een dagelijkse standup meeting zelf gekozen door teamleden. Binnen de Lean methode staat het vinden van goede mensen en hen het werk laten doen centraal. Dit in tegenstelling tot een topdown benadering waarin werknemers vaak als uitvoerende poppetjes worden gezien. 

Het Lean denken moet door iedereen in een project goed begrepen worden voordat het wordt toegepast. Zie het grote geheel, maak kleine stappen, test meteen en leer snel (think big, act small, fail fast and learn rapidly) is de kern van Lean software ontwikkeling.

Samenvatting
Welke ontwikkelingsmethode je kiest voor jouw app ontwikkelingstraject zal voornamelijk afhankelijk zijn van de grootte van het project en je eigen persoonlijke voorkeuren. Van het inzetten van de ultra eenvoudige Kanban methode tot het organiseren van een monster van een project met de waterval methode, alles is beter dan de chaos en onduidelijkheid van een methode loos project (MLP). Zelfs met een klein team of een eenvoudig project is het aan te raden om wat structuur aan te brengen. Wist je trouwens dat er naast deze software ontwikkelingsmethoden ook nog hele goede project management software bestaat om je te helpen je doelen te bereiken?