Scrum

• Informatica
• Middelbare school
• havo, vwo
• Leerjaar 3-6

Introductie

Scrum is een populaire projectmanagementmethode die veel wordt gebruikt in softwareontwikkeling en andere projecten waarbij teamwerk en flexibiliteit belangrijk zijn. In deze les zal ik de basisprincipes van Scrum uitleggen en hoe het kan worden toegepast in jullie project.

Introduceer wat scrum is en hoe het functioneert.

Scrum begint met het idee dat het moeilijk is om vooraf precies te weten wat er nodig is om een project succesvol af te ronden. In plaats daarvan is het beter om het project op te delen in kleinere stukken en deze stukken geleidelijk aan te ontwikkelen. Binnen Scrum is er een vast team dat verantwoordelijk is voor het project. Dit team wordt geleid door een Scrum Master die ervoor zorgt dat het team zich aan de Scrum-methodologie houdt en dat er geen obstakels zijn die het team belemmeren in hun werk.

drie belangrijke rollen binnen het Scrum-team

• de Product Owner
• de Scrum Master
• het Development Team

Product owner

Verantwoordelijk voor het beheren van de Product Backlog, een lijst met alle items die moeten worden gerealiseerd voor het project. De Product Owner bepaalt de prioriteit van deze items en werkt nauw samen met het Development Team om ervoor te zorgen dat de juiste items worden ontwikkeld.

Het Development Team

Verantwoordelijk voor het ontwikkelen van de items op de Product Backlog. Het team werkt in korte sprints van 1 tot 4 weken en aan het einde van elke sprint wordt er een werkend product opgeleverd.

Scrum Master

Dat is heel wat anders dan een projectmanager. Als Scrum Master ben je vooral bezig met het faciliteren van het team. Je zorgt ervoor dat alles goed kan verlopen. Een Scrum Master is als smeerolie in een motor: hij zorgt ervoor dat alles soepel draait. Wanneer een deelproduct niet op tijd gereed of onvolledig is, is het hele team verantwoordelijk en niet alleen de Scrum Master. De Scrum Master zorgt ervoor dat het team zich aan de spelregels van Scrum houdt

Je bent in een scrumteam met z’n allen verantwoordelijk voor het resultaat. Het team maakt zelf zijn planning en de teamleden ‘beloven’ elkaar dat ze zich ervoor inzetten om die planning te halen. Verder is het niet de manager die het werk verdeelt, maar de teamleden zelf. Ook houden ze elkaar op de hoogte van de voortgang. Het is namelijk belangrijk dat de planning gehaald wordt en daarvoor is het hele team verantwoordelijk.

Product Backlog

Een geordende lijst van alle items die moeten worden ontwikkeld om het product te voltooien.

Het bevat alle vereisten, functies, verbeteringen en bugs die het team moet aanpakken.

De Product Backlog is dynamisch en verandert voortdurend naarmate het team meer inzicht krijgt in de vereisten en de voortgang van het project.

Dit is geen statische lijst; telkens komen er nieuwe items bij of veranderen er items. De Product Owner zorgt ervoor dat wat het hardst nodig is en wat het snelst een werkend product kan opleveren, bovenaan de Product Backlog komt te staan.

De items op de lijst zijn zo gedetailleerd mogelijk. De Product Backlog is gegroepeerd: items die bij elkaar horen, staan ook bij elkaar.

Er zijn functionele requirements. Die benoemen de functionaliteiten in de software. Hiernaast zijn er ook de niet-functionele requirements. Denk bijvoorbeeld aan de snelheid waarmee iets werkt in een programma. Of de grootte van de kans dat er een fout optreedt. Het is belangrijk dat deze in de Product Backlog zo helder mogelijk worden weergegeven.

De items die bovenaan de lijst staan, moeten voor het team concreet en helder zijn. De items die verderop in de Product Backlog staan, hoeven nog niet concreet beschreven te zijn. In de Product Backlog staat wat er moet gebeuren, niet hoe.

In de Product Backlog kun je ook zien wat er allemaal nog moet komen. Dus wat het product uiteindelijk moet kunnen.

Een goed beheerde Product Backlog is van cruciaal belang voor het succes van een project. Het zorgt ervoor dat het team de juiste items aanpakt in de juiste volgorde en stelt het team in staat om snel te reageren op veranderingen en feedback. Het is belangrijk dat het Development Team en de Product Owner nauw samenwerken om ervoor te zorgen dat de items op de Product Backlog in overeenstemming zijn met de doelstellingen van het project.

Sprint

Als alles voorbereid is, gaat het team aan het werk. Er wordt gewerkt in periodes van drie weken. Zo’n periode noem je een sprint. In elke sprint wordt gewerkt aan een of meer nieuwe functionaliteiten. Dus in élke periode wordt er minimaal één werkend, getest product opgeleverd.

op de volgende slides worden de afzonderlijke onderdelen besproken van een sprint

Kick-off

Op maandagmorgen presenteert de Product Owner de backlog aan het team. Hij neemt de bovenste, en dus belangrijkste, items van de Product Backlog. Die komen in overleg met het team in de sprint backlog. Het hele team is bij die presentatie aanwezig. De teamleden stellen net zolang vragen aan de Product Owner totdat ze precies weten wat er verwacht wordt.

Planning

Daarna gaat het team het werk voor de komende drie weken plannen. Alle backlog-items worden opgedeeld in taken van enkele uren, niet meer. We noemen dat work-items.
Grote taken worden gesplitst in kleinere taken: taken die in korte tijd – maximaal drie weken – gemaakt kunnen worden. Alleen... soms is het moeilijk om een grote taak te splitsen. Dat komt meestal omdat niet duidelijk is wat die taak inhoudt. De Product Owner kan dan nog meer informatie geven over die taak, zodat het team beter kan overzien wat er verwacht wordt waarna het team de taak alsnog kan splitsen.
Het komt regelmatig voor dat een teamlid denkt dat een taak binnen vier uur kan worden afgerond terwijl een ander meent dat dit veel meer tijd kost. Door samen te overleggen kom je tot overeenstemming.

Voortgang

Als hulpmiddel gebruikt het team een groot A1 vel,  verdeeld in drie vakken: to do, doing en done.Dit vel wordt het scrumbord genoemd.

Alle work-items worden op een post-it geschreven en in het vak ‘to do’ op het scrumbord geplakt. Voor iedereen is dan zichtbaar dat er een heleboel werk wacht.

Iemand pakt een post-it uit het to do-vak en plakt dat in het vak doing. Telkens als een work-item gereed is, wordt de post-it naar het vak done verplaatst. Je ziet zo al snel vorderingen.

Daily Scrum

In de Daily Scrum sessies delen teamleden wat ze gedaan hebben, wat ze vandaag gaan doen en of er problemen zijn.

Ieder teamlid moet drie vragen beantwoorden:

Wat heb ik bereikt?
Wat ga ik bereiken?
Wat blokkeert me?

Explain wat de daily scrum is en hoe het gebruikt wordt.

• Wat heb ik bereikt? je vertelt welke work-items je af hebt gekregen of waar je nog mee bezig bent en hoe dat is gegaan.
• Wat ga ik bereiken? je vertelt welke work-items voor de volgende meeting wil gaan doen.
  
• Wat blokkeert me? nu heb je de mogelijkheid om problemen te noemen die je ziet aankomen. Misschien is er een kans dat de sprint niet op tijd gereed kan zijn of misschien heeft een teamlid een probleem waar hij geen oplossing voor heeft.
  

Op al die vragen kunnen de andere teamleden inspelen. Vooral bij de laatste vraag kunnen de teamleden wat voor elkaar betekenen. Misschien weet niemand direct een oplossing maar misschien bedenkt iemand daarna een oplossing.

Door deze manier van werken wordt transparant waarmee iedereen bezig is. Omdat iedereen aan hetzelfde product werkt, is dat erg waardevol. Luieren valt natuurlijk ook direct op. Het kan wel eens tegenzitten, maar dat moet niet telkens het geval zijn. Dan kun je verwachten dat daar kritiek op komt. Die kritiek komt dan van je medeteamleden, niet van je docent. Want je bent als team verantwoordelijk voor het resultaat.

Sprint review

Aan het einde van de drie weken is de sprint backlog leeg en het product klaar. Het team is daar trots op. Je laat dat aan elkaar zien tijdens een speciale bijeenkomst, de sprint review. Een sprint review is altijd feestelijk. Vaak is er een traktatie en iedereen kan even opgelucht ademhalen. Met elkaar heeft het team de klus geklaard! De Product Owner kan het product laten zien.

Het is belangrijk wat de opdrachtgever van het product vindt. De Product Owner zorgt ervoor dat alle reacties van de opdrachtgever bij het team bekend worden zodat daar op ingespeeld kan worden. Uiteraard in een nieuwe sprint.

Retrospective

Na de sprint review is er nog één bijeenkomst voordat de sprint afgesloten kan worden, de retrospective. Tijdens deze bijeenkomst kijk je met het hele team naar zaken die goed liepen en naar zaken die niet goed liepen. Voor beide zijn er acties nodig. Het zal duidelijk zijn dat er voor zaken die niet goed gingen, verbeteracties opgesteld moeten worden. Maar ook voor zaken die wel goed liepen moeten er acties opgesteld worden. Want je wilt dat de zaken die goed liepen, goed blijven verlopen. In een volgende sprint zullen de geformuleerde acties aan de orde komen.

Praktisch voor jullie project

Scrum Master en Product Owner
Bij een schoolproject zal de docent vooral de rol hebben van Scrum Master. Hij zorgt ervoor dat jullie kunnen werken, dat de juiste software geïnstalleerd is en dat jullie de beschikking hebben over de juiste materialen om te scrummen, zoals post-its, stiften enz.
Een iemand van je groep maak je de Product Owner. Dit groepslid heeft het meeste contact met de docent, als jullie opdrachtgever.
Sprints
Bij een echt scrumproject duren de sprints meestal ongeveer 3 weken. Dit kun je op school ook prima doen. Je complete project zal dan in totaal 2 of 3 sprints hebben. Bepaal vooraf met elkaar de doelen die je voor het einde van iedere sprint hebt.

Scrumbord
Een scrumbord hoort er zeker ook bij.
Sprint review en retrospective
Ook bij het schoolproject kun je de sprint review en de retrospective prima houden. Aan het einde van de sprint lever je het deelproject in en bespreek je het met je docent. In de retrospective kijken jullie met elkaar terug op de afgelopen weken. Welke dingen gingen goed, en welke dingen ga je in de volgende sprint anders aanpakken?

Conclusie

Tot slot: Scrum is een techniek om samen producten te maken. De scrum master is de verantwoordelijke, de Product Backlog is de lijst met items, sprints zijn periodes om items af te ronden en de Sprint Review en Sprint Retrospective zijn sessies om te evalueren wat er is gebeurd.

Sluit de les af met een korte samenvatting van wat je geleerd heb.

Aan het begin van de sprint, tijdens de kick-off, bedenk je met je groep welke taken jullie tijdens deze sprint allemaal gaan uitvoeren. Die taken schrijf je op post-its en plak je in het vlak TO DO.

Als je tijdens de sprint een taak gaat uitvoeren, plak je de post-it waar die taak op staat in het vlak bij DOING. Zo is het voor iedereen duidelijk welke taken er op dat moment gedaan worden. Is de taak helemaal klaar, dan plak je de post-its bij DONE.

Zo heb je een mooi overzicht welke taken er nog gedaan moeten worden, aan welke taken er nu wordt gewerkt, en welke taken inmiddels klaar zijn.

Je kunt deze basis van het scrumbord verder uitbreiden. Bijvoorbeeld met verschillende categorieën.

Voorbeeld

Stel je voor dat jullie groepje een game maakt. De taken vallen dan onder andere in de volgende categorieën:
Game design (zoeken/maken graphics/sounds, bedenken lay-out, storyline)
Coderen (doen van tutorials, programmeren)
Overig (planning/document bijwerken/ sprintdoelen/website)
Je kunt deze categorieën overnemen op het scrumbord. En eventueel een aparte kleur post-it per categorie gebruiken.

Je kunt je scrumbord eventueel nog verder uitbreiden met een backlog. Een plek op het scrumbord waarin je alle taken van het hele project op post-its plakt. Als je tijdens een sprint iets nieuws bedenkt, wat je in een volgende sprint kunt ontwikkelen, plak je deze taak in de backlog.

Aan het begin van de sprint, tijdens de kick-off, bekijk je met elkaar de backlog. Welke taken gaan jullie in deze sprint uitvoeren? Die plak je dan bij TO DO.