Het onderstaande plaatje geeft het verloop van een project aan. Het product bestaat uit een lijst van taken die gedaan moeten worden, de product backlog. Uit die product backlog wordt per sprint een sprint backlog gemaakt. Deze shortlist bepaalt de werkzaamheden van de betreffende sprint. Tijdens de sprint, die tussen de 2 en 4 weken lang is, worden de taken uit de shortlist opgepakt. Iedere dag wordt de dagelijkse Scrum meeting gehouden. Hierin wordt kort uitgesproken per teamlid wat gisteren gedaan is, wat vandaag gedaan wordt en wat de werkzaamheden in de weg staat. Aan het einde van de sprint wordt een potentieel op te leveren product opgeleverd.

clip_image001

Figuur 1: Verloop van een project

In dit artikel zal het Scrum process template van Scrum for Team System in de voorbeelden gebruikt worden. Dit process template bestaat uit de volgende work items:

· Bug

· Impediment

· Product Backlog Item

· Sprint

· Sprint Backlog Item

· Sprint Retrospective

Toepassen van Scrum

Release

Als een nieuw Scrum project gemaakt wordt, dan wordt standaard een set van template Releases en Sprints gemaakt, zoals het onderstaande plaatje laat zien.

clip_image001[4]

Figuur 2: Aangemaakte set van template Releases en Sprints

Releases hebben geen begin- en einddatum. Deze data worden uit de data gehaald die aan de Sprints gekoppeld zijn.

Sprint

Een Sprint Work Item Type bestaat uit de volgende velden:

· Sprint Name

· Capacity (hours)

· Sprint Start Date

· Sprint End Date

· Current Status

· Sprint Goal

· History

Sprint Backlog Item

Een Sprint Backlog Item Work Item Type bestaat uit de volgende velden:

· Title

· Area

· Sprint

· Estimated Effort (Hours)

· Team

· Task Priority

· Owned By

· Work Remaining (hours)

· Current Status

· Description

· History

· Links

· File Attachments

Een Sprint Backlog Item wordt gemaakt door het aan een Product Backlog taak als een gerelateerd work item toe te voegen. Op deze manier wordt de nieuwe Sprint Backlog taak automatisch gekoppeld aan de geselecteerde Product Backlog taak.

Sprint Retrospective

Er zijn drie typen items:

· What Didn't Go So Well - om vast te leggen van welke gebieden het team vindt waar het niet zo goed was als ze wilde.

· What We Can Do Better - acties of activiteiten die de probleemgebieden zouden kunnen helpen verbeteren.

· What Went Well - om aan te geven welke gebieden het team als positief tijdens de uitvoering heeft ervaren.

Het Work Item Type bestaat uit de volgende velden:

· Title

· Sprint Number

· Retrospective Type

· Team

· Individual

· Description

· History

· Links

· File Attachments

De spelers

clip_image001[6]

Figuur 3: De spelers

"Product Owner"

De "Product Owner" is verantwoordelijk voor de retun on investment (ROI) van het project. Vaak is dit een medewerker van de klant.

De taken:

· Definieert de features van het product en beslist over opleverdata en inhoud

· Verzamelt input van de gebruikers, stakeholders en andere geïnteresseerde partijen

· Is verantwoordelijk voor de return on investment

· Geeft prioriteiten aan de features aan de hand van de marktwaarde

· Kan features en prioriteiten elke 30 dagen wijzigen

· Accepteert of wijst werk resultaten af

"Team Members"

Rollen en taken samengevat:

· Multifunctioneel (tester, developer, DBA in één)

· Teamgrootte van 7 (+/- 2)

· Selecteren van het doel per iteratie en specificeren van werk resultaten

· Hebben het recht om alles binnen de grenzen van de projectlijnen te doen om het doel van de iteratie te halen

· Het team organiseert zichzelf en het werk

· Geven demonstraties van het werk resultaat aan de Product Owner en de stakeholders

"Scrum Master"

De "Scrum Master" is de persoon die verantwoordelijk is om er zorg voor te dragen dat het proces gebruikt wordt zoals het bedoeld is. De Scrum Master kan gezien worden als een vader, een coach en een scheidsrechter.

Een Scrum Master is een leider en facilitator en is verantwoordelijk voor:

· Het verbeteren van de productiviteit van het ontwikkelteam door creativiteit aan te moedigen en te ondersteunen

· Een hechte samenwerking tussen alle rollen en functies en het verwijderen van obstakels

· Het beschermen van het team tegen externe onderbrekingen

· Het zorgdragen dat het proces gevolgd wordt

· Het uitnodigen van de juiste mensen voor de daily scrum meeting, iteratie reviews en planning meetings

· Het verwijderen van obstakels tussen het ontwikkelen en de klant zodat de klant direct het ontwikkelen van de functionaliteit aanstuurt

· Het leren aan de klant hoe de return on investment gemaximaliseerd kan worden en hoe hun doelen bereikt kunnen worden door gebruik te maken van Scrum

· Het verbeteren van de ontwikkelmanieren en ontwikkelgereedschappen zodat iedere nieuwe increment van functionaliteit potentieel op te leveren is.

Specifieke onderdelen uitgelicht

Wanneer is een onderdeel klaar?

Het is belangrijk dat ieder lid in het team dezelfde definitie heeft van wanneer iets klaar is. Een goed uitgangspunt daarvoor is de volgende lijst:

· Code voldoet aan de standaarden

· Zinnige unit testen voltooien zoals verwacht

· Er is gerefactord

· Het is ingecheckt in source control

· Het 'built' met de rest van de code

· De kwaliteit is getest

Een Sprint Backlog Item kan van de "In Progress" status naar de "Done" status gezet worden. "Work Remaining" wordt dan direct op "0" gezet.

Hoe om te gaan met bugs

Bugs zijn van het zelfde niveau als Product Backlog Items en niet, zoals misschien verwacht, op het niveau van een Sprint Backlog taak. Een bug is een defect in een stuk code dat al eens de status van "Done" bereikt heeft. Zodra een defect onderkend is, wordt het als bug toegevoegd als nieuw werk. De bug wordt zichtbaar gemaakt door het toe te voegen aan de Product Backlog. De Product Owner bepaalt de prioriteit.

Toepassen van Scrum als process template - als developer

Na de beschrijving over het toepassen van Scrum als process template is de volgende stap het toepassen voor de developer. Wat zijn de stappen om het in een project toe te passen?

Hieronder het plaatje hoe Scrum verloopt als referentie.

clip_image001[8]

Figuur 4: Verloop van Scrum

Stap 1: Product Backlog

De product backlog is de verzameling van alle features voor het product. Deze items worden doorgaans in een User Story formaat geschreven. Dat wil zeggen dat het vanuit het oogpunt van de gebruiker geschreven wordt. De Product Owner is verantwoordelijk voor het beheer van de product backlog.

Prioriteit

De items in de product backlog moeten voorzien worden van een prioriteit. Items met een hoge prioriteit moeten gedetailleerder beschreven zijn en ook een preciezere tijdschatting krijgen. De prioriteiten worden door de Product Owner gesteld.

Items invoeren

Items zijn op twee manieren in te voeren. Enerzijds via Visual Studio door het toevoegen van een nieuw product backlog work item en anderzijds via Excel. Met Excel kan een connectie gelegd worden naar de Team Foundation Server. De eenvoudigste manier is vanuit de Team Explorer op de query "All Product Backlog Items" rechts te klikken en voor "Open in Microsoft Excel" te kiezen.

clip_image001[10]

Figuur 5: Item invoeren met Excel

In Excel is dan vervolgens de mogelijkheid om met "Publish" de nieuwe work items op te slaan in de Team Foundation Server.

clip_image001[12]

Figuur 6: Opslaan in TFS vanuit Excel

Stap 2: Sprint

Het project wordt in meerdere Sprints verdeeld. Een Sprint beschrijft wat er in die periode globaal aan werkzaamheden gedaan zal worden en wat het einddoel is. Het Sprint work item wordt gebruikt om Sprint Backlog items te groeperen. Een sprint duurt tussen de 2 en 4 weken. De duur is over het algemeen voor alle sprints gelijk en wordt vaak op 2 weken gelegd.

Toelichting op stap 2

Voor stap 2 is de duur op 2 weken gesteld. De reden hiervoor is dat dit een mooie lengte is om de werkzaamheden in uit te voeren. Binnen deze tijd is het minder snel mogelijk om terug te vallen op het doen van zogenoemde mini-watervallen. Het voordeel daarvan is, dat agile werken daardoor bevorderd wordt.

Daarnaast is de periode van 2 weken ook kort genoeg om tegen te gaan dat er iets ontwikkeld wordt, wat de klant niet voor ogen had. Het is minder erg om 2 weken werk over te doen.

Stap 3: Sprint Backlog

De lijst met Product Backlog items wordt verdeeld over verschillende sprints. Deze verdeling kan op verschillende manieren gedaan worden. Het eindresultaat van een sprint is een potentieel op te leveren product, dus de verdeling moet daar rekening mee houden. Verder is het handig om de features die eenvoudig te realiseren zijn in de eerste sprint te zetten. Het team heeft dan de kans om te wennen en in te werken. Deze lijst wordt de Sprint Backlog. Elk Sprint Backlog Item wordt als related work item toegevoegd via het bijbehorende Product Backlog work item. Het veld Sprint uit het work item wordt gevuld met de desbetreffende Sprint. Het is aan het team om de Sprint Backlog aan te maken en bij te houden.

clip_image001[14]

Figuur 7: Sprint Backlog Item

clip_image002

Figuur 8: Related work item

clip_image001[16]

Figuur 9: Sprint Backlog Item bijhouden

Toelichting op stap 3

De reden om in de eerste sprint de eenvoudige taken op te pakken, is al genoemd, namelijk inwerken en wennen. Ik wil hierbij benadrukken, dat dit een fijne manier van starten is. De druk is nog laag en de mogelijkheid om kennis op te doen over het op te leveren eindresultaat is dan nog zeer aanwezig.

Stap 4: Werkzaamheden tijdens de Sprint

Tijdens de Sprint zijn de developers met de Sprint Backlog work items aan de slag. Elke developer die een work item op pakt, verandert de status naar 'In Progress'. De werkzaamheden voor dat specifieke work item kunnen tijdens het inchecken aan het betreffende work item worden gelinkt. Zo worden de werkzaamheden gekoppeld, zodat later terug te vinden is welke code bij welke feature hoort. Als een item klaar is, kan de status naar 'Done' gezet worden.

Toelichting op stap 4

Een opmerking over sprints waarin te veel werk zit: dit wordt aan de Product Owner voorgelegd met het verzoek voor advies over welke items geschrapt kunnen worden uit de lopende Sprint.

Een opmerking over sprints waarin te weinig werk zit: dit wordt eveneens aan de Product Owner voorgelegd met het verzoek voor advies over welke items uit de Product Backlog toegevoegd zouden kunnen worden.

Een opmerking over sprints waarvan wordt ingezien dat deze niet haalbaar zijn: deze kunnen geannuleerd worden. Na het annuleren wordt een nieuwe Sprint Planning sessie gehouden.

Stap 5: Sprint afronden

Aan het eind van de sprint is het zaak dat alle ontwikkelde code getest is en de bugs opgelost zijn, zodat de Sprint Review kan plaats vinden. De Sprint Review bestaat uit het demonstreren van het product van de sprint door de teamleaden aan de Product Owner, klanten en eventueel management. Na de Sprint Review wordt er geëvalueerd waar in de volgende Sprint aan gedacht moet worden. Vervolgens kan de volgende Sprint weer beginnen met het samen stellen van de Sprint Backlog op basis van de verworven inzichten.

Stap 6: Release Sprint

Na een aantal Sprints is het product volwassen genoeg om daadwerkelijk opgeleverd te worden. Daar is de Release Sprint het geschikte moment voor. In deze Sprint wordt geen extra functionaliteit meer toegevoegd. De taken die wel binnen deze Sprint vallen zijn bijvoorbeeld:

· De code naar de productie omgeving deployen

· Productie data vullen

· Rollback scenario

Het team is verantwoordelijk voor het opleveren van het product.

Toelichting op stap 6

Het uitvoeren van een Release Sprint is niet een eenmalige sprint, waarna het product klaar is. Het is veel interessanter om het product, zodra het mogelijk is, al op te leveren. Het is voor de Product Owner aan te raden om te streven naar "early & often" release sprints. Oftewel zo snel als mogelijk en zo vaak

als mogelijk het product opleveren. Dit levert naast mogelijk Return on Investment ook reacties van gebruikers op. Deze kunnen toekomstige sprints beïnvloeden. Ik kan dus niet genoeg benadrukken om dit toe te passen.

Conclusie

Early & often... Dat is waar het eigenlijk allemaal om draait. Scrum gaat er volledig over om alles zo vroeg mogelijk te communiceren, ontdekken, herkennen, erkennen, melden, bijschaven, aanpassen, omgooien en dat alles ook zo vaak mogelijk.

Om maar even een voorbeeld te nemen, situatie A:

Een ontwikkelaar vindt tijdens het project een methode om een bepaald probleem aan te pakken. Deze methode kost twee dagen om te implementeren. De ontwikkelaar meldt dit niet aan de andere teamleden, want hij is druk bezig. Andere teamleden zitten vervolgens te wachten op de oplevering van het deel van de ontwikkelaar en gaan wat anders doen of zijn zelf bezig om het probleem aan te pakken, aangezien het nog niet is opgelost.

Situatie B:

Een ontwikkelaar vindt tijdens een sprint een methode om een bepaald probleem aan te pakken. Deze methode kost twee dagen om te implementeren. De ontwikkelaar meldt dit tijdens de Scrum meeting. Andere teamleden kunnen direct profiteren van de methode voor eigen gebruik zodra deze klaar is, maar het is ook mogelijk om rekening te houden met eigen werkzaamheden die afhankelijk zijn het werk van de ontwikkelaar.

Als er "early & often" gecommuniceerd wordt, zoals in situatie B, kan het team meedenken en de werkzaamheden er op aanpassen.