Scrum. F. Vonk versie

Transcriptie

1 2013 Scrum F. Vonk versie

2 inhoudsopgave 1. inleiding Sprint Scrum Board rollen Scrum Master Scrum Member Daily Scrum Meeting decompositie & deelproducten planning & tracking Opstartfase Sprint Afsluitfase tot slot Dit werk is gelicenseerd onder een Creative Commons Naamsvermelding NietCommercieel GelijkDelen 3.0 Unported licentie De afbeelding op het voorblad is verkregen via INFOwrs. Copyright 2010 INFOwrs Serviços em informatica

3 1. inleiding In deze reader gaan we in op één van de vele Agile Software Development methodes (zie WikiNL en WikiEN). De methode waar we het over gaan hebben bestaat al lange tijd en wordt nog steeds veel en succesvol toegepast binnen bedrijven. De naam van de methode is Scrum (zie WikiNL en WikiEN). Er is veel geschreven over Agile Software Development en Scrum. Hier gaan we een zeer minimale uitvoering van Scrum beschrijven die ons helpt bij het omgaan met kleine projecten zoals die uitgevoerd worden tijdens de informatica lessen. De sleutel tot een succesvolle afronding van een project zijn goed en duidelijk beschreven eisen. Iedereen moet weten wat er gemaakt gaat worden en het daarover eens zijn. Anders kan een team geen goed product afleveren. 1 Om tot goede eisen te komen zijn mensen en interacties van groot belang. Een klant weet verrassend genoeg vaak niet wat hij/zij precies wil en moet geholpen worden om dit helder te krijgen. Dit moet duidelijk zijn vóór het project op grote schaal van start gaat zodat er zo min mogelijk onnodig werk gedaan wordt

4 2 Daarnaast is het belangrijk om een klant snelle feedback te geven zodat hij/zij vroegtijdig de eisen kan bijstellen en het project kan bijsturen als de eisen niet accuraat genoeg waren. Alles draait om flexibiliteit en wendbaarheid, vandaar de naam Scrum, een spelsituatie uit de sport Rugby. Scrum zorgt ervoor dat deze belangrijke voorwaarden voor succes op een effectieve en efficiënte wijze worden geïmplementeerd en kunnen worden uitgevoerd. Zoals gezegd gaan we niet het volledige Scrum proces beschrijven en uitvoeren. We gaan het toespitsen op de kleine projecten die we doen bij het vak informatica. De volgende belangrijke aspecten gaan een rol spelen tijdens onze praktische opdrachten: Sprint Scrum Board rollen Daily Scrum Meeting decompositie & deelproducten planning & tracking Deze aspecten gaan we in de volgende hoofdstukken behandelen. Let op, links in dit document hebben een rode kleur. Veel plezier en succes

5 2. Sprint 3 Een heel belangrijke eigenschap van Scrum (en alle andere Agile Software Development methodes) is dat de methode iteratief is. Iteratief betekent dat het ontwikkelteam niet in één keer naar het eindproduct toewerkt maar dat er deelproducten worden gerealiseerd die stap voor stap bijdragen aan het eindproduct. Ieder deelproduct is het resultaat van een iteratie die we bij Scrum een Sprint noemen. De meeste mensen kennen het spel Pong. Als je dit spel wilt maken kun je simpelweg in één keer het spel maken. Voor een klein en eenvoudig spel als Pong is deze strategie niet eens heel slecht als je weet dat je voldoende tijd hebt om het af te krijgen. Toch kun je ook voor zo'n klein spel Scrum gebruiken en is dit zelfs de veiligste manier. Als je onverhoopt toch tegen problemen aanloopt heb je bij Scrum nog deelproducten die af zijn. In het andere geval heb je mogelijk een spel dat niet getest is en niet of niet goed werkt. Als je Pong met Scrum aan zou pakken dan kunnen daar bijvoorbeeld de volgende deelproducten uitkomen naar aanleiding van de uitgevoerde activiteiten in de Sprints: 1. Het speelveld met achtergronden, de batjes en het balletje. Het balletje botst tegen de batjes en de boven- en onderkant van het speelveld. Bij ieder nieuw spel wordt een andere achtergrond gekozen. Het balletje verdwijnt aan de linker- en rechterkant uit het veld. 2. Het spel detecteert dat het balletje links of rechts uit het speelveld verdwijnt, houdt de score bij en zet een nieuw balletje in het veld. Het spel kan een winnaar bepalen en de winnaar van een spel kan zijn/haar naam invullen en komt in de high score. De high score wordt getoond na een spel. De snelheid van het balletje gaat omhoog naarmate de tijd vordert. 3. Er zit geluid in het spel en bij ieder nieuw spel is er een ander achtergrond muziekje. Geluid kan aan- en uitgezet worden. Er is een menu met keuze tussen twee moeilijkheidsgraden. De hoogste moeilijkheidsgraad betekent dat er kleinere batjes worden gebruikt. Ieder deelproduct kun je dan laten zien aan de klant die er feedback op kan geven. Als je tijd tekort hebt en de derde Sprint kun je niet afmaken dan heb je nog steeds een speelbaar spel. Zelfs na de eerste Sprint heb je in principe een speelbaar spel als is dit niet de meest ideale oplossing. Sprints hebben een vaste tijdsduur waarvan niet afgeweken wordt. Voor de eerste Sprint begint is er vaak een opstartfase en aan het einde van het project is er nog een afsluitfase. Om met Sprints van vaste lengte te kunnen werken en toch flexibel

6 te blijven gebruiken we een speciale planning en tracking methode waarop we later terugkomen. Bij onze kleine praktische opdrachten hebben we een opstartfase van 1 week en duren de Sprints ook 1 week. De laatste Sprint is de afsluitfase. Bij de grotere eindopdracht hebben we wederom een opstartfase van 1 week en duren de Sprints 2 weken. Ook hier is de laatste Sprint weer de afsluitfase. Tijdens iedere sprint worden de traditionele activiteiten van het softwareontwikkelproces uitgevoerd, te weten: het selecteren van de eisen voor de sprint het ontwerpen van de functionaliteit op basis van de eisen het implementeren van de ontworpen functionaliteit het testen van de gerealiseerde functionaliteit Schematisch ziet dit alles er als volgt uit. eisen & test eisen selectie eind test & evaluatie test implem entatie ontwerp - 5 -

7 3. Scrum Board Het Scrum Board is het fysieke of virtuele bord waarop de planning en voortgang per Sprint wordt bijgehouden. Het Scrum Board kan op vele manier ingedeeld worden. Een veel voorkomende manier is het gebruiken van vier kolommen zoals je hierna ziet. In het To Do gedeelte staan de activiteiten van de Sprint waar nog geen enkel teamlid aan begonnen is. Dit wordt ook wel de backlog genoemd. In het In Progress gedeelte staan de activiteiten waar op dit moment door teamleden aan gewerkt wordt. Deze zijn altijd afkomstig uit het To Do gedeelte. Bij iedere activiteit wordt aangegeven wie er aan de activiteit werken en wanneer de activiteit gestart is. In het To Verify gedeelte staan de activiteiten die getest kunnen worden. Bij iedere activiteit wordt aangegeven wie de activiteit gaat verifiëren en wanneer de activiteit uit In Progress is gekomen. In het Done gedeelte staan de activiteiten die klaar zijn. Bij iedere activiteit wordt aangegeven wanneer de activiteit uit To Verify is gekomen. We gaan ons Scrum Board maken in een virtuele omgeving die Trello heet. Deze omgeving vind je op de website van Trello. Ieder teamlid heeft toegang tot het Scrum Board en is actief betrokken bij het bijhouden van het bord en de voortgang

8 4. rollen Scrum Master De Scrum Master is feitelijk de teamleider van het project. Hij/zij heeft de volgende verantwoordelijkheden binnen het project. meewerken met het team aan het product opzetten van het Scrum Board voorbereiden van de Sprints voorbereiden van het Scrum Board voor iedere Sprint bijeenroepen en voorzitten van de Daily Scrum Meetings monitoren (in de gaten houden) van het Scrum Board bijhouden van het Plan van Aanpak en de planning De Scrum Master hoeft niet de persoon te zijn die het initiële Plan van Aanpak schrijft. Het feit dat er een Scrum Master is wil niet zeggen dat de andere teamleden niets van het proces af hoeven te weten. Ieder teamlid houdt namelijk actief zijn/haar eigen voortgang op het Scrum Board bij. Feitelijk is ieder teamlid in staat in meer of minder mate het proces te begeleiden en te coördineren. Als de Scrum Master bijvoorbeeld ziek is wil dat niet zeggen dat het proces stil ligt, een teamlid neemt de rol dan tijdelijk over. Scrum Member Zoals gezegd houdt ieder teamlid zijn/haar eigen voortgang bij op het Scrum Board. Wanneer een teamlid dit verzuimt dan wijzen of de Scrum Master of andere teamleden hem/haar hierop. Teamleden weten van elkaar waar ze mee bezig zijn en proberen zoveel mogelijk van elkaar te leren. Teamleden bekijken en reviewen (bestuderen en becommentariëren) elkaars werk om het beter te maken. Teamleden houden elkaar op de hoogte bij afwezigheid. Dit is niet alleen de taak van de Scrum Master. Met name als deze afwezig is moeten de teamleden hem op de hoogte houden en zijn taken zo goed mogelijk overnemen

9 5. Daily Scrum Meeting 4 Deze meeting wordt ook wel de Stand-Up Meeting genoemd. De reden is dat bij deze bijeenkomst iedereen staat in plaats van zit. Uit onderzoek is gebleken dat vergaderingen die staand worden gehouden doorgaans minder lang duren en even effectief zijn, zie onder andere APA PsycNET. Aan het begin van iedere les wordt daarom een korte Stand-Up Meeting gehouden. Deze wordt bijeengeroepen en voorgezeten (of in dit geval voorgestaan) door de Scrum Master. De meeting duurt maximaal 5 minuten. In deze meeting geeft ieder teamlid het volgende aan: lig ik op planning wat heb ik vorige les afgekregen wat ga ik deze les doen heb ik problemen die mijn voortgang hinderen De Scrum Master maakt notulen van de meeting en deze neem je op in je verslag. De meeting houd je dus staande behalve als je in tweetallen werkt. In de meeting besproken procesproblemen worden gedocumenteerd in het Plan van Aanpak, productproblemen worden gedocumenteerd in het Ontwerp Document. Tijdens de meeting wordt besloten wie wat documenteert

10 6. decompositie & deelproducten 5 Decompositie is het opdelen van een totaalprobleem in deelproblemen. Het decompositieproces stop wanneer je deelproblemen overhoudt die je ofwel (her)kent (standaardproblemen) of waarvan je inschat dat je ze (relatief makkelijk) op kunt lossen. Nadat deelproblemen opgelost zijn moeten de oplossingen samengevoegd worden zodat het totaalprobleem opgelost wordt. Schematisch kun je dat afbeelden zoals hierna is gedaan. Decompositie is belangrijk omdat kleine problemen makkelijker en betrouwbaar op te lossen zijn dan grote. Bovendien kun je risicovolle problemen als eerste oplossen zodat je snel risico's aan kunt pakken en uit de weg kunt ruimen. Bij decompositie is KISS (Keep It Short & Simple, of ook wel Keep It Simple, Stupid) een belangrijk principe. Het resultaat van decompositie documenteren op een manier zoals je hierna ziet afgebeeld is niet optimaal paimeiitguy.files.wordpress.com/2008/07/iasample1.jpg - 9 -

11 In de voorgaande afbeelding zie je door de bomen het bos niet meer. Het is daarom belangrijk verschillende views (aanzichten) te definiëren die ieder een deel of aspect van de decompositie laten zien. In bijvoorbeeld de huizenbouw staat ook niet alles in één document of tekening. Je hebt daar bouwtekeningen met verschillende aanzichten. Je hebt daar een bestek waarin de te gebruiken materialen staan beschreven. Ook heb je aparte constructietekeningen en -berekeningen. Bij het KISS principe begin je met het beschrijven, ontwerpen, realiseren en testen van het kleinst mogelijke systeem dat kan werken. Hierin zitten bij lange na niet alle eisen verwerkt. Dit eerste product is de basis om de nog niet gerealiseerde eisen aan toe te voegen. Door steeds weer eisen aan je product toe te voegen zorg je er ook voor een goede uitbreidbaarheid van je product. Als de klant dan tijdens het project nog met eisen komt die in het begin niet bekend waren, dan kunnen deze waarschijnlijk relatief makkelijk toegevoegd worden. Dit draagt bij aan de flexibiliteit die we zo belangrijk vonden. Een ander voordeel van een zo klein mogelijk werkend systeem maken is, zoals eerder gezegd, dat je onzekerheden snel weg kunt nemen. Je toont immers vroegtijdig aan dat je een werkend systeem kunt realiseren. Dit heet het aantonen van de haalbaarheid (feasibility). Bovendien kan een klant met dit systeem aan de slag en er feedback op geven. De KISS aanpak past goed bij iteratieve processen en dus ook bij Scrum. In een klein aantal Sprints, liefst één, bouw je het kleinst werkende systeem. In de verdere Sprints ga je het systeem gecontroleerd uitbreiden zodat het resultaat van de Sprint werkt en getest en door de klant gebruikt kan worden. Deze aanpak lijkt op het eerste gezicht extra tijd te kosten door de overhead (extra werk) van de Sprints. In de praktijk blijkt echter dat door deze gecontroleerde manier van ontwikkelen over het hele project geen tijdsverlies maar juist tijdswinst wordt behaald. Dit komt met name omdat je goed in staat bent vroegtijdig risico's te zien en deze aan te pakken door snelle feedback van de klant. Dat laatste verhoogt de kans dat je maakt wat de klant wil significant (in hoge mate)

12 7. planning & tracking 7 Plannen is een onzekere activiteit. Je probeert immers in te schatten 8 hoeveel tijd je nodig denkt te hebben om een activiteit af te ronden. Ervaring helpt om beter te leren schatten maar zelfs met ervaring zijn er altijd onvoorziene omstandigheden. Daarom is plannen alleen niet voldoende en moet je ook aan tracking doen. Dat wil zeggen dat je regelmatig kijkt of je planning wel klopt. Als dat niet het geval is moet je de planning bijstellen. Bij Scrum krijg je iedere Sprint feedback over de planning en die kun je bij de planning van de volgende Sprint dus gebruiken. Dus ben in het begin niet bang om verkeerd te schatten! Je kunt je planning snel genoeg bijstellen. 9 Om je Sprints optimaal en toch flexibel te plannen is de MoSCoW methode uitermate geschikt. De medeklinkers in de naam van de methode zijn de categorieën waarin je eisen van de klant kunt opdelen. Eisen in de categorie Must (M) zijn eisen die je in een sprint af moet hebben. Eisen in Should (S) wil je heel graag af hebben. Feitelijk zou je een Sprint zo moeten plannen dat je alle M en S eisen ook daadwerkelijk af hebt aan het einde van de sprint. Zoals gezegd is dat lastig omdat plannen een onzekere activiteit is. Het is daarom niet erg als je een aantal S eisen niet af hebt. Maar wat als je tijd over hebt? Dat is de reden dat je de categorie Could (C) hebt. Dit zijn de eisen die je doet als je tijd over hebt in een Sprint. De laatste categorie, Won't (W) gaan we niet gebruiken. Deze wordt wel gebruikt door volledig geautomatiseerde Scrum tools maar voor ons heeft het weinig zin om voor iedere Sprint aan te geven wat we toch niet gaan doen. Het is echter wel belangrijk om dus zoveel C eisen in je Sprint op te nemen dat je van tevoren eigenlijk al weet dat je die nooit allemaal af gaat krijgen! 7 massachusetts-reverse-mortgage.com/wp-content/uploads/2011/05/puzzled-150x150.jpg 8 schatting: onnauwkeurige berekening van de waarde of grootte van iets (encyclo.nl) 9 upload.wikimedia.org/wikipedia/commons/4/40/sant_vasily_cathedral_in_moscow.jpg

13 Om de categorie van een eis goed te herkennen op het Scrum Board, spreken we de volgende kleurcodering af: M eisen hebben de kleur groen. S eisen hebben de kleur geel. C eisen hebben de kleur oranje. Mocht je toch met W eisen willen werken dan hebben die de kleur rood. Nu volgt een overzicht van activiteiten die je moet doen om je proces goed te laten verlopen. Opstartfase Het team bepaalt wie Scrum-master is. Het team brainstormt over wat er gemaakt gaat worden en maakt een keuze. Het team brainstormt over eisen. De team leden werken de volgende documenten individueel uit: o Plan van Aanpak o Product Beschrijving & Eisen o Test Document De Scrum Master archiveert de initiële versie van de gemaakte documenten. Sprint voorbereiding: o De Scrum Master maakt het Scrum Board klaar voor de komende Sprint. o De Scrum Master zet de eisen voor de komende Sprint op het Bord. o De Scrum Master doet voor alle eisen op het Bord een voorstel voor de MoSCoW categorisering. iedere Sprint o Het team bespreekt het voorstel op het Bord en maakt zo nodig wijzigingen. o De Scrum Master maakt een snapshot van het Bord voor in het Plan van Aanpak. o Ieder teamlid kiest samen met de Scrum Master een eis van het Bord. Als de huidige eis klaar is wordt een nieuwe eis gekozen. o De teamleden geven hun eigen voortgang aan op het Bord. o De teamleden doen ontwerp, implementatie en test voor de door hen gekozen eisen. o Het team test het deelproduct tegen het einde van de Sprint. o De Scrum Master archiveert het deelproduct. o De Scrum Master maakt een eind snapshot van het Bord voor in het Plan van Aanpak

14 Afsluitfase Het team laat hun product testen door anderen. Gevonden bugs worden gedocumenteerd maar niet meer opgelost. Ieder teamlid reflecteert individueel over het product, het teamproces en het eigen proces (verplicht bij eindopdracht, anders optioneel). De reflectie wordt gedocumenteerd en behoort tot de deliverables (oftewel is onderdeel van de in te leveren documentatie). De Scrum Master verzamelt alle deliverables en levert ze in via Moodle. tot slot Begin met hard werken! In het begin kom je namelijk de meeste onzekerheden en risico's tegen en pas als je die hebt weggenomen wordt je project voorspelbaarder. Op deze manier werken voorkomt stress!