Softwareontwikkelmethode scrum

Scrum is een iteratieve ontwikkelingsmethode waar computersoftware mee ontwikkeld kan worden. Doordat er kleine stapjes genomen worden, is deze ontwikkelingsmethode flexibeler dan de traditionele ontwikkelingsmethoden. Omdat in het scrumteam naast de ontwikkelaars ook de opdrachtgever participeert, is de opdrachtgever op de hoogte van de voortgang van het project en kan de opdrachtgever ingrijpen wanneer er een misverstand ontstaat tussen opdrachtgever en ontwikkelaar.

Geschiedenis scrum

De basis voor de ontwikkelingsmethode scrum werd begin 1986 door Ikujiro Nonaka en Hirotaka Takeuchi beschreven in de Harvard Business Review. Jeff Sutherland ontwikkelde op basis van dit onderzoek in 1993 het scrumproces. Samen met Ken Schwaber werd de methode verder uitgewerkt, waarna in 1995 scrum als ontwikkelingsmethode voor te ontwikkelen software werd geformaliseerd.

Wat is scrum

Scrum is een iteratieve ontwikkelingsmethode waarmee, door te doen en door kleine stapjes te zetten, op een effectieve en flexibele manier een goed werkend systeem neergezet wordt. Vaak wordt deze methode gebruikt voor het ontwikkelen van software, maar de methode wordt steeds meer ingezet in andere omgevingen.

Voordelen scrum

De methode heeft vele voordelen ten opzichte van andere software ontwikkelingsmethoden. Scrum gaat namelijk uit van de mogelijkheden en niet van de onmogelijkheden.

• Korte lijnen: doordat de opdrachtgever ook participeert in het ontwikkelteam zijn de lijnen tussen de ontwikkelaar en de opdrachtgever kort. Hierdoor kan er direct ingegrepen worden wanneer de ontwikkelaars iets anders ontwikkelen dan de opdrachtgever voor ogen heeft.
• Kort cyclisch: iedere 2-4 weken wordt een werkend stuk software opgeleverd. Hierdoor blijft de vaart in het ontwikkelproces gegarandeerd en kan de opdrachtgever snel ingrijpen wanneer blijkt dat er een misverstand is tussen ontwikkelaars en opdrachtgever.
• Voortgang: door de korte cycli is de voortgang van het project duidelijk.
• Overzichtelijk: door de korte cycli is het op te leveren deel overzichtelijk. Het team kan zich hierdoor focussen op een enkel probleem.

Opbouw team

Een scrumteam is een multidisciplinair team. In het team participeren naast de ontwikkelaars ook de opdrachtgever, klant en gebruiker. Deze laatsten hebben ook zeggenschap. Hierdoor kan het team snel schakelen.

Het team is zelfsturend. Het team bepaalt zelf de planning en verdeelt onderling de taken. Ook het voorzien van blokkades en andere problemen en uitdagingen is een deel van het takenpakket. Doordat het hele team zelfsturend is, is ieder teamlid verantwoordelijk. Hierdoor is er geen projectleider nodig: het team is dus niet hiërarchisch opgebouwd.

Een scrumteam bestaat meestal uit minimaal drie tot maximaal negen personen. Het liefst werken deze personen in een fysieke ruimte samen, waardoor korte lijnen ontstaan. Het team bestaat uit ontwikkelaars, een scrum master en een opdrachtgever (de product owner).

Product owner

De product owner is de opdrachtgever. Dit teamlid bepaalt het ‘wat’. Hij geeft aan wat er gemaakt moet gaan worden en in welke volgorde, hij bepaalt de prioritering.

Ontwikkelaars

De ontwikkelaars bepalen het ‘hoe’. Zij zijn verantwoordelijk voor de analyse, het ontwerp, de ontwikkeling, de test en de documentatie. Zij leveren aan het einde van elke sprint een werkend stuk software op.

Scrum master

De scrum master is de katalysator. Hij zorgt ervoor dat het scrumproces gevolgd wordt. Daarnaast regelt hij alle scrumvergaderingen. Hij is er verantwoordelijk voor dat het team niet lastig gevallen wordt door derden, of dat er tijdens de sprint extra wensen en eisen neergelegd worden.

Sprint

De scrummethodiek is iteratief. Dit houdt in dat er kort cyclisch gewerkt wordt: iedere twee tot maximaal vier weken wordt een werkend stuk software opgeleverd. Zo’n iteratie wordt een ‘sprint’ genoemd. Aan het einde van een sprint wordt een afgerond stuk software opgeleverd.

De opdrachtgever zorgt ervoor dat alle wensen en eisen vastgelegd zijn en dat deze geprioriteerd worden. Deze wensen en eisen worden ‘user stories’ genoemd. De user stories zijn vastomlijnde opdrachten die vaak binnen enkele uren of maximaal enkele dagen op te lossen zijn. Alle user stories staan geprioriteerd op een lijst die de ‘backlog’ genoemd wordt. Aan het begin van een sprint wordt deze backlog tijdens de sprint planning doorgelopen en worden er punten aan elke user story toegekend. Aan de hand van deze punten wordt bepaald hoeveel uur elke user story waarschijnlijk zal gaan kosten. Aan de hand van de gegeven punten bepaalt het team hoeveel user stories er tijdens deze sprint opgepakt kunnen worden en aan welke user stories tijdens deze sprint gewerkt gaan worden.

De user stories waaraan gewerkt gaan worden, worden op het ‘taskboard’ gehangen. Vaak in de vorm van gele briefjes of ‘post-it’s’. De teamleden verdelen onderling de user stories en bepalen wanneer welke user story uitgewerkt gaat worden.

Aan het einde van de sprint wordt er geëvalueerd met het team en met de klant en worden de verbeterpunten vastgelegd, zodat een volgende sprint nog beter uitgevoerd kan worden, de ‘retrospective’. Op deze manier zal aan het einde van het project de klant exact het product hebben dat hij voor ogen had.

Vergaderingen

De scrummethode maakt gebruik van verschillende vergaderingen:

Daily scrum of stand up

Elke ochtend is er een korte vergadering van maximaal 15 minuten. Tijdens deze vergadering moeten alle teamleden aanwezig zijn. Tijdens deze meeting staan alle teamleden om het taskboard heen, vandaar de naam ‘stand up’. Elk teamlid krijgt tijdens de meeting het woord.

Ieder teamlid beantwoordt de volgende drie vragen:

1. Wat heb je (gisteren) gedaan?
2. Wat ga je (vandaag) doen?
3. Voorzie je problemen of uitdagingen (impedements) en heb je daar hulp bij nodig?

Omdat de vergadering maximaal 15 minuten mag duren kunnen alleen kleine problemen besproken worden. Grotere problemen worden na de vergadering opgepakt met de belanghebbenden.

Backlog refinement

Tijdens de backlog refinement worden de user stories die op de backlog staan geanalyseerd. De teamleden bekijken of de omschrijvingen van de user stories voldoende zijn om deze in behandeling te nemen. De user stories die te groot zijn, worden in delen opgeknipt om zo behapbare delen te creëren die in een sprint op gepakt en opgelost kunnen worden. De kwaliteit van de backlog zal hierdoor verbeteren.

Sprint planning

Voor de start van de sprint komen de teamleden bij elkaar om de backlog te bekijken. Elke user story op de backlog wordt door het team voorzien van punten. Vaak gebeurt dit door middel van ‘pokeren’. Ieder teamlid krijgt pokerkaartjes met hierop punten. Per user story geeft een ieder zijn mening over de planning door een kaartje met een aantal punten neer te leggen. Aan de hand van de gegeven punten wordt gediscussieerd en komen de teamleden in samenspraak tot een gefundeerd aantal punten.

Het team bepaalt hierna hoeveel punten en dus hoeveel user stories de aankomende sprint opgenomen kunnen worden. De user stories en taken worden daarna over de leden verdeeld. De user stories waar deze sprint aan gewerkt gaan worden, worden op het taskboard gehangen.

Sprint review

Tijdens de sprint review wordt het stuk software wat tijdens de sprint is ontwikkeld getoond. Deze bijeenkomst duur maximaal 4 uur en is voor iedereen toegankelijk.

Retrospective

Aan het einde van de sprint komen de teamleden bijeen om de afgelopen sprint te evalueren. Vaak krijgt de sprint een cijfer, van 0 tot 10. Gekeken wordt wat er goed en fout is gegaan tijdens de sprint, waardoor er een leerproces is. Van belang is dat er een veilige sfeer is, waarin ieder eerlijk zijn mening kan geven.

Taskboard

Op het taskboard hangen alle user stories waar de huidige sprint aan gewerkt worden. Het taskboard is in drie of vier delen gesplitst:

1. To do: dit zijn alle user stories waar nog niet aan gewerkt wordt, maar die wel in deze sprint opgepakt moeten gaan worden.
2. In progress: dit zijn user stories waar aan gewerkt wordt.
3. Done: dit zijn door de ontwikkelaars afgeronde user stories.
4. Testing (optioneel): user stories die door het acceptatieteam worden getest.

Elke user story uit de huidige sprint staat beschreven op een post-it en hangt in een van de kolommen op het taskboard. Zo is het voor iedereen in het team duidelijk waar aan gewerkt wordt. Het team is zelf verantwoordelijk wie welke user story oppakt. Na de start van de sprint kunnen er geen extra user stories meer op het taskboard gehangen worden.