Software-ontwikkeling: welke methoden zijn er en waarin verschillen ze?

Lekker scrummen, lean, kanban, feature-driven of toch de waterval methode? Kies een software-ontwikkelingsmethode die bij je past. 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 watervalmethode 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 vanuitgegaan 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 spiraalmodel 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 Leanmethoden. Het klassieke watervalmodel 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 zet ik hierna uiteen:

Scrum

Even lekker scrummen! Het lijkt wel of dat ieder bedrijf tegenwoordig in de ochtend bij de koffie-automaat zijn dagelijkse opstartmeeting heeft. Binnen Scrum werken multidisciplinaire teams samen,  die in korte sprints met een vaste lengte van een tot vier weken, werkende softwareproducten 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 vijftien 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 producteigenaar precies wil en dat wordt in deze meeting nader bepaald en verder georganiseerd.

3. Scrum of scrums

Als er meerdere scrumteams 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. Sprintplanning

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 productdemo aan het eind van een sprint waarin het team toont wat afgerond is. Het belangrijkste doel van de scrummethode is het opleveren van werkende software aan het eind van een sprint. Dit overleg duurt maximaal vier 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 opstartmeeting 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 featurelijst 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 watervalmethode 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 Agilemethoden de watervalmethode steeds minder populair geworden. De reden daarvoor is dat veel grote softwareprojecten die sterk leunden op de watervalmethode 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 Kanbanmethode ligt de nadruk op het continu opleveren van features. De voortgang van het werk wordt bijgehouden op het Kanbanbord. 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 geswitched 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 software-ontwikkeling (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 Leanmethode 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 Leanmethode 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 projectmanagementsoftware bestaat om je te helpen je doelen te bereiken?