Het schrijven van correcte programma’s, die onder alle omstandigheden doen wat ze moeten doen, is minder eenvoudig dan het lijkt. Dit is een ervaring van vrijwel elke programmeur. Je hebt je programma klaar, je hebt er heel goed over nagedacht, je hebt het uitvoerig getest en dan blijken er later toch nog fouten in te zitten! Dat gebeurt vooral zodra anderen je programma gaan gebruiken. Bovendien zijn de gevolgen nog veel groter als het aantal gebruikers groot is. De vraag hoe je betrouwbare software moet maken, heeft geleid tot een heel eigen vakgebied, namelijk Software Engineering.
Voor het ontwikkelen van goede software kunnen verschillende methoden worden gehanteerd. Tegenwoordig is Scrum erg populair. Scrum wordt behalve voor het maken van software ook voor andere doeleinden gebruikt. In deze module laten we zien wat Scrum is en hoe Scrum toegepast kan worden. Scrum biedt oplossingen voor een aantal problemen, maar niet voor alles. Scrum schrijft bijvoorbeeld niet voor in welke taal er geprogrammeerd moet worden. Scrum lost ook het probleem van correctheid van software niet op. Scrum zorgt wel voor oplossingen voor communicatieproblemen. En voor problemen die ontstaan als meerdere mensen met elkaar moeten samenwerken. Daar is bij de ontwikkeling van grote programma’s vaak sprake van.
Leerdoelen
Na verwerking van deze module:
kun je uitleggen wat er bedoeld wordt met Software Engineering;
kun je een aantal kenmerken noemen die van toepassing zijn op het vakgebied Software Engineering;
kun je uitleggen waar de term Scrum vandaan komt;
weet je wat een iteratie is;
weet je wat wordt bedoeld met het Scrum team;
weet je wat een Product Owner is en wat zijn/haar taken zijn;
weet je wat een Scrum Master is en wat zijn/haar taken zijn;
kun je uitleggen wat een ontwikkelteam is;
weet je wat de taken zijn van het ontwikkelteam;
weet je wat een Product Backlog is;
weet je wat wordt bedoeld met de Definition of Done;
weet je wat een Sprint Backlog is;
kun je uitleggen wat Product Backlog Items zijn;
weet je wat wordt bedoeld met de velocity van het ontwikkelteam;
kun je uitleggen wat wordt bedoeld met de Backlog Refinement;
kun je uitleggen waarvoor Burndown Charts gebruikt worden;
weet je het verschil tussen de Release Burndown Chart en de Sprint Burndown Chart;
kun je uitleggen waarvoor een Scrum bord wordt gebruikt;
kun je uitleggen wat de functie is van de Sprint Planning Meeting;
weet je wat een Daily Scrum is;
weet je wat het verschil is tussen een Sprint Review en een Sprint Retrospective;
kun je toelichten welke principes van Scrum bij het ontwikkelen van software worden toegepast.
Je bent begonnen in de module Scrum en Software Engineering.
Deze module bestaat uit meerdere onderdelen.
In ieder onderdeel vind je, verdeeld over verschillende pagina's, informatie in de vorm van teksten, afbeeldingen en video's.
Daarnaast ga je zelf aan de slag. Onder het kopje "Aan de slag" vind je steeds toepassingsopdrachten.
Deze opdrachten maak je alleen of met een klasgenoot.
Succes met de module Scrum en Software Engineering.
B Software Engineering
Inleiding
Al in de vorige eeuw hielden informatici zich bezig met de vraag hoe je betrouwbare software moet maken. In 1968 werd er zelfs een grote conferentie aan gewijd. De conferentie kreeg de titel “Software Engineering”. Een tot die tijd weinig gebruikte term. Deelnemers van de conferentie maakten zich vooral zorgen over wat destijds ook wel de software crisis werd genoemd. De kwaliteit van de ontwikkelde software was veelal onder de maat en projecten kostten vaak meer geld en tijd dan van tevoren was gepland. Na de conferentie werd er een rapport gepubliceerd met richtlijnen voor het ontwikkelen van software.
“The major cause [of the software crisis] is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem. In this sense the electronic industry has not solved a single problem, it has only created them, it has created the problem of using its products.” - Edsger Dijkstra
Er is inmiddels veel veranderd. Software Engineering heeft zich tot een heel eigen vakgebied ontwikkeld. Het is een deelgebied van informatica dat zich bezighoudt met alle aspecten van het bouwen van complexe maar betrouwbare software tot informatiesystemen.
Op Software Engineering zijn een aantal kenmerken van toepassing:
Het gaat altijd over grote programma’s. Dit zijn programma’s die zo groot of complex zijn dat je deze met meerdere personen moet ontwikkelen.
Centraal staat het beheersen van de complexiteit van de software of het informatiesysteem.
Voor de ontwikkeling van software is het noodzakelijk om samen te werken.
Er moet rekening mee gehouden worden dat software verandert.
Software moet efficiënt ontwikkeld worden. Tijd is immers geld.
Software wordt ontwikkeld voor anderen en dus niet voor jezelf. Je hebt te maken met een opdrachtgever, maar ook met een potentieel grote groep gebruikers.
★ Aan de slag 1
Bekijk het filmpje van de David Lettermanshow.
Leg het verband uit tussen dit filmpje en het vakgebied Software Engineering.
★ Aan de slag 2
Een centraal thema voor Software Engineering is het beheersen van de complexiteit.
Software en/of systemen kunnen zo complex zijn dat het onmogelijk is om in je eentje in te zien hoe alles in elkaar zit.
Hoe zou dit probleem kunnen worden aangepakt?
Software is aan verandering onderhevig.
Dat komt omdat software vaak een stukje van de werkelijkheid modelleert.
Bijvoorbeeld de dienstregeling van de NS.
Die werkelijkheid verandert.
Software zal dus ook mee moeten veranderen.
Wat gebeurt er als software niet mee verandert?
Wat zou bedoeld worden met “Software wordt ontwikkeld voor anderen en dus niet voor jezelf”?
★ Aan de slag 3
Bekijk het filmpje over de Ariane 5.
Waarom zou het iets uitmaken dat de Ariane 5 groter was?
★ Aan de slag 4
In een programma wordt op een zeker moment de vermenigvuldiging 65541 x 65585 uitgevoerd.
Het antwoord blijkt 3539188 te zijn.
Maar dit klopt niet.
Leg uit wat de oorzaak zou kunnen zijn.
Wat is een goed woord voor software?
Kies uit:
besturingssysteem
programmatuur
applicatie
toepassing
Leg uit waarom het noodzakelijk is om systematisch te werk te gaan bij het ontwikkelen van betrouwbare software.
★ Aan de slag 5
Bekijk de cartoon.
Je ziet het traject van Software Engineering.
Leg uit wat de cartoonist ons duidelijk wil maken.
Welke twee kenmerken van Software Engineering komen in de cartoon vooral aan bod?
C Scrum
Inleiding
Scrum is in de jaren negentig van de vorige eeuw ontwikkeld door Ken Schwaber en Jeff Sutherland. Het is een raamwerk voor het ontwikkelen en onderhouden van complexe producten. Dat gebeurt in teamverband. Het team bestaat uit mensen die afkomstig zijn uit verschillende vakgebieden. Het team is multidisciplinair. Binnen het team worden de taken verdeeld, wordt iedereen betrokken bij de planning en worden problemen benoemd. Het team stuurt zichzelf aan. Scrum veronderstelt daarbij wel dat binnen het team alle benodigde kennis aanwezig is.
De term scrum
Voor het ontwikkelen van software kan Scrum worden gebruikt. De term is afkomstig uit de rugbysport. Tijdens een rugbywedstrijd kan nadat het spel heeft stilgelegen de wedstrijd hervat worden met een Scrum. De spelers van de beide teams staan dan voorovergebogen tegenover elkaar. In de Scrum, zo wordt deze opstelling genoemd, moeten de spelers proberen de bal te bemachtigen. Daarvoor moet je samenwerken met je teamleden.
In de ontwikkelmethodiek Scrum is samenwerking ook heel belangrijk.
Een goede samenwerking verbetert de effectiviteit. En dat staat bij Scrum hoog in het vaandel.
Scrum wordt niet alleen voor het ontwikkelen van software gebruikt. Het eindproduct kan ook iets anders zijn. We zullen daar in deze module voorbeelden van laten zien.
Bekijk de film waarin de werking van Scrum beknopt wordt uitgelegd:
★ Aan de slag 6
Leg uit waarom een goede samenwerking de effectiviteit verbetert.
Neem als voorbeeld de samenwerking tussen een producent en een klant bij de ontwikkeling van een nieuw product.
Iteraties
Scrum werkt met iteraties. Een iteratie in Scrum wordt ook wel een sprint genoemd. Het is een korte periode die leidt tot een resultaat dat ook echt af is. We illustreren dit aan de hand van het ontwerp en de productie van een nieuw model wielrenfiets. Een fabrikant van sport- en wielrenfietsen krijgt van een klant de opdracht om een nieuw model wielrenfiets te ontwerpen en te vervaardigen. De fabrikant zou het eindproduct aan de opdrachtgever kunnen laten zien als de fiets helemaal ontwikkeld, gefabriceerd en geassembleerd is. De fabrikant kan echter ook besluiten om tussentijds telkens een onderdeel dat klaar is aan de opdrachtgever te presenteren. Bijvoorbeeld het frame, het zadel, het stuur etc.
In dat geval krijgt de opdrachtgever al snel een zichtbaar resultaat te zien. Dat levert vaak een tevreden klant op. Het ontwerp en de productie van de diverse onderdelen van de fiets zouden verschillende iteraties kunnen zijn. De assemblage, het in elkaar zetten van de fiets, zou ook een aparte sprint kunnen zijn. Bouw je met Scrum een fiets dan levert elke sprint dus een fiets of fietsonderdelen op.
Het eindresultaat van een sprint levert een product op dat echt af is. Het product moet “shippable” zijn. Dat betekent zoiets als het product is klaar (bruikbaar) voor het verschepen naar de eindgebruiker. En dat is dus de klant. In dit opzicht is het voorbeeld van de fiets misschien enigszins ongelukkig gekozen. De losse onderdelen die echt af zijn, zijn vooral interessant voor de fabrikant van fietsen. En niet zo zeer voor de wielrenner. In het geval van software betekent shippable dat je begint met een eenvoudig werkend product. Daaraan ga je in volgende sprints telkens een stukje functionaliteit (feature) toevoegen.
In de praktijk duurt een sprint vaak enkele weken. Een sprint zou ook korter kunnen duren. Eigenlijk is hoe korter hoe beter. Er kan snel worden bijgestuurd als er iets mis dreigt te gaan. En de klant kan al in een vroeg stadium feedback geven op een deel van het opgeleverde product.
Scrum is bedacht voor het ontwikkelen van software, maar zoals je uit het voorbeeld van het ontwerpen van een nieuwe fiets kunt afleiden, is de ontwikkelmethode Scrum ook voor andere doeleinden zeer geschikt. In deze interactieve module kijken we, ondanks dat we vaker terugkomen op het voorbeeld van de fiets, vooral naar het gebruik van Scrum voor de ontwikkeling van software. Daar is deze methode in eerste instantie ook oorspronkelijk voor bedacht.
D Het Scrum team
Het Scrum team
In Scrum wordt gewerkt met een vast team van mensen. We noemen zo’n team het Scrum team. Elk Scrum team bestaat uit de Product Owner, de Scrum Master en de leden van het ontwikkelteam. Het ontwikkelteam, vaak afgekort als “team”, is een onderdeel van het Scrum team. Het ontwikkelteam wordt ook wel het Development Team genoemd.
We kijken nogmaals naar het voorbeeld van de wielrenfiets. Voor de ontwikkeling, fabricage en assemblage van een nieuw model fiets zou, als we daar Scrum voor zouden gebruiken, de verantwoordelijkheid bij een Scrum team kunnen worden neergelegd. Samen streven de leden van het Scrum team naar het zo snel mogelijk opleveren van een waardevol tastbaar resultaat. Dat moet iets zijn waar de klant wat aan heeft. In de praktijk betekent dat de oplevering van een product, of een deelproduct, dat waardevol is voor de klant of opdrachtgever.
Zo’n deelproduct is bijvoorbeeld de zadelpen van de fiets. De zadelpen is de stang waardoor het zadel met het frame wordt verbonden. De klant heeft z’n voorkeur uitgesproken voor een verende zadelpen. Met een verende zadelpen kunnen de klappen op onregelmatige ondergronden beter worden opvangen. Als het Scrum team in een paar weken tijd een goed functionerende zadelpen voor de fiets kan ontwerpen en produceren, zal de klant tevreden zijn. Het is aannemelijk dat de klant dan ook met vertrouwen naar de rest van het project zal kijken.
Een ander onderdeel van de fiets is het zadel. Wielrenners hebben veel last van zadelpijn. Dat wordt vaak veroorzaakt door een verkeerd zadel. Een zadel moet goed aansluiten op de anatomie van de fietser. Is dat niet het geval dan kan door wrijving op het bovenbeen en druk op de schaambeenderen zadelpijn veroorzaakt worden. Zadelpijn kan voorkomen worden door een zadel op maat te laten maken. Dat is echter een dure oplossing. De klant heeft daarom aan de fabrikant gevraagd een zadel te ontwerpen dat betaalbaar is, maar toch aan de behoeften van een specifieke groep tegemoetkomt.
Er wordt vooral gedacht aan wielrenners die fietsen voor hun hobby. De klant wil graag dat leren zadels worden gebruikt. Een leren fietszadel heeft immers als groot voordeel dat het helemaal naar je lichaam en je houding gaat staan en daardoor optimaal ondersteunt.
★ Aan de slag 7
Zadelpen
Er is voor gekozen om als eerste een zadelpen te ontwerpen en te produceren en pas in een later stadium naar het ontwerp en oplevering van het zadel te kijken.
Wat kan daarvan de reden zijn?
De Product Owner
Binnen het Scrum team speelt de Product Owner een belangrijke rol. De Product Owner vertegenwoordigt de belangen van alle betrokken partijen. Dus ook de belangen van de klant. Een van de taken van de Product Owner is het prioriteren van de Product Backlog. Dat is een overzicht van alle taken die moeten worden verricht om het product te maken. Daarnaast houdt de Product Owner de financiën in de gaten en let hij of zij erop dat het product binnen de afgesproken tijd opgeleverd wordt. Samen met het Development Team bepaalt de Product Owner wanneer iets ook echt klaar is. Daarvoor worden criteria opgesteld die vastgelegd worden in de zogenaamde Definition of Done. Voor de succesvolle oplevering van een product zal de Product Owner ook regelmatig overleg moeten hebben met de klant en de leden van het ontwikkelteam. De Product Owner is overigens altijd één persoon.
★ Aan de slag 8
Waarom ligt het voor de hand dat de Product Owner altijd één persoon is?
De Scrum Master
Om goed werk te kunnen verrichten, heeft het ontwikkelteam ondersteuning nodig. Dat is een van de activiteiten waar de Scrum Master zich mee bezighoudt. Als de leden van het ontwikkelteam willen overleggen, regelt de Scrum Master bijvoorbeeld een vergaderruimte. Daar hoeft het ontwikkelteam zich niet om te bekommeren. Hun taak is het om zich volledig te richten op het maken van het product. Datzelfde geldt ook voor een programmeur die tijdelijk meer rechten op het netwerk nodig heeft. Bijvoorbeeld voor het uitvoeren van een specifieke test of het installeren van software die daarvoor nodig is. Het is aan de Scrum Master om dit soort belemmeringen voor leden van het ontwikkelteam tijdig te signaleren en te verhelpen. Daarnaast helpt de Scrum Master het team om de Scrum-spelregels goed toe te passen.
Het ontwikkelteam
Het ontwikkelteam is een onderdeel van het Scrum team. Het is een gevarieerd gezelschap. Voor het ontwikkelen van software en informatiesystemen heb je met specialisten te maken. Programmeurs, testers, analisten etc. De Scrum Master is ook lid van het ontwikkelteam. In het ontwikkelteam zitten mensen met verschillende achtergronden. Binnen het team is sprake van enige specialisatie, maar er bestaan geen gespecialiseerde teams. In principe doen de meeste leden van het team alles. Dus ontwikkelen, testen, maar ook het documenteren van de ontwikkelde software.
De leden van het ontwikkelteam moeten goed met elkaar samenwerken. Aan het begin van elke werkdag vindt er daarom een overleg van het team plaats. Dit overleg wordt de Daily Scrum genoemd. Tijdens dit overleg wordt er besproken hoe het werk van die dag goed georganiseerd en op elkaar afgestemd kan worden.
E Lijsten en grafieken
De Product Backlog
In Scrum wordt gewerkt met verschillende soorten lijsten: de Product Backlog en de Sprint Backlog.
★ Aan de slag 9
Zoek op internet naar de betekenis van het woord backlog.
De Product Backlog - 2
Het beheer van de Product Backlog is in handen van de Product Owner. De Product Owner stelt vast wat en waar iets op de Product Backlog komt te staan. Maar waarvoor dient die Product Backlog nu eigenlijk? De Product Backlog is een geordende lijst waarop alle onderdelen (eigenschappen) worden vermeld die nodig zijn voor het realiseren van een compleet product. Voor elk onderdeel (eigenschap) wordt de gewenste functionaliteit die nodig is voor het product beschreven. Het is belangrijk dat iedereen weet wat er moet gebeuren om een opdracht succesvol af te ronden. Daarbij speelt de Product Backlog een belangrijke rol. Zoals gezegd is het de taak van de Product Owner om te bepalen wat er op de lijst komt te staan. Hij bepaalt ook waar iets komt te staan. Met andere woorden welke prioriteit aan een bepaald onderdeel wordt toegekend.
Op de Product Backlog wordt de gewenste functionaliteit van de verschillende onderdelen verwoord in User Stories. Als iedereen zich netjes houdt aan wat er op de Product Backlog staat, levert dat uiteindelijk het gewenste eindresultaat op. Voor het ontwerp en productie van de wielrenfiets heeft de Product Owner als eerste op de Produkt Backlog de zadelpen geplaatst. Er staat dan zoiets als:
Prioriteit
User Story
Uren
1
Als fietser wil ik dat de fiets een verende zadelpen krijgt, zodat de vering op onregelmatige ondergronden beter klappen kan opvangen.
2
2
Als fietser wil ik dat de fiets voorzien is van een model zadel waardoor ik zo min mogelijk last heb van zadelpijn.
5
3
Als fietser wil ik dat de fiets van een leren zadel wordt voorzien, zodat ik optimale ondersteuning krijg.
2
4
★ Aan de slag 10
Om te bepalen wat en waar iets op de Product Backlog komt te staan, zal de
Product Owner van tevoren met verschillende mensen in gesprek moeten gaan.
Wie zijn dat en waarom moet de Product Owner met hen vooraf overleggen?
Welke functie heeft het vermelden van de prioriteit op de Product Backlog?
De Product Backlog - 3
De items die op de Product Backlog worden vermeld, worden Product Backlog Items genoemd. In de dagelijkse praktijk worden deze items vaak stories genoemd. Achter elke User Story wordt een aantal punten vermeld. Deze punten staan voor de tijd die het team nodig denkt te hebben voor het realiseren van de vastgelegde wens.
Op de Product Backlog staan items die vaak samen afgehandeld kunnen worden. Bijvoorbeeld omdat ze bij elkaar horen. Voor de wielrenfiets zou de Product Owner alle items die gaan over het ontwerp van het zadel kunnen groeperen. Hoeveel items bij elkaar geplaatst kunnen worden, hangt af van de velocity van het team.
Daaronder verstaan we de hoeveelheid werk dat een team kan verrichten gedurende één sprint. De velocity kan dan worden uitgedrukt in het aantal punten dat nodig is voor één sprint.
★ Aan de slag 11
Waar zou je Product Backlog Items mee kunnen vergelijken?
Een User Story bestaat uit een rol van een eindgebruiker, een wens en een voordeel:
als (rol)
wil ik (wens)
zodat (voordeel)
Wielrenners gebruiken vaak pedalen met een kliksysteem. De schoen wordt tijdens het fietsen vastgekoppeld aan het pedaal. Dat heeft een aantal voordelen. Zoek op internet naar een voordeel van kliksystemen en formuleer een User Story voor klikpedalen waarin een rol een wens en een voordeel wordt verwoord. De eindgebruiker is in dit voorbeeld een wielrenner. Je begint de User Story dan ook met de rol "Als een wielrenner":
Stel dat de eerste drie User Stories in de Product Backlog in één sprint gerealiseerd kunnen worden. Wat is dan de velocity van het team?
De Product Backlog - 4
De tijd die nodig is voor het realiseren van een wens die wordt uitgesproken in een User Story wordt vastgesteld door de leden van het ontwikkelteam. Zij voeren immers het werk uit en kunnen de benodigde tijd het beste inschatten.
De Product Owner zal voor het opstellen van de Product Backlog hierover bij de teamleden informatie moeten inwinnen. Dat blijft niet alleen bij deze ene keer. De Product Owner zal tijdens het uitvoeren van de opdracht de Product Backlog op gezette tijden onder de loep moeten nemen en indien nodig moeten bijstellen. Dit wordt de Backlog Refinement genoemd.
★ Aan de slag 12
Wat zou er tijdens de Backlog Refinement zoal kunnen worden aangepast?
Op de Product Backlog staan bovenaan in de lijst vaak User Stories met daarachter een laag aantal punten. Leg uit waarom.
De Sprint Backlog
Scrum werkt met iteraties. Een iteratie of sprint is een korte periode die leidt tot afgerond resultaat. De Sprint Backlog is een overzicht van de taken die moeten worden uitgevoerd gedurende een sprint. Deze taken worden geformuleerd door het Scrum team. Voorafgaand aan de sprint vindt er een overleg plaats. Dit overleg wordt de Sprint Planning genoemd. Tijdens dit overleg selecteert het team een aantal Product Backlog Items, meestal in de vorm van User Stories, en formuleert taken die nodig zijn voor het realiseren van de gekozen User Stories.
Meestal wordt er ook een inschatting gemaakt van de tijd die nodig is om de omschreven taak uit te voeren.
Voor een Sprint Backlog kan een spreadsheet gebruikt. Maar een Sprint Backlog kan ook worden uitgevoerd in de vorm van een kolom met kaartjes op het Scrum-board. Tijdens de sprint wordt de informatie op de Sprint Backlog telkens bijgewerkt als er nieuwe informatie beschikbaar is. In de kolommen met de dagen kan worden ingevuld hoeveel tijd het team denkt nodig te hebben voor het afronden van de taken. In het voorbeeld hebben we voor één User Story een aantal taken uitgewerkt. Deze lijst is dus nog niet compleet.
User Story
Taken
Dag 1
Dag 2
Dag 3
Dag 4
Dag 5
...
Als fietser wil ik dat de fiets een verende zadelpen krijgt, zodat de vering op onregelmatige ondergronden beter klappen kan opvangen.
Ontwerpen zadelpen
...
...
...
...
...
...
"
Productie zadelpen
"
Testen zadelpen
...
...
...
...
...
...
"
Evalueren van de testen
...
...
...
...
...
...
"
Teamoverleg
...
...
...
...
...
...
Er is al eerder aangegeven dat de ontwikkelmethode Scrum oorspronkelijk is bedacht voor het ontwikkelen van software.
In een Sprint Backlog tref je onder taken dan vooral activiteiten aan zoals ontwerpen GUI, overleg met …, programmeren van …, testen van … etc.
Definition of Done
Wanneer is iets echt af? Dat wordt vastgelegd in de Definition of Done.
Samen met het ontwikkelteam bepaalt de Product Owner aan welke acceptatiecriteria een product moet voldoen voordat het ook echt af is.
Dat wil zeggen: de gebruikers moeten er zo mee aan de slag kunnen gaan.
Voor ontwikkelde software houdt dat bijvoorbeeld in dat de software uitvoerig is getest en van documentatie is voorzien.
Burndown Charts
Chart is de Engelse term voor koersgrafiek. Een koersgrafiek geeft het prijs- of koersverloop aan van bijvoorbeeld een aandeel. Bij Scrum worden ook verschillende typen grafieken gebruikt die lijken op koersgrafieken, de zogenaamde Burndown Charts. Deze Burndown Charts worden in Scrum gebruikt om de voortgang bij te houden. Er zijn twee Burndown Charts:
De Release Burndown
De Sprint Burndown
In de Release Burndown Chart kan de voortgang van een Scrum project worden bekeken. Deze grafiek laat de relatie zien tussen het aantal punten die in de Product Backlog worden vermeld en het aantal sprints dat moet worden doorlopen.
Veronderstel dat voor het project van de wielrenfiets in de Product Backlog in het totaal 72 punten staan. Zoals al eerder is uitgelegd, staan de vermelde punten voor een hoeveelheid tijd (werk) die nodig is om een taak uit te voeren. Het totaal aantal punten, in dit geval 72, staat dan voor de hoeveelheid tijd die nodig is om het hele project af te ronden. Aan het begin van het project is er ingeschat dat er 8 sprints nodig zijn om het complete project af te ronden. Dat betekent dus gemiddeld 9 punten per sprint.
Als alles volgens planning zou verlopen, zou de Release Burndown Chart er als volgt uitzien:
De praktijk blijkt echter weerbarstig. De eerste drie sprints verlopen helemaal volgens de planning. In de vierde maar ook in de zesde sprint wijkt de benodigde tijd af van de geplande tijd.
Uit beide grafieken kan worden afgeleid, dat al het werk uiteindelijk toch in 8 sprints afgerond kan worden. Soms klopt de planning echter niet. Dankzij de Burndown Chart zie je dat al in een vroeg stadium. In die gevallen zou de Product Backlog nog eens bekeken moeten worden.
★ Aan de slag 13
Noem een mogelijke oorzaak waarom tijdens de vierde en de zesde sprint meer tijd nodig is geweest dan aanvankelijk is gepland.
Waarom zouden dit soort grafieken in Scrum Burndown Charts genoemd worden?
De Release Burndown Chart is geen statische grafiek.
Eigenlijk moet deze grafiek na elke sprint worden geactualiseerd.
Wiens taak is dit?
Burndown Charts - 2
De Sprint Burndown Chart geeft het team inzicht in de dagelijkse voortgang van een sprint ten opzichte van de vooraf gemaakte planning. Deze grafiek laat per sprint zien hoeveel werk er inmiddels is afgerond en wat er nog moet worden gedaan.
Bij één van de aan de slag opdrachten zijn we uitgegaan van de veronderstelling dat de eerste drie User Stories die op de Product Backlog staan in één sprint gerealiseerd zouden kunnen worden.
Prioriteit
User Story
Punten
1
Als fietser wil ik dat de fiets een verende zadelpen krijgt, zodat de vering op onregelmatige ondergronden beter klappen kan opvangen.
2
2
Als fietser wil ik dat de fiets voorzien is van een model zadel waardoor ik zo min mogelijk last heb van zadelpijn.
5
3
Als fietser wil ik dat de fiets van een leren zadel wordt voorzien, zodat ik optimale ondersteuning krijg
2
4
Het ontwikkelteam heeft een inschatting gemaakt dat 1 punt overeenkomt met twee werkdagen. In dit voorbeeld staat voor een sprint dan 9 punten en dat zijn dan 18 werkdagen. In de weekenden wordt niet gewerkt. Een sprint gaat dan ruim 3 weken in beslag nemen.
★ Aan de slag 14
Bekijk de Sprint Burndown Chart.
Wat valt op?
De Sprint Burndown Chart moet, net als de Release Burndown Chart, telkens worden geüpdatet.
Wiens taak is dat?
Het Scrum bord
Het Scrum bord is een instrument dat door een ontwikkelteam gebruikt kan worden om de onderdelen van de Sprint Backlog te visualiseren. Op het bord zijn alle taken die voor een sprint moeten worden afgerond, te zien.
Het bord wordt meestal ingedeeld in drie categorieën:
To Do
Work in Progress
Done
In de To Do kolom staan de User Stories uitgesplitst in taken. Deze taken, die worden genoteerd op een Post-it, krijgen op het bord een plek op basis van hun prioriteit. De belangrijkste taak staat bovenaan. Voor de Post-it’s waar de User Stories op vermeld worden, wordt vaak een andere kleur gebruikt dan de Post-it’s waar de taken op zijn uitgewerkt. Door met diverse kleuren te werken, wordt de indeling op het bord overzichtelijker.
Tijdens de sprint bepalen de leden van het ontwikkelteam welke taken uitgevoerd moeten worden. Deze taken, die vermeld worden op de Post-it’s, worden verplaatst naar de kolom Work in Progress.
Taken die afgerond zijn, komen te staan in de kolom Done.
Een Scrum bord heeft niet altijd dezelfde vorm. Soms staat er voor Done nog een aparte kolom Verify of Testing. Dat kan handig zijn als een ontwikkelteam onderscheid wil maken tussen de fase van het testen en de oplevering van een product. Er zijn ook teams die op het Scrum Bord de Sprint Burndown Chart afbeelden. Het voordeel daarvan is dat het hele team tijdens de sprint op de hoogte is van de voortgang
Bekijk de time-lapse van een Scrum bord van tijdens een sprint van 9 dagen.
★ Aan de slag 15
Is een Scrum bord statisch?
Leg je antwoord uit.
F De Sprint
Een iteratie of sprint is een korte periode die leidt tot een afgerond resultaat. Voor een product is dat bijvoorbeeld het eindresultaat, bij de ontwikkeling van software kan dat een release zijn. Voordat er een release van de software kan plaatsvinden, moet de software worden getest. Voor ontwikkelaars is het van belang om software te ontwikkelen die doet wat de klant ervan verwacht. Dat geldt voor een compleet pakket, maar ook voor een kleiner onderdeel van het volledige pakket. In Scrum wordt immers met sprints gewerkt waarin ook een onderdeel van de software ontwikkeld en gerealiseerd kan worden.
Een sprint duurt hooguit een maand. Vaak zijn sprints korter en nemen ze enkele weken in beslag. Sprints hebben tijdens het ontwikkeltraject altijd dezelfde lengte en ze volgen elkaar altijd direct op. Voorafgaand aan de start van een sprint vindt er een bijeenkomst plaats die de Sprint Planning Meeting wordt genoemd. Tijdens de Sprint Planning Meeting wordt gekeken naar de Product Backlog. Welke items op de Product Backlog horen bij elkaar en kunnen in de sprint worden uitgewerkt. Tijdens de sprint wordt er aan het begin van de werkdag een kort overleg gevoerd. Dit overleg, van hooguit 15 minuten, wordt de Daily Scrum genoemd. Tijdens dit overleg staat iedereen. De Daily Scrum wordt daarom ook wel de Daily Standup genoemd.
Een sprint wordt afgesloten met een Sprint Review en een Sprint Retrospective. Er bestaat een duidelijk onderscheid tussen de Sprint Review en de Sprint Retrospective. Een Sprint Review wordt gehouden met de klant, de Sprint Retrospective met het team. Tijdens de Sprint Review wordt gekeken of het nodig is om de Product Backlog aan te passen. De Sprint Retrospective is een aparte vergadering waarin bekeken wordt hoe de sprint is verlopen. Zijn de doelstellingen bereikt? Hoe is samenwerking verlopen? Zijn er nog bijzondere dingen gebeurd? Het belangrijkste doel van deze vergaderingen is om te leren van wat er wellicht niet goed is gegaan en wat (en hoe) het volgende keer beter kan.
G Het Enigmacollege
De opdracht
Je hebt kennis gemaakt met het vakgebied Software Engineering en de ontwikkelmethode Scrum. Nu wordt het tijd om de opgedane kennis in praktijk te brengen. Jullie verplaatsen je daarbij in de huid van werknemers van softwarebedrijf “Het bitje”. Eigenaar van “Het bitje” is de heer Mauchly. Hij heeft recentelijk per mail een verzoek ontvangen van de rector van het Enigmacollege.
Geachte heer Mauchly,
Het Enigmacollege is een school voor voortgezet onderwijs waar veel aandacht is voor ICT. Ieder jaar is er op het Enigmacollege een open dag voor leerlingen uit groep 8 van basisscholen uit de omgeving. De commissie, die de open dag organiseert, heeft het idee gelanceerd dat het aardig zou zijn als iedere bezoeker tijdens de open dag een game kan downloaden over het Enigmacollege. Het spel moet leuk zijn voor leerlingen uit groep 8, maar moet ook een goed beeld geven van de school. Indien uw bedrijf interesse heeft in deze opdracht wil ik u vragen contact op te nemen met de voorzitter van de commissie open dag, de heer Eckert
Met vriendelijke groet,
J. von Neumann, Rector Enigmacollege
De heer Mauchley, eigenaar van “Het bitje”, heeft na een gesprek met de voorzitter van de commissie open dag te kennen gegeven de game te willen ontwikkelen. Hij heeft zijn werknemers gevraagd om met de verstrekte opdracht aan de slag te gaan. Voor het ontwikkelen van de game gaat het team gebruik maken van Scrum.
In dit project is de heer Dijkstra het alter ego van je docent informatica. Voor het Enigmacollege kun je de eigen school in gedachten nemen.
Soorten games
Er bestaan verschillende soorten games. Voordat jullie team start met het uitvoeren van de opdracht is het verstandig om eerst eens te kijken welke typen games er bestaan.
In de praktijk is het soms moeilijk om een game in een bepaalde categorie te plaatsen, omdat een game elementen van verschillende typen bevat. Het is belangrijk dat je als ontwerper rekening houdt met de verwachtingen die een speler heeft. Een RPG dat vliegensvlugge reacties vereist, maakt dat je de speler teleurstelt. Je voldoet niet aan zijn verwachting.
Bekijk het filmpje waarin voorbeelden van verschillende typen games worden besproken:
GameMaker
Voor het bouwen van de game wordt GameMaker gebruikt.
Bekijk de animatie over GameMaker:
Een van de kenmerken van GameMaker is dat je zonder dat je daarvoor een programmeertaal hoeft te leren, een game kunt maken. Door middel van drag and drop kun je objecten aan de game toevoegen. Het gedrag van de objecten kun je ook aanpassen door acties naar events te verslepen
Daarnaast bezit GameMaker een programmeertaal, GML (GameMaker Language).
Op het internet vind je veel informatie en cursussen over het werken met GameMaker. Een paar belangrijke sites zijn:
Voordat er gestart kan worden met het uitwerken van de opdracht bepaalt jullie docent de groepsgrootte. Voor het bouwen van de Game maken jullie gebruik van GameMaker. Tijdens het project wordt er bijgehouden hoelang en waaraan gewerkt is. Dat wordt vastgelegd in een gezamenlijk logboek. Onder het menu-item Bijlagen staat een Excelbestand dat daarvoor gebruikt kan worden. Het bijhouden van de gewerkte tijd kan en mag ook op andere manieren worden geregistreerd. Het hele ontwikkelproces wordt vastgelegd in een eindverslag.
Voor het schrijven van het eindverslag is het noodzakelijk om veranderingen op het Scrum bord en in de charts vast te leggen. Bijvoorbeeld in de vorm van foto’s.
Voor het Scrum bord kan een fysiek bord gebruikt worden, maar het is ook mogelijk om het bord in een digitale vorm uit te werken. Overleg dat met je docent.
Bij de aan de slag opdrachten voor de projectopdracht geven we telkens aan voor wie de aan de slag opdracht bedoeld is.
★ Aan de slag 16
Voor wie: iedereen.
Bespreek binnen jullie groep wie de rol van Product Owner en die van Scrum Master gaat vervullen. In het ontwikkelteam zijn verschillende disciplines vertegenwoordigd, bijvoorbeeld een programmeur, een grafisch ontwerper, een tester. Overleg daarom vooraf wie welke taken op zich gaat nemen.
De taakverdeling binnen het Scrum team is besproken en de rollen zijn verdeeld. De eerstvolgende stap is dat de Product Owner contact opneemt met de voorzitter van de commissie open dag van het Enigmacollege. De Product Owner heeft bedacht dat het handig is om met de opdrachtgever te bespreken wat er van het te ontwikkelen spel verwacht wordt.
★ Aan de slag 17
Voor wie: Product Owner.
Bereid een gesprek voor dat gevoerd moet worden met de voorzitter van de commissie open dag van het Enigmacollege. Doel van het gesprek is om een helder beeld te krijgen van de eisen die door de opdrachtgever aan het te ontwikkelen spel worden gesteld. Doel van het gesprek is ook om duidelijk te krijgen voor wie en waarom de game ontwikkeld moet worden.
★ Aan de slag 18
Voor wie: Product Owner, voorzitter open dag Enigmacollege.
De Product Owner maakt met de voorzitter van de commissie open dag een afspraak om te praten over de opdracht die is verstrekt aan softwarebedrijf “Het bitje”. Op het afgesproken tijdstip vindt de ontmoeting plaats.
Er heeft een uitgebreid overleg plaatsgevonden tussen de Product Owner en de voorzitter van de open dag van het Enigmacollege. De Product Owner weet inmiddels voor welke doelgroep de game ontwikkeld moet worden en wat het doel is van de game. Ook is helder wat de eisen zijn die aan de game worden gesteld. Nu breekt het moment aan waarop de Product Owner een eerste versie van de Product Backlog kan opstellen.
★ Aan de slag 19
Voor wie: Product Owner.
Maak een eerste versie van de Product Backlog. Hierop komen de belangrijkste items te staan. Breng ook al een prioritering aan. Bepaal wat en waar iets staat. De tijd die nodig is voor het realiseren van de User Stories wordt op deze ruwe versie nog niet vermeld.
Prioriteit
User Story
1
Als opdrachtgever wil ik een spel met minimaal 3 levels.
2
Als opdrachtgever wil ik dat een speler in de vorm van een personage zich door een level kan verplaatsen.
3
4
De Product Owner heeft een ruwe versie van de Product Backlog gemaakt. Hoeveel tijd er nodig is voor het uitwerken van de items moet worden besproken met de leden van het ontwikkelteam. Zij voeren het werk uit en kunnen dus het beste inschatten hoeveel tijd er voor het realiseren van de items nodig is.
★ Aan de slag 20
Voor wie: Product Owner, leden ontwikkelteam.
Voer (Product Owner) met de leden van het ontwikkelteam overleg over de tijd die nodig is om de wensen en eisen die zijn vastgelegd op de Product Backlog te kunnen realiseren. Verwerk deze informatie in de Product Backlog. Bespreek (Product Owner) met de leden van het ontwikkelteam de User Stories die op de Product Backlog vermeld worden. Breng indien nodig aanpassingen aan. Wat kun je aan de hand van wat je ziet, concluderen?
Er heeft een eerste Backlog Refinement plaatsgevonden. Tijdens het uitvoeren van de opdracht zal de Product Backlog vaker moeten worden aangepast. Het opleveren van deelproducten door het ontwikkelteam en het bespreken ervan met de opdrachtgever kan immers nieuwe inzichten en/of wensen opleveren.
Stel een Definition of Done op. Hieronder zie je een stukje van een voorbeeld:
Definition of Done
Het product ziet er aantrekkelijk uit voor de doelgroep waarvoor het ontwikkeld wordt.
Er moet een duidelijke gebruikershandleiding zijn.
Nu de Product Backlog klaar is, kan de eerste sprint beginnen. Voordat de sprint daadwerkelijk kan starten, moeten er nog enkele dingen geregeld worden. De velocity van het team is nog niet vastgesteld. Ook moet er een Sprint Planning Meeting georganiseerd worden.
Probeer in deze fase van het ontwikkelproces een inschatting te maken van de velocity van het team.
Tijdens de Sprint Planning Meeting wordt gekeken naar de Product Backlog. Welke items op de Product Backlog horen bij elkaar en kunnen in de sprint worden uitgewerkt. Bij dit overleg zijn de Product Owner, de klant en de leden van het ontwikkelteam aanwezig. De Product Owner komt met een voorstel welke items bij elkaar zouden kunnen horen.
De Scrum Master heeft al lang van tevoren vastgesteld wanneer en waar de Sprint Planning Meetings plaatsvinden. Het aantal vergaderingen hangt af van hoeveel sprints er georganiseerd gaan worden.
★ Aan de slag 21
Voor wie: Scrum Master.
Stel de data en tijdstippen van de Sprint Planning Meetings vast. Organiseer de eerste Sprint Planning Meeting.
★ Aan de slag 22
Voor wie: Product Owner, klant, leden ontwikkelteam.
Kom op het afgesproken tijdstip en plaats bij elkaar voor de eerste Sprint Planning Meeting
In de fase die nu aanbreekt, vertalen de leden van het ontwikkelteam de Product Backlog Items naar taken die moeten worden uitgevoerd. Tijdens dit proces is de Product Owner aanwezig. Indien nodig kan de Product Owner nog vragen van het team beantwoorden of eventueel beslissingen nemen.
★ Aan de slag 23
Voor wie: leden ontwikkelteam.
Maak van de items op de Product Backlog taken. Maak een Sprint Backlog. Voor de overzichtelijkheid gaan we tijdens dit project werken met een Scrum bord. Het Scrum bord is een instrument dat door een ontwikkelteam gebruikt kan worden om de onderdelen van de Sprint Backlog te visualiseren.
★ Aan de slag 24
Voor wie: Scrum Master.
Zorg voor een Scrum bord en Post-it’s waarmee op het Scrum bord gewerkt kan worden.
★ Aan de slag 25
Voor wie: leden ontwikkelteam.
Richt het Scrum bord in.
In Scrum worden Burndown Charts gebruikt om de voortgang bij te houden.
★ Aan de slag 26
Voor wie: Product Owner.
Ontwerp voor het project een Release Burndown Chart.
★ Aan de slag 27
Voor wie: leden ontwikkelteam.
Ontwerp voor het project een Sprint Burndown Chart.
Het ontwikkelproces - 2
Alle voorbereidingen zijn nu getroffen. De eerste sprint kan daadwerkelijk beginnen. Bij de ontwikkelmethode Scrum komt het ontwikkelteam aan het begin van de dag bij elkaar om af te spreken wat er die dag gedaan moet worden. De geplande werkzaamheden worden doorgenomen en er worden afspraken gemaakt. In Scrum wordt dit de Daily Scrum genoemd. Dit is een korte bijeenkomst van maximaal een kwartier.
Bij de opdracht is het gezien de tijd die we eraan besteden niet mogelijk om een Daily Scrum uit te voeren. Wat is het mogelijk om op bepaalde momenten met het team de voortgang, de nog uit te voeren taken en mogelijke problemen te bespreken.
Nu is het moment aangebroken waarop jullie met GameMaker aan de slag gaan. Er wordt gestart met de eerste sprint. Het resultaat daarvan is een spel in GameMaker met slechts een beperkte functionaliteit. In de sprints die volgen, wordt het spel steeds verder uitgebreid met nieuwe onderdelen.
★ Aan de slag 28
Voor wie: leden ontwikkelteam.
Vergader tijdens de sprint een aantal keren met elkaar om de voortgang, nog uit te voeren werkzaamheden en mogelijke problemen te bespreken.
Houd tijdens de sprint wijzigingen op het Scrum bord bij.
Actualiseer de Sprint Burndown Chart
Het ontwikkelproces - 3
Een sprint wordt afgesloten met de Sprint Retrospective. Dit is een aparte vergadering waarin bekeken wordt hoe de sprint is verlopen. Zijn de doelstellingen bereikt? Hoe is samenwerking verlopen? Zijn er nog bijzondere dingen gebeurd? Het belangrijkste doel van deze vergaderingen is om te leren van wat er wellicht niet goed is gegaan. Tijdens de Sprint Review wordt gekeken of het nodig is om de Product Backlog aan te passen.
★ Aan de slag 29
Voor wie: Product Owner, leden ontwikkelteam en klant
Sluit de sprint af met een Sprint Review.
★ Aan de slag 30
Voor wie: Product Owner, Scrum Master, leden ontwikkelteam.
Sluit de sprint af met een Sprint Retrospective
Na elke sprint moet de Release Burndown Chart eigenlijk geactualiseerd worden.
Dit is de taak van de Scrum Master.
★ Aan de slag 31
Voor wie: Scrum Master.
Actualiseer na de eerste sprint de Release Burndown Chart.
★ Aan de slag 32
Voor wie: Product Owner, Scrum Master, leden ontwikkelteam.
We hebben nu één sprint afgerond. Ga voor alle andere sprints op dezelfde manier aan het werk en rond het project af.
★ Aan de slag 33
Voor wie: iedereen.
Schrijf een eindverslag waarin heel het ontwikkelproces wordt beschreven.
Het arrangement Scrum en Software Engineering is gemaakt met
Wikiwijs van
Kennisnet. Wikiwijs is hét onderwijsplatform waar je leermiddelen zoekt,
maakt en deelt.
Dit lesmateriaal is gepubliceerd onder de Creative Commons Naamsvermelding-GelijkDelen 4.0 Internationale licentie. Dit houdt in dat je onder de voorwaarde van naamsvermelding en publicatie onder dezelfde licentie vrij bent om:
het werk te delen - te kopiëren, te verspreiden en door te geven via elk medium of bestandsformaat
het werk te bewerken - te remixen, te veranderen en afgeleide werken te maken
voor alle doeleinden, inclusief commerciële doeleinden.
De module 'Software Engineering' is ontwikkeld door auteurs en medewerkers van Enigma-online.
Fair Use
In de modules van Enigma-online wordt gebruik gemaakt van beeld- en filmmateriaal dat beschikbaar is op internet. Bij het gebruik zijn we uitgegaan van fair use. Meer informatie: Fair use
Mocht u vragen/opmerkingen hebben, neem dan contact op
via de helpdesk VO-content .
Aanvullende informatie over dit lesmateriaal
Van dit lesmateriaal is de volgende aanvullende informatie beschikbaar:
Het schrijven van correcte programma’s, die onder alle omstandigheden doen wat ze moeten doen, is minder eenvoudig dan het lijkt. Dit is een ervaring van vrijwel elke programmeur. Je hebt je programma klaar, je hebt er heel goed over nagedacht, je hebt het uitvoerig getest en dan blijken er later toch nog fouten in te zitten! Dat gebeurt vooral zodra anderen je programma gaan gebruiken. Bovendien zijn de gevolgen nog veel groter als het aantal gebruikers groot is. De vraag hoe je betrouwbare software moet maken, heeft geleid tot een heel eigen vakgebied, namelijk Software Engineering.
Al in de vorige eeuw hielden informatici zich bezig met de vraag hoe je betrouwbare software moet maken. In 1968 werd er zelfs een grote conferentie aan gewijd. De conferentie kreeg de titel “Software Engineering”. Een tot die tijd weinig gebruikte term. Deelnemers van de conferentie maakten zich vooral zorgen over wat destijds ook wel de software crisis werd genoemd. De kwaliteit van de ontwikkelde software was veelal onder de maat en projecten kostten vaak meer geld en tijd dan van tevoren was gepland. Na de conferentie werd er een rapport gepubliceerd met richtlijnen voor het ontwikkelen van software.
Scrum is in de jaren negentig van de vorige eeuw ontwikkeld door Ken Schwaber en Jeff Sutherland. Het is een raamwerk voor het ontwikkelen en onderhouden van complexe producten. Dat gebeurt in teamverband. Het team bestaat uit mensen die afkomstig zijn uit verschillende vakgebieden. Het team is multidisciplinair. Binnen het team worden de taken verdeeld, wordt iedereen betrokken bij de planning en worden problemen benoemd. Het team stuurt zichzelf aan. Scrum veronderstelt daarbij wel dat binnen het team alle benodigde kennis aanwezig is.
Leg uit waarom een goede samenwerking de effectiviteit verbetert.
Scrum werkt met iteraties. Een iteratie in Scrum wordt ook wel een sprint genoemd. Het is een korte periode die leidt tot een resultaat dat ook echt af is. We illustreren dit aan de hand van het ontwerp en de productie van een nieuw model wielrenfiets. Een fabrikant van sport- en wielrenfietsen krijgt van een klant de opdracht om een nieuw model wielrenfiets te ontwerpen en te vervaardigen. De fabrikant zou het eindproduct aan de opdrachtgever kunnen laten zien als de fiets helemaal ontwikkeld, gefabriceerd en geassembleerd is. De fabrikant kan echter ook besluiten om tussentijds telkens een onderdeel dat klaar is aan de opdrachtgever te presenteren. Bijvoorbeeld het frame, het zadel, het stuur etc.
In Scrum wordt gewerkt met een vast team van mensen. We noemen zo’n team het Scrum team. Elk Scrum team bestaat uit de Product Owner, de Scrum Master en de leden van het ontwikkelteam. Het ontwikkelteam, vaak afgekort als “team”, is een onderdeel van het Scrum team. Het ontwikkelteam wordt ook wel het Development Team genoemd.
Binnen het Scrum team speelt de Product Owner een belangrijke rol. De Product Owner vertegenwoordigt de belangen van alle betrokken partijen. Dus ook de belangen van de klant. Een van de taken van de Product Owner is het prioriteren van de Product Backlog. Dat is een overzicht van alle taken die moeten worden verricht om het product te maken. Daarnaast houdt de Product Owner de financiën in de gaten en let hij of zij erop dat het product binnen de afgesproken tijd opgeleverd wordt. Samen met het Development Team bepaalt de Product Owner wanneer iets ook echt klaar is. Daarvoor worden criteria opgesteld die vastgelegd worden in de zogenaamde Definition of Done. Voor de succesvolle oplevering van een product zal de Product Owner ook regelmatig overleg moeten hebben met de klant en de leden van het ontwikkelteam. De Product Owner is overigens altijd één persoon.
Om goed werk te kunnen verrichten, heeft het ontwikkelteam ondersteuning nodig. Dat is een van de activiteiten waar de Scrum Master zich mee bezighoudt. Als de leden van het ontwikkelteam willen overleggen, regelt de Scrum Master bijvoorbeeld een vergaderruimte. Daar hoeft het ontwikkelteam zich niet om te bekommeren. Hun taak is het om zich volledig te richten op het maken van het product. Datzelfde geldt ook voor een programmeur die tijdelijk meer rechten op het netwerk nodig heeft. Bijvoorbeeld voor het uitvoeren van een specifieke test of het installeren van software die daarvoor nodig is. Het is aan de Scrum Master om dit soort belemmeringen voor leden van het ontwikkelteam tijdig te signaleren en te verhelpen. Daarnaast helpt de Scrum Master het team om de Scrum-spelregels goed toe te passen.
Het ontwikkelteam is een onderdeel van het Scrum team. Het is een gevarieerd gezelschap. Voor het ontwikkelen van software en informatiesystemen heb je met specialisten te maken. Programmeurs, testers, analisten etc. De Scrum Master is ook lid van het ontwikkelteam. In het ontwikkelteam zitten mensen met verschillende achtergronden. Binnen het team is sprake van enige specialisatie, maar er bestaan geen gespecialiseerde teams. In principe doen de meeste leden van het team alles. Dus ontwikkelen, testen, maar ook het documenteren van de ontwikkelde software.
In Scrum wordt gewerkt met verschillende soorten lijsten: de Product Backlog en de Sprint Backlog.
Zoek op internet naar de betekenis van het woord backlog.
Om te bepalen wat en waar iets op de Product Backlog komt te staan, zal de
De items die op de Product Backlog worden vermeld, worden Product Backlog Items genoemd. In de dagelijkse praktijk worden deze items vaak stories genoemd. Achter elke User Story wordt een aantal punten vermeld. Deze punten staan voor de tijd die het team nodig denkt te hebben voor het realiseren van de vastgelegde wens.
De tijd die nodig is voor het realiseren van een wens die wordt uitgesproken in een User Story wordt vastgesteld door de leden van het ontwikkelteam. Zij voeren immers het werk uit en kunnen de benodigde tijd het beste inschatten.
Scrum werkt met iteraties. Een iteratie of sprint is een korte periode die leidt tot afgerond resultaat. De Sprint Backlog is een overzicht van de taken die moeten worden uitgevoerd gedurende een sprint. Deze taken worden geformuleerd door het Scrum team. Voorafgaand aan de sprint vindt er een overleg plaats. Dit overleg wordt de Sprint Planning genoemd. Tijdens dit overleg selecteert het team een aantal Product Backlog Items, meestal in de vorm van User Stories, en formuleert taken die nodig zijn voor het realiseren van de gekozen User Stories.
Het Scrum bord is een instrument dat door een ontwikkelteam gebruikt kan worden om de onderdelen van de Sprint Backlog te visualiseren. Op het bord zijn alle taken die voor een sprint moeten worden afgerond, te zien.
Je hebt kennis gemaakt met het vakgebied Software Engineering en de ontwikkelmethode Scrum. Nu wordt het tijd om de opgedane kennis in praktijk te brengen. Jullie verplaatsen je daarbij in de huid van werknemers van softwarebedrijf “Het bitje”. Eigenaar van “Het bitje” is de heer Mauchly. Hij heeft recentelijk per mail een verzoek ontvangen van de rector van het Enigmacollege.
Er bestaan verschillende soorten games. Voordat jullie team start met het uitvoeren van de opdracht is het verstandig om eerst eens te kijken welke typen games er bestaan.
Voordat er gestart kan worden met het uitwerken van de opdracht bepaalt jullie docent de groepsgrootte. Voor het bouwen van de Game maken jullie gebruik van GameMaker. Tijdens het project wordt er bijgehouden hoelang en waaraan gewerkt is. Dat wordt vastgelegd in een gezamenlijk logboek. Onder het menu-item Bijlagen staat een Excelbestand dat daarvoor gebruikt kan worden. Het bijhouden van de gewerkte tijd kan en mag ook op andere manieren worden geregistreerd. Het hele ontwikkelproces wordt vastgelegd in een eindverslag.
Voor de overzichtelijkheid gaan we tijdens dit project werken met een Scrum bord. Het Scrum bord is een instrument dat door een ontwikkelteam gebruikt kan worden om de onderdelen van de Sprint Backlog te visualiseren.
Alle voorbereidingen zijn nu getroffen. De eerste sprint kan daadwerkelijk beginnen. Bij de ontwikkelmethode Scrum komt het ontwikkelteam aan het begin van de dag bij elkaar om af te spreken wat er die dag gedaan moet worden. De geplande werkzaamheden worden doorgenomen en er worden afspraken gemaakt. In Scrum wordt dit de Daily Scrum genoemd. Dit is een korte bijeenkomst van maximaal een kwartier.
Een sprint wordt afgesloten met de Sprint Retrospective. Dit is een aparte vergadering waarin bekeken wordt hoe de sprint is verlopen. Zijn de doelstellingen bereikt? Hoe is samenwerking verlopen? Zijn er nog bijzondere dingen gebeurd? Het belangrijkste doel van deze vergaderingen is om te leren van wat er wellicht niet goed is gegaan. Tijdens de Sprint Review wordt gekeken of het nodig is om de Product Backlog aan te passen.
Voor wie: Scrum Master.
Voor wie: Product Owner, Scrum Master, leden ontwikkelteam.
