SCRUM workshop

Introductie

Leuk, maar wie is verantwoordelijk voor de deployment? Ze zeggen dat dit de manier is. Laten we het maar gewoon doen... Leuk, maar wie is verantwoordelijk voor de deployment?

The Problem: The Chaos Report Onderzoek gestart in1994 Ruim 35,000 software development projecten bekeken In 2000: Source: Standish “Chaos” Report, Jim Johnson lecture at XP2002 conference: http://www.xp2003.org/xp2002/talksinfo/johnson.pdf

Functies gebruikt in een typisch systeem One problem with the Chaos report is it measures success against the original requirements, which have a tendency to change during the project. Begs the question of which of the original requirements should have been delivered, ever? Is this a reasonable way to measure software development success? Source: Jim Johnson lecture at XP2002 conference

Waarom mislukken IT projecten? Aannames Gewijzigde prioriteiten Gebrek aan samenwerking Omgeving wijzigt Beperkingen in communicatie Probleem is niet duidelijk Oplossing is onbekend Technische beperkingen …

Voorbeelden: Er gaat iets fout tijdens de deployment. Traditioneel: extra controles, 4 ogen principe etc = processen. Agile: samenwerken Een bug vinden in de documentatie, wow. 2x het systeem gebouwd. Geschreven documenten zijn vaak dikker dat de code. Voorbeeld multomap vs 60 regels code (fondskoers inlezen: datamodel, use case, ucr, logica, ui design). En 4) Tekening plan volgen versus sprint en bijstellen. Wat levert meer op? Bron: http://agilemanifesto.org/iso/nl/

Waterfall vs Agile

Coingame

Wat is Scrum

Wat is Scrum Ontwikkelt in’90 – ’96 door Ken Schwaber & Jeff Sutherland Simpel en populair framework Youtube: Jeff Sutherland breaks down the structure of scrum

Scrum = Prioriteren op waarde Voorspelbaarheid Feedback Fun

Scrum overview D.O.R. D.O.D. Scrum bord Burndown Belemmeringen 3 2 1 Dagelijkse update 8 13 5 20 40 100 3 wekelijkse sprint Sprint Demo & retrospective Productbacklog Sprintplanning Sprint backlog Shipable product D.O.R. D.O.D.

Scrum overview 3 rollen 4 gebeurtenissen 4 artifacten Team Product owner Scrummaster 4 gebeurtenissen Sprintplanning Daily scrum Sprint demo/review Sprint retrospective 4 artifacten Product backlog Sprint backlog Burndown Definition of Done Scrumguide (scrum.org)

Scrum Board

Ideale setup? Backlog en scrumboard visueel?

Burndown? Velocity? Zie ook de timeboxes!

Retrospective

Large scrum: 5 teams parallel.

Teamwork

3 rollen Team Productowner Scrummaster

Productowner Bepaalt de functionaliteit van het product Bepaalt de einddatum en inhoud Is verantwoordelijk voor de winstgevendheid (ROI) Bepaalt functionaliteit en prioriteit in volgorde van marktwaarde Functionaliteit en prioriteit kunnen elke iteratie aangepast worden, naar behoefte Accepteert het uiteindelijke resultaat (of niet)

Geschreven specificaties Maak 2-tallen (Analist en Developer) Developers gaan de zaal uit Analisten maken in 5 minuten geschreven specificaties Analist geeft specs aan Developer zonder te spreken Developer krijgt 5 minuten om de specs te realiseren

Geschreven specificaties

Product backlog = userstory Sprint 1 Sprint 2 Schatting Done bij een Velocity van X Schatting Done bij een velocity van Y

Userstory Userstory: As a <role> I want to <what> So that <why> +/- requirement Notes: e.g. ref to wireframe, non-functional requirement etc. Zou gekoppeld kunnen worden aan testscenario’s en testscripts How to demo / how to test: <as smart as possible> Estimate <story-points>

Effective Communication

Scrum team Gebruikelijk 5-9 mensen Multi-disciplinair: Programmeurs, testers, ontwerpers, etc. Leden zijn fulltime toegekend Teams organiseren zichzelf In het ideale: helemaal geen titels/rollen Teamindeling is vast Focus

Scrummaster Verantwoordelijk voor de toepassing van Scrum waarden en normen Wegnemen van belemmeringen Zorg voor optimale productiviteit van het team Zorg voor samenwerking tussen de verschillende disciplines en rollen Schermt het team af van verstoringen van buiten het team

4 Meetings Sprint planning Daily scrum Sprint review Sprint retrospective Alle meetings getimeboxed

Sprintplanning Ref Mike Cohn “Agile Estimation and Planning” (zie ook YouTube) Een aantal biologische feiten: Het is voor het menselijk brein moeilijk tijd in te schatten, zeker als het meer dan een aantal uur is. Dit wordt uitvergroot door de hoeveelheid onzekerheden in software development, druk vanuit management verschil in skills van het team, … Echter, we zijn redelijk goed in het vergelijken van dingen. Dat kunnen we vrij accuraat.

Uren of storypoints Planning op basis van uren: Minder dan 1 dag: 1, 2, 4 of 8 uur. Meer: 2, 3, 5, 10 dagen, 1 maand etc. Als aan een taak gewerkt is wordt het restant opnieuw geschat. Plannen op basis van StoryPoints: Het idee is om één referentie user story een aantal story points te geven en vervolgens andere user stories, punten te geven relatief t.o.v. de referentie. Voordeel: snel en gezamenlijk. Schatting is een beladen woord, misschien gokken of fantaseren noemen? Voorbeeld: geef een schatting om van hier naar centrum van den haag te komen: welk vervoermiddel, welke status, drukte, ken je de weg Hoe kunnen we iets schatten wat nog niet bestaat Pokerspel laten zien – afgeronde fibonacci reeks (rij van Fibonacci) 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 steeds twee voorgaande optellen 0, 0.5, … 20 ,40, 60, 100

Planning poker Simpele en effectieve methode die als team uitgevoerd kan worden Zorgt voor interactie tussen alle team leden en product owner Snel achterhalen van de daadwerkelijke opdracht. Zorgt voor een gedragen schatting van het gehele team. Regels: Productowner leest user story voor en geeft toelichting Vragen stellen/discussie over de userstory Iedereen trekt een kaart en legt hem omgekeerd neer Alle kaarten worden tegelijk omgedraaid Alle schattingen gelijk -> Volgende userstory Schattingen ongelijk -> hoogste en laagste geven toelichting, daarna opnieuw naar 3 (zolang het nodig is).

Storypoints vertaald naar planning De velocity is het aantal storypoints het team kan afronden in de gegeven tijd (sprint). Het team kan haar velocity pas bepalen na een aantal sprints (4+).

Samenvatting Focus op continue verbeteringen Snel inspelen op veranderingen Waarde toevoegen, belangrijkste eerst (backlog) Timebox (sprint) 3 rollen (productowner, team, scrummaster) 4 meetings (planning, daily, demo, retro)

Simplifying Life with SCRUM Twitter: #intoscrum