SCRUM

Versie: 1.1

Laatste Update: 10-08-2012

Afdrukken: 2 dia’s per pagina

ONDERWERPEN CURSUS

Introductie

• Even Kennismaken & Warming up

De kenmerken van Scrum

• De verschillen tussen Scrum en de traditionele benadering

• De toegevoegde waarde van Scrum

• De belangrijkste rollen, producten en deliverables in een Scrum project

• Samenwerken in een team volgens Scrum

Praktijk

• Specificeren, prioriteren, ontwerpen en plannen volgens Scrum

• De Scrum meetings

• Vullen van de product backlog

• Daily Scrum meeting

• Sprint Review

• Retrospective

2

WARMING UP : OLD SKOOL

3

Maak een Naambordje

WARMING UP: ZO KAN HET OOK

4

Als spreker wil ik graag naambordjes zien van alle

deelnemers, zodat ik ze persoonlijk kan

aanspreken

Kennismaken& Warming Up

5

Welke vragen zou je vandaag beantwoord willen zien?

WAAROM MISLUKKEN SOFTWARE -PROJECTEN VAAK?

• Slechte of verouderde specificaties;

• Te weinig communicatie met de klant;

• Slechte of geen betrokkenheid van de belangrijkste stakeholders;

• Ontwikkelaars die aan veel projecten tegelijk moeten werken;

• Prioriteiten wijzigen gedurende het project;

• Onrealistische tijdsschema's;

• Te krappe budgetten;

• rapportage eisen die resulteren in veel onnodig geschuif met papier;

• Geen commitment van het management;

• Bron: http://www.computable.nl/artikel/nieuws/outsourcing/2350343/1276946/waarom-softwareprojecten-mislukken.html#ixzz1orNvA4Ag

6

De Praktijk

7

Wat blijkt er uit onderzoek

8

9

10

13

KENMERKEN WATERVAL -BENADERING

• Ontstaan in de jaren 70

• Opdelen van een project in fasen.

• Pas als een voorgaande fase is afgesloten kan aan een

volgende fase worden begonnen.

• Beperkt mogelijk om terug te keren naar een voorgaande

fase.

• Elke fase wordt uitvoerig gedocumenteerd in een

mijlpaalrapport.

• De gebruikers zijn alleen aan het begin en aan het einde

van een project betrokken.

15

16

NADELEN WATERVAL -BENADERING

• Star, er kan moeilijk worden ingespeeld op nieuwe ontwikkelingen tijdens een project.

• Fasen zijn groot, daardoor moeilijk om tijd en kosten in te schatten.

• Ontwerpers, bouwers, gebruikers en opdrachtgever zijn gescheiden, ze werken niet in één team.

• Veel nadruk op documentatie.

• Testen komt pas in de acceptatie-fase.

• De gebruikers worden niet actief betrokken.

• Lange doorlooptijd, groot risico dat gaandeweg eisen veranderen.

17

VOORDELEN VAN SCRUM

• Meer betrokkenheid van de belangrijkste stakeholders, omdat ze deel uit maken van het ontwikkelteam.

• Meer commitment bij de opdrachtgever, omdat hij eindverantwoordelijk is voor het beheren van de Product Backlog en hij er daarmee voor verantwoordelijk is dat het Team bezig is met het werk dat het meest waardevol is.

• Veel contact en communicatie tussen opdrachtgever en team kanzorgen voor een verhoogde teamgeest.

• Het project wordt als geheel gezien in plaats van de verschillendeonderdelen als eilanden te beschouwen.

• Doordat er veel tegelijk gebeurt kan de doorlooptijd van een project korter worden dan bij andere methodes.

• Er kan eerder worden ingespeeld op problemen.

18

NADELEN VAN SCRUM

• Er is een cultuuromslag nodig om SCRUM succesvol toe

te kunnen passen, veel organisaties zijn daar nog niet aan

toe.

• Het gebruiken van een methodologie is nog geen garantie

voor succes.

• In bedrijfskritische omgevingen is SCRUM vaak moeilijk

toepasbaar omdat de specificaties vooraf leidend zijn.

• Het open-end karakter van SCRUM is voor veel

organisaties nog een brug te ver.

19

Mooi die theorie

20

Hoe gaat het in de praktijk werken?

AGILE MANIFESTO

Goede software wordt gemaakt door:

• Mensen en hun onderlinge interactie is beter dan

processen and tools.

• Werkende software is beter dan allesomvattende

documentatie.

• Samenwerking met de klant is beter dan

contractonderhandelingen.

• Inspelen op verandering is beter dan het volgen

van een plan.

21

AGILE MANIFESTO IN DE PRAKTIJK

• Centraal stellen van de stakeholders en hun

onderlinge interacties.

• Streven naar korte termijndoelen in een iteratief

proces.

• Direct contact met en betrokkenheid van gebruikers

en “business”.

• Flexibel kunnen reageren op wijzigingsvoorstellen

tijdens het project.

22

23

KENMERKEN AGILE

• Iteratief ontwikkelen

• Elke iteratie is als het ware een miniatuurproject op zichzelf.

• Communicatie

• Nadruk op directe communicatie, in plaats van geschreven verslaglegging.

• Voortschrijdend inzicht

• Specificaties komen gedurende het project tot stand en kunnen na iedere iteratie worden bijgesteld.

• Teamwork

• Een team waarin ontwikkelaars en degenen die het product definiëren.

• Test-driven development

• De ontwikkelaar produceert tegelijkertijd met de code een unittest waarmee hij aantoont dat de code klopt en werkt. Als de code wordt aangepast, wordt ook de unittest aangepast.

24

WANNEER AGILE -ONTWIKKELING?

Agile-methoden zijn geschikter naarmate de eisen nog vaag en

veranderlijk zijn. De geschiktheid voor Agile-ontwikkeling worden

afgemeten aan drie dimensies:

• Cultuur

• De cultuur van de organisatie moet openstaan voor discussie en

onderhandeling.

• Mensen

• Mensen moeten vertrouwd worden met de Agile-benadering en in een Agile-

project zijn minder maar competentere mensen nodig.

• Communicatie

• Organisaties moeten een omgeving hebben waarin snelle communicatie

tussen team-leden mogelijk is en moeten de beslissingen accepteren die

ontwikkelaars nemen.

25

AGILE-BESTAANSGROND

• Grote oplossingsruimte

• Senior ontwikkelaars

• Veranderlijke project-eisen

• Klein aantal ontwikkelaars

• Cultuur die in chaos gedijt

26

WATERVAL -BESTAANSGROND

• Duidelijke specificaties

• Veel junior ontwikkelaars

• Vaststaande project-eisen

• Groot aantal ontwikkelaars

• Cultuur die orde vereist

27

KENMERKEN VAN SCRUM

• Zelfsturende, multidisciplinaire teams;

• Ontwikkelling in korte sprints;

• Opleveren van werkende software na iedere sprint;

• een SCRUM-team wordt begeleid door de "scrum-master" en houdt eenzogenaamde “standup-meeting“;

• na deze meeting gaat de ontwikkelaar weer aan het werk om de opdracht af te ronden.

28

DOELSTELL INGEN VAN SCRUM

• Verhogen van de effectiviteit;

• Bewaken van de voortgang;

• Oplossen van blokkades bij de ontwikkeling;

• In kaart brengen en minimaliseren van de risico's.

29

30

31

SCRUM-WERKWIJZE

• In teamverband wordt het project opgepakt. Elk lid is betrokken bij het plannen, benoemen van blokkades en het verdelen van de taken.

• De Product Owner maakt samen met de klant en andere stakeholders een lijstvan de eisen en taken. Dit heet ook wel een ‘User Story’.

• De belangrijkste requirements worden als eerste opgepakt.

• Het team geeft vervolgens gezamenlijk, van elke User Story, een inschattingvan de hoeveelheid ontwikkelcapaciteit die nodig is.

• De story’s worden regelmatig met de opdrachtgever en het hele team besproken.

• Scrum is een iteratief proces, er wordt gewerkt in korte iteraties van 2 tot maximaal 4 weken, die ook wel ‘Sprints’ worden genoemd.

• In iedere Sprint moet een werkend stuk/product worden opgeleverd.

32

33

HET IDEALE TEAM VOLGENS SCRUM

• Verschillende disciplines;

• 5-9 mensen;

• Self-supporting;

• Self-organizing;

• Juiste focus;

• Samenwerking;

• Plezier in het werk.

34

35

ROL: PRODUCT OWNER

• Vertegenwoordiger van de klant

• Verantwoordelijk voor het vullen en de prioritering van de Product

Backlog.

• Geen traditionele (technische) productmanager die zich vaak vooral met

technische specificaties bezighoudt.

• Altijd één persoon,

• De hele organisatie moet de beslissingen van de product owner

respecteren.

• Moet een erg duidelijk beeld hebben van het te ontwikkelen product

Hij/zij moet dus goed op de hoogte zijn van de wensen en een

duidelijke visie hebben hoe deze tot uitdrukking moeten komen.

36

ROL: PRODUCT OWNER

• Een teamleider van de mensen van de werkvloer zou een goede Product Owner kunnen zijn, omdat hij goed inzicht heeft in de gewenste functionaliteit.

• Hij/zij heeft tenslotte iedere dag te maken met de huidige beperkingenwaarvoor een oplossing gezocht moet worden.

• Moet worden gesteund door het hoger management.

• Communicatief sterk persoon, die weet wat er speelt binnen de organisatie.

• Overlegt met stakeholders

• Voor het juist specificeren van de backlog items kunnen de stakeholders best in contact worden gebracht met het team.

37

ROL: SCRUM MASTER

• Procesbegeleider en facilitater van het team.

• Geen authoriteit binnen het Team, hij kan dus niet als projectmanager optreden

• 'Facilitator'; hij zorgt er voor dat het team niets in de weg staat om goed werk te kunnen verrichten

• Begeleidt het team, product owner en stakeholders tijdens de verschillende meetings

• Beschermt het team tegen externe invloeden en zorgt dat iedereen zichaan de regels houdt

• Schermt het team af van de Product owner en andere stakeholders, waardoor men zich volledig kan richten op de software ontwikkeling.

38

ROL: TEAMLID

• Een team is multidisciplinair en zelfsturend. Ze zijn in staat

om alle taken van ontwerp, realisatie, testen en de

oplevering te verzorgen.

• Een team bestaat uit 5 tot en met 9 deelnemers.

• Het team is verantwoordelijk voor zowel het inplannen als

het uitvoeren van het werk tijdens een Sprint.

• Het team is zelf verantwoordelijk is voor het werkproces.

• Door elke Sprint af te sluiten met een evaluatie wordt

continue gewerkt aan verbeteringen aan dit proces.

39

ARTEFACT: PRODUCT BACKLOG

De Product Backlog is een geprioriteerde lijst met al

het werk dat gedaan moet worden om een product of

een nieuwe release het levenslicht te laten zien.

Op de Product Backlog staan niet alleen functionele

en non-functionele producteisen, maar ook alle

stappen die bijvoorbeeld moeten worden gezet om

een product te lanceren, te kunnen verkopen, te

kunnen implementeren en te kunnen onderhouden.

40

ARTEFACT: SPRINT BACKLOG

• Takenlijst die het team in de Sprint moet afwerken.

• Items van de Product Backlog worden door het

team opgedeeld in taken tijdens de Sprint planning

meeting.

• Taken worden niet toegewezen, maar de

teamleden pakken zelf taken op die urgent zijn en

passen bij hun kennis en ervaring.

41

ARTEFACT: BURNDOWN

• Een grafiek die de voortgang tijdens de Sprint laat zien.

• Deze grafiek heeft twee lijnen, de beschikbare capaciteit en de benodigde capaciteit. Beide lijnen zijn tegen de tijd uitgezet.

• Zolang beschikbare en benodigde capaciteit gelijk oplopen weet het team dat de Sprint volgens plan verloopt.

• De Burndown wordt dagelijks bijgewerkt en is zichtbaar voor iedereen.

42

MEETING : SPRINT PLANNING

• Elke Sprint begint met een Sprint planning meeting.

• In deze meeting bespreekt de Product Owner het werk dat

hij graag gedaan wil hebben door het team.

• Vervolgens selecteert het team de items van de backlog die

in één Sprint opgepakt kunnen worden. Deze items worden

door het team uitgewerkt in taken en die taken worden van

een inschatting voorzien.

• Het resultaat is een Sprint plan dat in korte tijd van 1 tot 4

weken uitgevoerd kan worden waarbij er een werkend

increment wordt opgeleverd.

43

MEETING : DAILY SCRUM

Een korte dagelijkse meeting van 15 minuten.

Het doel is zorgen dat iedereen zo effectief mogelijk bezig is.

Iedereen blijft staan en beantwoordt de volgende 3 vragen:

• Wat heb ik gedaan sinds de vorige meeting?

• Wat ga ik doen tot de volgende meeting?

• Welke issues heb ik en welke hulp heb ik daar bij nodig?

44

MEETING : SPRINT REVIEW

• In de Sprint Review wordt het resultaat van de Sprint gepresenteerd.

• Het team laat met een demo aan de Product Owner en andere stakeholders zien dat het product echt werkt en voldoet aan de definition of done.

• Het doel van deze meeting is te laten zien dat er voortgang gemaakt is.

• Voor de Product Owner is dit een belangrijk moment om feedback te krijgen van andere stakeholders.

45

MEETING : RETROSPECTIVE

• De Sprint wordt afgesloten met de Retrospective.

• Tijdens deze meeting kijkt het team terug op het

werkproces in de afgelopen Sprint.

• Alles wat goed ging moet in ieder geval worden

behouden of verbeterd.

• Alles wat niet goed ging moet worden aangepakt,

zodat in volgende Sprints niet dezelfde fouten

gemaakt kunnen worden.

46

47

48

Het start met een visie : Een Product Visie

PRODUCT V IS ION

Een SCRUM-traject begint met een gezamenlijke visie op het eindproduct, de Product Vision. De Product Vision is een schets van het toekomstige product dat wordt ontwikkeld.

Het beschrijft:

• Voor wie het product is bestemd;

• De primaire klantbehoefte die het vervult;

• De (maximaal zes) kenmerken die het product succesvol zullen maken;

• Hoe het product zich van andere producten onderscheidt;

• Hoe het bedrijf geld gaat verdienen met het product.

Een goede Product Vision is kort, helder en enthousiasmerend. Het is de taak van de Product Owner om er voor te zorgen datiedereen de Product Vision begrijpt en onderschrijft.

49

50

Het project wordt een succes omdat:

1._________________________

2._________________________

3._________________________

4._________________________

5._________________________

6._________________________

VULLEN VAN DE PRODUCT BACKLOG

• De Product Backlog is een lijst met geprioriteerde high-levelrequirements.

• De Product Owner is verantwoordelijk voor het vullen van de Product Backlog (samen met de stakeholders en het team).

• In eerste instantie worden alleen de requirements uitgewerkt die het team in de eerste sprint gaat implementeren.

• Het opstellen van de eerste versie van de visie en de product backlog hoeft niet langer dan 2 weken te duren.

• De Product Backlog wordt daarna veelvuldig getoetst en aangepast aan de actuele situatie en behoeften van de business. Ook dit is de verantwoordelijkheid van de product owner.

51

USER STORIES

• Items die in de Product Backlog staan. Ze beschrijven verzoeken van bijvoorbeeld klanten die nog gerealiseerd moeten worden.

• Het grote verschil met de klassieke requirements is dat User Stories beschrijven waarom iets gedaan moet worden.

• De reden of aanleiding is voor het team belangrijk om tot een passende oplossing te komen.

• Daarnaast kunnen er acceptatie voorwaarden of een demo script bij de User Story opgenomen worden.

• Hoe de oplossing er precies uit moet zien, wordt door het team gedurende de Sprint bepaald.

52

DE EERSTE SPRINT PLANNING MEETING

• Tijdens eerste Sprint Planning Meeting, geeft de Product Owner een toelichting op de Product Backlog Items met de hoogste prioriteit.

• Het team schat in hoeveel items ze in de eerste sprint kunnen implementeren en vragen daarbij nadere toelichting over de requirements aan de Product Owner.

• Vervolgens worden de requirements 'sprint ready' gemaakt. Dit wil zeggen het opsplitsen van Product Backlog Items totdat ze zo klein zijn dat het team ze in enkele dagen kan implementeren.

• Bij het 'sprint ready' maken heeft de product owner de medewerking van het team nodig. Vaak gebeurt dit in planningpoker sessies.

53

SPRINT PLANNING IN 2 DELEN

De sprint planning gebeurt in 2 delen:

1. Wat moet er gebeuren?

• Requirement workshop

• Team samen met Scrum Master en Product Owner

2. Hoe moet het worden gemaakt?

• Design workshop

• Team

• Product Owner moet wel beschikbaar zijn voor vragen

54

PLANNING POKER

Een simpele methode die binnen Scrum wordt gebruikt tijdens de planningsessie aan het begin van een Sprint. In het kort gaat het als volgt:

1. De Product Owner licht een user story toe

2. De teamleden stellen vragen en bepalen de benodige taken

3. De Scrummaster vraagt vervolgens alle teamleden een kaart te kiezen en geeft een signaal waarop alle teamleden deze kaart open op tafel leggen.

4. De teamleden met de hoogste en de laagste schatting leggen uit hoe ze tot hun keuze gekomen zijn.

5. Vervolgens worden stap 3 en 4 herhaald net zo lang tot er consensus ontstaat over de schatting, de Scrummaster kan deze bij de user story noteren en het hele proces kan herhaald worden voor de volgende user story.

55

DEFIN IT ION OF DONE

• Beschrijft waar het resultaat van een Sprint aan

moet voldoen.

• Is een hulpmiddel voor het team om de kwaliteit

van het werk constant te houden.

• Wordt door het team zelf opgesteld en beschrijft

dingen als testen, unittesten, documentatie enz.

56

TEAM VELOCITY

• De hoeveelheid werk die het team in één Sprint kan

wegwerken.

• Tijdens elke Sprint wordt de hoeveelheid werk bijgehouden.

• Op basis van deze Velocity kan het team inschatten

hoeveel werk het per Sprint aankan.

• Naarmate een team meer ervaring heeft en beter op elkaar

is ingespeeld, zal de velocity toenemen.

57

SPRINT

• Scrum is een iteratieve methode.

• Elke iteratie wordt een ‘Sprint’ genoemd. Een Sprint duurt 2 tot maximaal 4 weken. Binnen deze tijd pakt het team een vooraf geselecteerde hoeveelheid werk op dat helemaal afgemaakt wordt.

• Het resultaat van elke Sprint is een stukje werkende software. Daardoor is het product snel bruikbaar en krijgt het team snel feedback op het product en het proces.

• Het team wordt tijdens de Sprint gefaciliteerd door de Scrum Master, die er ook voor zorgt dat er geen wijzigingen plaats vinden die het Sprint doel beïnvloeden.

• Zowel de samenstelling van het team als de kwaliteitsdoelstellingen blijven constant gedurende een sprint.

58

59

BURNDOWN CHART

• Een grafiek die de voortgang gedurende de Sprint laat zien.

• Er zijn twee Burndowns:

• Release Burndown: meet de resterende Product Backlog tegen de looptijd van een release (als onderdeel van een release plan).

• Sprint Burndown: meet de resterende Sprint Backlog tegen de looptijd van een Sprint.

• De Burndown heeft twee lijnen, de beschikbare capaciteit en de benodigde capaciteit.

• Zolang beschikbare en benodigde capaciteit gelijk oplopen weet het team dat de Release/Sprint volgens plan verloopt.

• De Burndown wordt dagelijks bijgewerkt en is zichtbaar voor iedereen.

60

61

DAILY SCRUM

Elk Team komt dagelijks 15 minuten bij elkaar gedurende een bijeenkomst

genaamd de Daily Scrum. De Daily Scrum vindt elke dag plaats op

dezelfde tijd en op dezelfde locatie gedurende de Sprints.

Tijdens de bijeenkomst legt elk teamlid uit:

1. Wat hij of zij heeft bereikt sinds de vorige bijeenkomst;

2. Wat hij of zij gaat doen tot aan de volgende bijeenkomst; en

3. Welke belemmeringen hij of zij heeft die dat in de weg staan.

62

AAN HET E INDE VAN DE SPRINT

Sprint Review• Aan het eind van een Sprint wordt een Sprint Review gehouden.

• Dit is een timebox van vier uur voor een Sprint van een maand.

• Tijdens de Sprint Review bekijken het Scrum Team en de belanghebbenden

wat er is gedaan.

• Op basis daarvan en op basis van aanpassingen aan de Product Backlog

gedurende de Sprint wordt bepaald wat er vervolgens gedaan zou kunnen

worden.

Retrospective• Na de Sprint Review en voorafgaand aan de volgende Sprint Planning heeft het

Team een Sprint Retrospective bijeenkomst.

• Dit is een drie uur durende timebox voor vier wekelijkse sprints.

• In deze bijeenkomst moedigt de ScrumMaster het Team aan om het

ontwikkelproces, binnen de grenzen van het Scrum proces raamwerk en

werkwijze, aan te passen om dit effectiever en plezieriger te maken voor de

komende Sprints.

63

NIEUWE SPRINT?

Sprint-demo• Elke sprint eindigt we met een sprint-demo waar alle stakeholders zijn

uitgenodigd om het resultaat te bekijken.

• Hier kunnen ook mensen die niet direct bij het project betrokken zijnfeedback geven op het geleverde resultaat.

• Dit kan als input dienen voor de volgende sprint.

Opleveren of nog een sprint?• Aan het einde van de sprint zijn de user-stories helemaal gereed en,

afhankelijk van de sprint, opgeleverd in de test- of live-omgeving.

• Zijn er nog user-stories over dan kan de Product Owner besluiten eenvolgende sprint in te plannen.

• De overgebleven user-stories worden aangevuld en opnieuw ingedeeldop prioriteit.

64

WEBSITES

www.agilemanifesto.org

www.agileconsortium.nl

www.agile.startpagina.nl

www.agilealliance.org

www.scrumalliance.org

66