Definitief 1.0 Handreiking voor toepassen van Agile Scrum binnen Overheidsdiensten april 2012

Transcriptie

1 1 Kennis Agile Scrum 1.1 Inleiding In dit eerste deel wordt de lezer meegenomen in de Agile Scrum methodiek. Binnen DR, onder meer met ondersteuning vanuit Quintor, worden steeds meer projecten op deze wijze uitgevoerd. Als aanvulling op het Handboek Projectmatig Werken passeren in een notendop de belangrijkste zaken rondom Agile Scrum. 1.2 Scrum een introductie De basis van Scrum is de Sprint, een periode van 3 tot 4 weken waarin het team werkt aan een vooraf vastgesteld Sprintdoel. Tijdens de Sprint werkt het team aan taken die in de Sprint Backlog zijn gedefinieerd. Deze taken worden uit de Product Backlog gehaald. De Product Backlog wordt in het begin van het project opgesteld door de Product Owner en bestaat uit alle functionaliteiten die in het project moeten worden ontwikkeld. Rondom de Sprint is een aantal meetings georganiseerd: de Sprintplanning, Daily standup, Demo en Retrospective. Voor het faciliteren van deze meetings is de Scrum Master verantwoordelijk. Afbeelding 1: Agile Scrum in een notendop Pagina 6 van 39

2 1.3 Rollen Het SCRUM TEAM Het Scrum team zorgt ervoor dat de functionaliteit uit de Sprint Backlog tijdens de Sprint wordt ontworpen, ontwikkeld en getest. Het team bestaat doorgaans uit 5-9 personen. Een grootte die, door ervaring en onderzoek aangetoond, het meest effectief is. Het team is zelforganiserend en de leden hebben een gezamenlijke verantwoordelijkheid voor de resultaten. De PRODUCT OWNER Een Product Owner verzamelt alle wensen en eisen t.b.v. het product en prioriteert de te ontwikkelen functionaliteit in de Product Backlog. Hiermee vertegenwoordigt de Product Owner de stem van de klant en zorgt ervoor dat het Scrum team bezig is met de voor de klant op dat moment belangrijkste functionaliteit. De Product Owner is vaak de klant, maar kan ook iemand zijn vanuit de interne organisatie. De functie vereist uitgebreide kennis over business processen. De Product Backlog is zichtbaar voor de hele organisatie zodat iedereen zich bewust is van wat er is te verwachten in toekomstige versies van het product. De SCRUM MASTER De Scrum Master zorgt ervoor dat het team de best mogelijke omstandigheden heeft voor het realiseren van het Sprintdoel. Het oplossen van de problemen en belemmeringen die binnen het team bestaan is de verantwoordelijkheid van de Scrum Master. Ook faciliteert de Scrum Master het Scrum-proces binnen het team. Hiermee is de Scrum Master probleemoplosser en coach. Tijdens de Sprint organiseert de Scrum Master dagelijks een Standup. Na elke Sprint organiseert de Scrum Master een Demo, Retrospective en Sprintplanning voor de volgende Sprint. Ook zorgt de Scrum Master voor een goede voorbereiding van deze meetings. Pagina 7 van 39

3 De PROJECTLEIDER De Projectleider krijgt van de stuurgroep de verantwoordelijkheid en bevoegdheid voor de dagelijkse gang van zaken in het project. Hiervoor stelt hij het projectplan op en regelt de bemensing en middelen. De projectleider kan beslissingen nemen binnen de grenzen zoals aangegeven door de stuurgroep. De belangrijkste verantwoordelijkheid van de projectleider is het zekerstellen dat het project de gewenste producten oplevert, binnen tijd, binnen budget en volgens de afgesproken kwaliteit. De projectleider faciliteert het Scrum team door impediments op te lossen die buiten het Scrum team liggen. Voor de Scrum Master is hij coach en ondersteuner. Ook faciliteert de projectleider de Product Owner bij het maken van keuzes en hij rapporteert de voortgang aan de stuurgroep. De projectleider vergewist zich ervan dat het project conform de afspraken wordt beheerst en uitgevoerd en managet risico s en budget. 1.4 Proces De PRODUCT BACKLOG De Product Backlog is een geprioriteerde lijst van alle user stories (stukjes functionaliteit) die in het project moeten worden ontworpen, ontwikkeld en getest. Deze lijst wordt voor de start van het project door de Product Owner samengesteld en mag tijdens het hele project worden gewijzigd. De items die als hoogst geprioriteerd staan worden verder in detail uitgewerkt. De items die lager op de lijst staan blijven in algemene bewoordingen totdat zij door de Product Owner belangrijk genoeg worden gevonden om in de komende Sprint op te pakken. De SPRINT BACKLOG De Sprint Backlog is de lijst van user stories die in de komende Sprint moeten worden ontworpen, ontwikkeld en getest. Dit zijn de hoogst geprioriteerde user stories uit de Product Backlog. De Sprint Backlog wordt tijdens de Sprintplanning samengesteld en mag tijdens de Sprint niet worden gewijzigd. Welke user stories in de Sprint Backlog komen te staan is afhankelijk van welke prioriteit de user story heeft en de beschikbare tijd van het team. Voor stories in deze backlog geldt dat ze moeten voldoen aan de Definition of Ready. De SPRINTPLANNING Bij de Sprintplanning zijn het team en de Product Owner aanwezig. Tijdens de Sprintplanning wordt het doel van de komende Sprint vastgesteld in de vorm van een Sprintdoel en Sprint Backlog. De Product Owner heeft tijdens de Sprint Planning de verantwoordelijkheid om het team de inhoud van de user stories uit te leggen en het Sprintdoel te formuleren. Het team heeft de verantwoordelijkheid te berekenen welke user stories zij kan oppakken in de Sprint (afhankelijk van de beschikbare tijd, velocity en inschatting van de zwaarte van de opgenomen user stories). Pagina 8 van 39

4 De DAILY STANDUP Elke dag, op hetzelfde tijdstip, komen het team en de Product Owner bij elkaar voor een Daily Standup. Deze meeting duurt maximaal 15 minuten en gebeurt staand. Tijdens de Daily Standup geeft elke deelnemer aan de hand van de user stories antwoord op de volgende vragen: Wat heb je gedaan sinds de laatste Standup? Wat ga je doen tussen nu en de volgende Standup? Loop je tegen problemen aan die je belemmeren in de uitvoering van je werk? De eerste twee vragen geven de deelnemers inzicht in de voortgang van de Sprint c.q. het project. De derde vraag levert een lijst van belemmeringen op die de Scrum Master samen met de projectleider moet opheffen. Iedereen kan deelnemen en luisteren tijdens de Standup, maar alleen de Scrum Master, Product Owner en de teamleden mogen spreken. Eventuele discussiepunten en het maken van afspraken worden geparkeerd tot na de Standup. De DEMO Aan het eind van de Sprint geeft het team een Demo aan alle stakeholders van het project, waarin getoond wordt wat er de afgelopen Sprint is opgeleverd. Het doel van de Demo is het ontvangen van feedback op de ontwikkelde functionaliteit. Deze feedback wordt door de Product Owner verzameld, geprioriteerd en op de Product Backlog geplaatst. Belangrijk is dat alle stakeholders bij de demo s vertegenwoordigd zijn. De RETROSPECTIVE Na de Demo voert het team samen met de Product Owner een Retrospective uit. Tijdens de Retrospective worden de ervaringen van de afgelopen Sprint besproken en worden er actiepunten voor de komende Sprint geformuleerd. Elke deelnemer geeft antwoord op de volgende vragen: Wat ging er goed en moeten we in de komende Sprint behouden? Wat ging er minder goed en kunnen we in de komende Sprint verbeteren? Welke actiepunten voor de komende Sprint kunnen we hieruit formuleren? De BURNDOWN CHART De Burndown Chart is een grafiek die laat zien hoeveel werk er nog gedaan moet worden in de Sprint om het Sprintdoel te halen. Op de x-as staat het aantal dagen van de Sprint, op de y-as het aantal story points of user stories dat in de Sprint Backlog is opgenomen. De groene lijn geeft aan welk deel van de stories afgerond zijn. Pagina 9 van 39

5 1.5 Agile Ontwikkelmethodieken Er bestaan verschillende Agile ontwikkelmethodieken waarvan Scrum de meest gebruikte methodiek is. De verschillende Agile methodieken hebben een aantal kenmerken die steeds weer terugkomen: een nauwe samenwerking tussen business en IT het werken in korte iteraties het kunnen omgaan met veranderingen in projecten De basis van Agile softwareontwikkeling is het Agile Manifesto, gepubliceerd in Utah in Hierin staat het volgende: Individuen en interactie boven processen en tools Werkende software boven uitgebreide documentatie Samenwerking met de klant boven contract onderhandelingen Reageren op verandering boven het strikt volgen van een plan Wat rechts staat is waardevol, maar wat links staat is waardevoller (Bron: Manifest voor Agile Software Development De Agile methodieken zijn een reactie op ontwikkelprocessen die er in theorie goed uitzien, maar in de praktijk niet goed werken. Waar oudere methoden een poging doen in de onzekere toekomstige behoeften van de klant te voorzien, zijn Agile methoden adaptief en kunnen zich dus direct aanpassen aan veranderende omstandigheden. De Agile methodieken zijn daarom omschreven als empirisch. Ze zijn volledig gebaseerd op de praktische ervaringen en werkwijzen die zich bewezen hebben te werken. Een ander belangrijk uitgangspunt is eenvoud en Lean Thinking. Dit houdt bijvoorbeeld in dat er geen tijd wordt besteed aan het schrijven van onnodige documentatie, maar alleen aan documentatie die ook daadwerkelijk wordt gebruikt. Andere Agile methode Een andere Agile methode is Lean Development, die voortvloeit van de ust-in-time en Lean Productie concepten. Lean Development richt zich meer op de organisatie van de ontwikkelactiviteiten van het gehele bedrijf op managementniveau. Deze Agile-methoden kunnen worden beschouwd als aanvulling op elkaar, waar: Lean Development de gehele ontwikkeling binnen de organisatie behandelt; Scrum gaat over hoe het project is georganiseerd en gepland. Pagina 10 van 39

6 1.6 Agile en Prince 2 DR maakt gebruik van Prince 2 (P2) als projectmanagement methodiek. De ontwikkelmethodiek Agile Scrum sluit daarbij goed aan. AS biedt alleen een methodiek en regels voor de fase waarin de uitvoering wordt gedaan. Voor de voorbereiding (met sprint 0) en de overgang naar beheer schrijft AS niets voor. De templates van P2 zijn voor die fasen (b.v. de PID bij de voorbereiding) te gebruiken. In de afbeelding hieronder zijn de fases in een AS project geprojecteerd op die van P2. Analyse Sprint 0 Sprint 1 Sprint 2 Wat (Starting up a Project Prince2) Hoe / Scrum (Initiating a Project Prince2) Uitvoering / Scrum (Controlling a Stage en Managing Stage Boundaries Prince2) Sprint 3 Sprint 4 Sprint 5 Beheer Beheer (Closing a Project Prince2) Afbeelding 2 : Uitvoering Agile Scrum project en Prince 2 project methodiek Hoe binnen een P2 project de sprints van Scrum vallen, wordt in onderstaande afbeelding weergegeven. Het rode blok is het deel van een P2 project waar scrum toegepast wordt. Directing a project Starting up a Project Initiating a Project Controlling a Stage Managing Stage Boundaries Closing a Project Managing Product Delivery Sprint 1 Sprint 2 Sprint 3 Directing a project Afbeelding 3 : Uitvoering sprints binnen Prince 2 project methodiek Pagina 11 van 39

7 Om binnen Prince 2 software te ontwikkelen is Scrum een van de mogelijkheden, naast Waterval en Innovation Lab. Hieronder staat een opsomming van criteria om de best passende methode in (software) ontwikkeling te kiezen. Afbeelding 4 : Keuze software ontwikkelmethodiek binnen Prince 2 Pagina 12 van 39