Scrum (softwareontwikkelmethode)

Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken

Scrum is een flexibele manier om (software)producten te maken. Er wordt gewerkt in multidisciplinaire teams die in korte sprints, met een vaste lengte van 1 tot 4 weken, werkende (software) producten opleveren. Scrum is een term die afkomstig is uit de rugbysport. Bij een scrum probeert een team samen een doel te bereiken en de wedstrijd te winnen. Samenwerking is heel belangrijk en men moet snel kunnen inspelen op veranderende omstandigheden. Scrum wordt veel gebruikt bij producten waarvan de klant / gebruiker nog niet goed weet wat hij wil en waarbij men al doende leert om de eisen en wensen beter te beschrijven en in bruikbare producten om te zetten. Vaak weet men pas wat men wil als men het eerste product, het prototype, ziet en dan worden alsnog de eisen aangepast. Scrum heeft de flexibiliteit om met laat wijzigende eisen en wensen om te gaan. Scrum valt onder de Agile-softwareontwikkeling.

Geschiedenis[bewerken]

Scrum werd geïntroduceerd in een onderzoek door Ikujiro Nonaka en Hirotaka Takeuchi, dat begin 1986 in de Harvard Business Review gepubliceerd is. In dit onderzoek wordt beschreven dat projecten met kleine (multidisciplinaire) teams historisch gezien het beste resultaat leveren. Naar aanleiding van dit onderzoek ontwikkelde Jeff Sutherland in 1993 het scrumproces, terwijl Ken Schwaber een eigen benadering bij zijn bedrijf toepaste. Samen werkten ze dit verder uit en in 1995 formaliseerde Ken Schwaber scrum als softwareontwikkelmethode. Scrum is ontwikkeld in de USA en wordt veelal gebruikt in deels Engelstalige projecten, vandaar de Engelse terminologie.

Scrum methode

Doelstellingen[bewerken]

  • In korte sprints snel werkende producten opleveren, waardoor snel duidelijk wordt of men goed bezig is. Dit beperkt de risico's van langere projecten waarvan soms pas na een jaar gebruikers / klanten iets kunnen zien / testen.
  • Snel duidelijkheid over de voortgang.
  • Korte lijnen, snelle communicatie, teamwerk.
  • Grotere betrokkenheid teamleden, concentratie op overzichtelijk deel van project

Uitgangspunten[bewerken]

Scrumprojecten hebben de volgende uitgangspunten:

  • Toewijding: de leden moeten zich er vol voor inzetten; het is geen part-time klus.
  • Focus: men moet zich focussen op wat er in de sprints gedaan moet worden.
  • Openheid: men moet elkaar goed op de hoogte houden van de voortgang en mogelijke problemen.
  • Respect: men moet mensen met een andere achtergrond en expertise respecteren.
  • Lef: men moet lef hebben om zaken te benoemen, vragen te stellen en met nieuwe oplossingen te komen.

Werkwijze[bewerken]

Bij scrum worden de experts bij elkaar in één team gezet, bij voorkeur ook in één ruimte, zodat er makkelijk kan worden samengewerkt. Het team wordt begeleid door een "scrummaster", die zorgt dat het team zich aan de (scrum)regels houdt en kan doorwerken. De product-owner is de klant en voor hem/haar wordt het product gemaakt. Hij geeft ook aan wat er gemaakt moet worden. Dat gebeurt in de vorm van userstories (een soort eisen en wensen (requirements)). Deze user-stories staan op een lijst, de productbacklog. De productbacklog is door de product-owner gesorteerd op belangrijkheid. De belangrijkste user-stories staan bovenaan. De belangrijkste user-stories worden opgenomen in de sprint backlog, dat is wat men in de sprint wil gaan doen. De sprint wordt ook wel de iteratie of de scrum genoemd. In korte sprints worden de user-stories door het ontwikkelteam in kant en klare producten omgezet, inclusief documentatie en (integratie)tests. Het is dus in principe helemaal af. Aan het einde van elke sprint wordt het gewijzigde/verbeterde (software)product in de "Demo" aan de product-owner getoond. Daarna volgt nog een evaluatie waarin het team probeert lessen te trekken uit de afgelopen sprint, zodat men steeds beter wordt.

Rollen[bewerken]

Bij Scrum kent men de volgende drie hoofdrollen:[1] plus nog wat "hulp" rollen. De hoofdpersonen (rollen) worden pigs (varkens) genoemd en de overige rollen chickens (kippen). Deze rollen komen uit de fabel van de kippen en het varken (Chicken and the Pig) die een uitsmijter gaan maken. De varkens zijn meer betrokken bij het proces dan de kippen; vandaar. [2]. Zo kent men ook een haan; maakt een boel lawaai maar je hebt er niets aan. De hoofdrollen zijn:

Product-Owner
De Product-Owner (product eigenaar) is de opdrachtgever / klant. Hij heeft het meeste belang bij het (software)product dat gemaakt wordt. Hij zorgt dat de rekening betaald wordt. Hij / zij beheert ook de product backlog, hij bepaalt wat er moet gebeuren en in welke volgorde. In principe wordt begonnen met het belangrijkste, waar het meeste voordeel mee te behalen is, wat boven aan de product backlog staat.
Ontwikkelteam
Het ontwikkelteam is multidisciplinair samengesteld en is verantwoordelijk voor het afleveren van het (software)product aan het einde van elke sprint. Het team bestaat meestal uit 3 tot 9 personen. Het team organiseert zichzelf. Zij doen de analyse, ontwerp, ontwikkeling, test en documentatie en zorgen dat er aan het eind van de sprint een kant en klaar product is, dat in principe in productie genomen kan worden.
Scrummaster
De Scrum Master begeleidt / helpt het team door te zorgen dat het juiste scrumproces gevolgd wordt. Hij verzorgt ook eventuele trainingen. De scrummaster regelt alle vergaderingen. Ook regelt hij de voorzieningen zoals een werkruimte, hardware en software. De scrummaster zorgt ervoor dat het team niet lastig gevallen wordt door derden die met extra eisen tussendoor komen of die bijvoorbeeld tijdelijk mensen nodig hebben uit het team. De scrummaster is geen projectmanager. Hij regelt bijvoorbeeld niet de personele zaken zoals selectie, beoordeling en beloning van de mensen. Dit bevordert de openheid en samenwerking.

Vergaderingen[bewerken]

Daily scrum[bewerken]

De daily scrum of stand-up: iedereen staat!

Elke dag is er de "Daily scrum" of "Stand-up". Deze vergadering heeft de volgende regels:

  • Alle leden van het ontwikkelteam hebben zich voor de vergadering voorbereid.
  • De vergadering start precies op tijd, ook als niet iedereen aanwezig is.
  • De vergadering is elke dag op precies dezelfde tijd en plaats, meestal 9:00 uur in de projectkamer.
  • De vergadering duurt maximaal 15 minuten, korter mag ook. De vergadering wordt staande gehouden: "stand-up", zodat het daardoor al eenvoudig tot 15 minuten wordt beperkt. Vergelijkbaar met een overleg tussen sporters aan het begin van bijvoorbeeld een rugbywedstrijd.
  • Bezoekers zijn welkom maar normaal gesproken spreken alleen de leden van het ontwikkelteam, de scrummaster en product-owner.
  • Normaal gesproken houdt men een rondje waarbij elk teamlid drie vragen beantwoordt:
    • Wat heb je gedaan?
    • Wat ga je doen?
    • Zie je ook problemen/uitdagingen (impediments), heb je hulp nodig, zijn er dingen die voor andere teamleden van belang zijn? De vergadering mag maximaal 15 minuten duren dus grotere problemen worden buiten de vergadering verder besproken. De vergadering is net lang genoeg om één kopje koffie, staande, op te drinken.

Backlog refinement[bewerken]

De user stories die op de backlog staan moeten gemaakt worden en verder uitgewerkt en daarom is het belangrijk om goed te begrijpen van de product-owner en via hem van de rest van de organisatie, wat hij nu precies wil.

Zaken die in eerste instantie nog vaag zijn, zoals een "gebruikersinterface ontwikkelen", of "management rapportages", kunnen mogelijk ook opgesplitst worden in kleinere beter behapbare onderdelen, zoals "gebruikersinterfaces voor verschillende groepen gebruikers", "financiële overzichten" en "commerciële overzichten".

Dit maakt het mogelijk om na te denken over de beste oplossing, zodat ook ingeschat kan worden hoeveel tijd het kost om dat te maken. Hierdoor wordt het ook mogelijk om acceptatiecriteria vast te leggen zodat er acceptatietests gemaakt kunnen worden. Mogelijk moet er zelfs nog aanvullend onderzoek gedaan worden in de vorm van zogenaamde "spikes".

Binnen de watervalmethode zou dit de analyse fase genoemd worden. Bij scrum heeft men dit overleg vrijwel wekelijks, gedurende het gehele project.

Dit proces is niet het belangrijkste scrum proces, maar is in de loop van de tijd toegevoegd om te zorgen dat de zaken op de back-log voldoende kwaliteit hebben (duidelijk genoeg zijn), om in de komende sprint opgenomen te worden. [3]

Scrum of scrums[bewerken]

Als er meerdere scrum teams zijn, is er ook een overleg tussen deze teams nodig. Het gaat dan om de punten waarop men met elkaar te maken heeft, interfaces etc. Dit overleg wordt normaal gesproken aansluitend op de daily scrum gehouden.

  • Elk team stuurt een vertegenwoordiger.

De agenda is ongeveer hetzelfde als bij de dagelijkse scrum, namelijk:

  • Wat hebben jullie gedaan sinds de vorige meeting?
  • Wat gaan jullie nu doen?
  • Gaat alles goed of hebben jullie problemen / vertraging?
  • Zijn er zaken die voor ons van belang zijn, waar we last van zouden kunnen hebben?

Sprint planning[bewerken]

Aan het begin van de sprint is er een sprint planning overleg. In principe worden de bovenste, belangrijkste user-stories van de product backlog in de sprint opgenomen, waarbij men zorgt dat het qua tijd zou moeten kunnen. Het ontwikkelteam moet ook duidelijk zeggen dat alles duidelijk is en dat zij denken dat het haalbaar is. Taken worden dan vervolgens nog verder binnen het ontwikkelteam verdeeld.

Demo[bewerken]

In de "Demo" wordt het product getoond dat af is. Eventueel wordt ook aangegeven wat niet gelukt is om af te krijgen deze sprint. De Demo duurt maximaal 4 uur. Het hele sprint team is aanwezig plus eventueel andere geïnteresseerden. Na afloop een borrel, is een goede gewoonte.

Evaluatie / Retrospective[bewerken]

De evaluatie is bedoeld om te leren van wat goed en fout ging met als doel om als team nog beter te worden. Alle teamleden zijn dan ook aanwezig. Het overleg duurt 3 uur en wordt geleid door de scrum master. Men maakt een rondje en iedereen zegt wat goed en fout ging. Men kan ook zeggen wat het meeste opviel of wat het moeilijkste was enz. Het is niet de bedoeling om mensen de schuld te geven van een vertraging.

Hulpmiddelen / Artifacts[bewerken]

Product backlog[bewerken]

De product backlog is een overzicht van de dingen die nog gedaan moeten worden. Dit wordt in andere software ontwikkelmethoden wel de requirements genoemd, de eisen en wensen. Het bestaat uit alles wat van belang is om mee te nemen in de sprint zoals eigenschappen, fouten uit vorige releases, niet functionele eisen zoals navigatie, kleur, "look en feel", snelheidseisen etc. De product-owner is de eigenaar van deze lijst en bepaalt de volgorde. In principe staan de belangrijkste bovenaan, maar ook een andere volgorde is mogelijk. Hierbij spelen zaken als risico, waarde voor de organisatie, datum waarop iets nodig is, wettelijke eisen, etc. De zaken op de lijst zijn normaal gesproken in de vorm van een user story. Hierin staat WAT er gemaakt moet worden WAAROM en voor WIE. Iedereen kan er dingen aan toevoegen, maar de product-owner is en blijft verantwoordelijk. Er staan ook ruwe schattingen bij van de waarde voor de organisatie en van de ontwikkelkosten. Voor het inschatten van de ontwikkeltijd kan gebruikgemaakt worden van wat binnen scrum "planning poker" genoemd wordt.

Sprint backlog[bewerken]

A scrum task board

In de sprint backlog staat wat er deze sprint wordt gedaan. De sprint backlog wordt samengesteld uit de bovenste items van de product backlog. Het ontwikkelteam bepaalt wat ze kunnen doen gebaseerd op hun snelheid in de vorige sprints.

Gebruikelijk is dat de items op de sprint backlog geschreven worden op post-its. Er zijn dan drie kolommen, "to do", "in progress", "done". Soms met een vierde kolom "testing". Zodoende is voor iedereen duidelijk hoe het ermee staat.

Het ontwikkelteam bepaalt zelf wie wat doet, of eigenlijk kiezen de leden zelf wat ze (kunnen en willen) oppakken van de todo-lijst. Dit bevordert dat het team zich ermee verbonden voelt, dat ze zich er voor willen inzetten, dat het hun product wordt.

Er kunnen na de start geen items meer toegevoegd worden aan de sprint, behalve door het ontwikkelteam zelf. Nadat de sprint klaar is wordt de Product Backlog nog eens tegen het licht gehouden en kunnen prioriteiten en dus de volgorde wijzigen.

Acceptatiecriteria / definition of done[bewerken]

In de "Definition of done" staat wat er is afgesproken over hoe men een product oplevert. Eisen over documentatie (Engelstalig), testen (getest door gebruikers en de afdeling beheer, op welke apparaten/webbrowsers), locatie (op de acceptatieomgeving), etc.

Verbetering / Increment[bewerken]

De "verbetering" (increment) is een lijst van alle gerealiseerde verbeteringen / veranderingen aan het product. Deze lijst wordt in elke sprint, aan het eind van de sprint bijgewerkt. Hierop staan alleen items die voldoen aan de "definition of done". Dit overzicht moet in een vorm zijn die bruikbaar is voor de klant / product-owner. De lijst kan nodig zijn om verdere investeringen in het project te verdedigen en om aan buitenstaanders / klanten / dealers / overheid, duidelijk te maken wat men tot nu toe bereikt heeft. Of deze lijst gebruikt en gepubliceerd wordt, ligt aan de product-owner.

Burn down[bewerken]

Dit is een voorbeeld van een "burn down chart" van een voltooide sprint. Men ziet wat er af is en wat er nog gedaan moet worden.

De burn down chart van de sprint hangt meestal aan de wand in de projectkamer. Op die manier is voor iedereen direct duidelijk hoeveel er nog gedaan moet worden. Doordat het dagelijks wordt bijgewerkt is direct duidelijk hoe het ervoor staat. Er zijn ook andere typen van "burn down charts" in gebruik, bijvoorbeeld de release burn down chart hierop staat hoeveel er nog gedaan moet worden voor de volgende release van het product (Er vanuit gaande dat een "release" in meerdere sprints gerealiseerd wordt). Ook bestaat er een alternative release burn down chart,[4] deze doet in principe hetzelfde, maar geeft extra de wijzigingen aan door het meer/minder werk, veroorzaakt door het voortschrijdende inzicht.

Begrippen[bewerken]

De volgende begrippen worden gebruikt in scrum:[5], en/of zijn bruikbaar om het geheel te begrijpen.

Scrumteam (Scrum Team)
Producteigenaar, scrummaster en ontwikkelteam
Producteigenaar (ProductOwner)
De verantwoordelijke voor de productbacklog, waarmee de prioriteiten van de belanghebbenden naar voren komen zodat het werk van het ontwikkelteam waarde heeft voor de organisatie.
Scrummaster
De verantwoordelijke voor het scrumproces, de persoon die ervoor zorgt dat alles goed loopt en men maximaal profiteert van de voordelen van scrum.
Ontwikkelteam
een groep van specialisten verantwoordelijk voor het ontwikkelwerk en de realisatie van een in principe kant en klaar product(uitbreiding).
Sprint burn down chart
Een grafiek waarmee de dagelijkse voortgang van de sprint wordt weergegeven.
Release burn down chart
Een grafiek waarmee wordt aangegeven wat er al van de productbacklog klaar is en wat er nog gedaan moet worden.
Productbacklog (Product backlog)
Een lijst met op een hoog niveau de eisen/wensen voor het product.
Sprintbacklog (Sprint backlog)
Een lijst met taken die tijdens de sprint moeten worden uitgevoerd.
Sprint
Een periode van 1 tot 4 weken waarin men een aantal zaken van de productbacklog oppakt. Dit is een time-box.
Spike
Een korte periode waarin in een time-box een onderzoek gedaan wordt. Bijvoorbeeld om een prototype te maken of te testen of iets mogelijk is.
Lichtkogel (Tracer Bullet)
Een lichtkogel (tracer bullet) is een spike waarmee men probeert te onderzoeken wat de mogelijkheden zijn van de gekozen projectarchitectuur, technologie en best practice. Het resultaat is een stukje programmatuur. Het is misschien de ontwikkeling van een klein onderdeel, maar het is geen wegwerp programmatuur. Het kan in het verdere proces gebruikt worden. Het is een "Proof of concept" en ook een "Prototype", bedoeld om inzicht te krijgen in de nieuwe architectuur, technologie en werkwijze. De naam komt uit het leger, daar gebruikt men lichtspoormunitie om het spoor van de kogels te volgen en eventueel de richting te corrigeren.
Taken
Aan het begin van de sprint worden de stories van de productbacklog uiteengerafeld tot taken. Aan een taak hangt een planning in uren. Een taak mag volgens de theorie maximaal 12 uur zijn, maar meestal spreekt men af dat taken maximaal een dag (8 uur) duren.
Definition of Done (DoD)
De afvinkcriteria waaraan iets moet voldoen om af / klaar te zijn. In veel gevallen is bijvoorbeeld een eis dat alle regressietests succesvol zijn afgesloten.
Velocity
De snelheid van het team, wat het team kan doen in één sprint. De snelheid kan worden berekend op grond van de gerealiseerde snelheid in vorige sprints, gemeten in story punten, met behulp van een burn down chart. Dit is een richtlijn voor het team en omgeving om goed in te kunnen schatten / plannen hoeveel men kan doen en wat men kan verwachten.
Impediment
(Obstakel) Alles wat in de weg staat van een efficiënt proces.[6]
Sashimi
Een rapport waarin is aangegeven dat iets "klaar" is.
Abnormal Termination
(Abort). Indien nodig kan de product-owner (producteigenaar) een sprint voortijdig stoppen.[7] De product-owner kan dit doen met input van het team, scrummaster of management. Het kan bijvoorbeeld zo zijn dat het management de sprint wil stoppen omdat externe omstandigheden het doel van de sprint niet meer nuttig maken. Als een sprint op deze manier gestopt wordt is het vervolg dat men in een vergadering uitlegt waarom dit nodig was, tevens is er dan weer een nieuwe "Sprint planning vergadering" om de volgende sprint te plannen.
ScrumBut
Een ScrumBut is een uitzondering op de "echte" Scrumwerkwijze, waarbij het team scrum heeft aangepast aan hun eigen behoefte.[8][9]
Pair programming
Het in tweetallen werken aan een programma/probleem. Dit is een intensieve samenwerking waarmee men van elkaar leert en samen iets probeert op te lossen wat te moeilijk is voor een persoon omdat kennis of vaardigheden ontbreken. Men kan hierbij gebruik maken van elkaars expertise.
Refactoring
Het opnieuw maken/ontwikkelen/programmeren van een bepaald onderdeel om het beter (onderhoudbaar) te maken.
Storypoint
Worden gebruikt in planning om de omvang van een klus (story) aan te geven. Door een bekende korte klus 1 of 2 punten te geven kunnen grote klussen ingeschat worden als bijvoorbeeld driemaal zo lang of tienmaal zo lang.
Timeboxing
Een methode waarbij men een afgesproken tijd, (time-box), neemt om iets te doen. Zodoende kan iets ook niet uitlopen. Men kan bijvoorbeeld voor het testen afspreken dat men drie dagen neemt om te zoeken naar fouten. Of men kan afspreken om per gebruiker twee dagen training te geven. Vergaderingen kunnen een begintijdstip en een eindtijdstip hebben.
Triangulation
Een planningsmethode waarbij men vanuit verschillende gezichtspunten tot goede schattingen hoopt te komen. Voornamelijk door met elkaar te praten over waarom men denkt dat iets een bepaalde tijd gaat duren.

Andere Agile methoden[bewerken]

Externe link[bewerken]

Bronnen / Referenties[bewerken]

  1. Gauthier, Alexandre. What is scrum. Planbox (August 17, 2011)
  2. The Scrum Guide Geraadpleegd op October 28, 2013
  3. Cho, L (2009). Adopting an Agile Culture A User Experience Team's Journey. Agile Conference: 416 . DOI:10.1109/AGILE.2009.76.
  4. USA. ontwikkeld door Mike Cohn. Mountaingoatsoftware.com Gearchiveerd van het origineel op September 9, 2012 Geraadpleegd op September 13, 2012
  5. Schwaber, pp. 141–143
  6. Little, Joe (January 17, 2011). Impediment Management (Agile Consortium).
  7. Ken Schwaber; Jeff Sutherland. The Scrum Guide
  8. ScrumButs and Modifying Scrum. Scrum.org Geraadpleegd op March 18, 2013
  9. Bloomberg, Jason. The Scrum But Paradox. DevX.com. QuinStreet (July 31, 2012) Geraadpleegd op March 18, 2013