Agile Development
in the real world
Agile, wat is dat?
Gebaseerd op 12 pijlers
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily cooperation between business people and developers
- Face-to-face conversation is the best form of communication
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Self-organizing teams
- Regular adaptation to changing circumstances
Maar wat betekent Agile nu ècht?
Agile staat voor:
- Kwaliteit (zowel technisch als design)
- Werkende software wordt in iteraties opgeleverd
- Flexibiliteit, inspelen op een veranderlijke markt
- Beslissingen zo lang mogelijk uitstellen
- Mensen van business & development werken dagelijks samen
- Werkende software is dé manier om voortgang te meten
- Men vertrouwd het development team en laat hen naar eigen inzicht het werk indelen en inschatten
"Move quickly!"
Kernpunten
Adaptief vs. predictief
Doelstellingen zijn duidelijk maar weten nog niet hoe deze behaalt gaan worden. Doelstellingen kunnen zelfs nog veranderen.
Iteratief vs. waterval
In
korte cyclussen wordt getest en geleverd. Fouten worden snel opgespoord
en er wordt bijgestuurd n.a.v. voortschrijdend inzicht.
Code vs. documentatie
Spendeer zoveel mogelijk tijd aan het daadwerkelijk 'bouwen'. Limiteer documentatie tot een minimum.
Meest bekende Agile frameworks
SAFE framework
Voorbereiding
Uitgevoerd door Product Owner (& product management)
- Business case
- Road map
- Visie
- Release plan
- Product backlog
Business case
Visie
Van epic naar story
Product backlog
Geprioriteerde lijst (enige bron) van alles wat het product zou moeten kunnen. Het richt zich op de mogelijkheden van het product en niet op werktaken. Dit zorgt ervoor dat het backlog doelgericht is en blijft.
Het richt zich op WAT en niet hoe.
Bestaat uit epics en user stories.
Rol van Product Owner
- Is marktgericht
- Ontwikkelt een productstrategie voor zowel lange- als korte termijn
- Duidelijke visie over productpositionering ten opzichte van de concurrentie
- Denkt na over de levensvatbaarheid van het product op lange termijn
- Maakt geen "knee jerk"* beslissingen
- Is verantwoordelijk voor de voorbereidende fase en het product backlog
Rol van Architect
- Waakt ervoor dat externe systemen, -partners, applicaties van derden en andere gebruikers van de applicatiedata niet worden vergeten
- Adviseert de PO in het prioriteren van issues door in kaart te brengen wat de mogelijke technische oplossingen zijn en wat de vereiste inspanning hiervan is
- Stelt vast welke rollen en vaardigheden nodig zijn om het project te voltooien
Rol van UX Designer
- Brengt de gebruikersbehoefte in kaart en waarborgt deze
- Communiceert een visie voor het product en creëert een gedeeld begrip hiervan in het team
- Wakkert gesprekken/discussie aan m.b.t. ontwerp-ideeën in pril stadium
- Verantwoordelijk voor de look & feel, flow van het systeem, de GUI en gerelateerde ontwerpkeuzes
What is UX?
User experience design (UXD)
Waar hoort UX thuis?
Business value vs inspanning
Voor de Product Owner is het belangrijk om de toegevoegde waarde van een story af te wegen ten opzichte van de benodigde inspanning om de story te realiseren. Dit is namelijk een waardevolle methode om te prioriteren.
Sprint planning meeting
De Product Owner presenteert de user stories aan het development team. De inhoud wordt besproken en vragen van het team worden door PO beantwoord.
Pas als de user story wordt begrepen door het development team (status: "ready") en er door het team een inschatting (d.m.v. poker sessie) is gemaakt, kunnen deze worden opgepakt in een sprint. Denk hierbij aan acceptance criteria bij het beoordelen van de story!
Rol van Scrum Master
Keep the wolves of scope creep at bay
- Establishes practices and rules
- Ensures everyone plays by the rules
- Resists adding new features
- Coaches & shields the team
- Removes impediments
- Ensures code inspections happen
- Runs daily Scrum meetings
Poker sessie
Per story wordt er door het gehele development team een inschatting gemaakt van de hoeveelheid werk of de complexiteit. Dit is niet meer dan een schatting!
Let op: hier wordt niet geschat hoeveel uur werk het is!
Voor het schatten wordt gebruik gemaakt van kaarten voorzien van een waarde tussen 1/2 en 100 punten. Maar er zijn ook andere mogelijkheden.
Van planning naar sprint
Sprint!
Een sprint is een vastomlijnd tijdsbestek van 2 tot 4 weken waarin het development team de sprintdoelstelling behaalt. Het development team geeft een commitment af voor de (hoeveelheid) stories die zij gedurende de sprint zullen opleveren. Deze stories worden toegevoegd aan het sprint backlog. Welke stories in het sprint backlog komen is een onderhandeling tussen het development team en de product owner. De product owner kan niets aan de sprint toevoegen als de sprint eenmaal is gestart.
Het tijdsbestek van een sprint is onveranderlijk. De sprint wordt altijd afgesloten met de demo.
Scrum board
De user stories uit het sprint backlog worden toegevoegd aan het scrum board. Het development team maakt de taken aan, die bij elke user story horen. Denk aan technische taken zoals bijvoorbeeld het aanpassen van de database. Voor test bijvoorbeeld het schrijven van test cases, uitvoeren van regressie test maar ook taken als het schrijven van documentatie behoort tot de mogelijkheden.
Voor elke taak wordt ingeschat hoeveel uur werk het is.
Scrum board fasen
Doel is zo snel mogelijk alle stickies van links naar rechts te verplaatsen, met als prioriteit de bovenste stickies eerst. Als het hierbij nodig is dat collega's samenwerken (denk aan pair programming) of bijv. te hulp schieten bij test, is dit de gewenste manier van werken. D.m.v. het scrum board is heel makkelijk te zien of en waar zich een bottleneck bevindt.
Definition of Done
De Definition of Done (DoD) is een lijst van requirements en zorgt ervoor dat de componenten (stories) die worden opgeleverd aan een vooraf vastgestelde kwaliteitsstandaard voldoen. Tegelijkertijd neemt het discussies weg of een component nu écht af is. De DoD kan na verloop van tijd door het team worden aangepast, maar kan tijdens een sprint nooit veranderen. Het is goed mogelijk dat het thema van een sprint erom vraagt de DoD aan te passen.
Daarnaast is het belangrijk te weten dat men een aparte DoD kan hebben voor:
- De (user stories in een) sprint
- Een feature (reeks stories)
- Een release (reeks features)
Dit omdat het zo kan zijn dat er andere criteria en voorwaarden gelden voor een complete feature of release.
Voorbeeld Definition of Done
- Voldoet aan acceptatie criteria
- Acceptatie tests geschreven en succesvol doorlopen
- Regressietest succesvol doorlopen
- Code review (voldoet aan coding standaarden)
- Bekende bugs opgelost
- Design review
- Voldoet aan UI guidelines
- Release notes geschreven (release?)
- Design notes geschreven (feature?)
- Product documentatie bijgewerkt (feature?)
- Story geaccepteerd door PO
Daily stand-up meeting
Open communicatie is erg belangrijk in een Agile werkomgeving.
Daarom komt elke dag op een vaste tijd het development team bij elkaar om te vertellen:
- Wat heb ik gisteren gedaan?
- Wat ga ik vandaag doen?
- Zijn er belemmeringen die mij weerhouden?
Let op: de stand-up is geenszins een rapportagemiddel om tegenover de PO te verantwoorden wat de status is van elk issue! Het is daarom ook niet noodzakelijk dat de PO aanwezig is bij de stand-up. De Scrum Master is wel aanwezig, aangezien deze als taak heeft eventuele belemmeringen weg te nemen zodat het team optimaal kan functioneren.
Demo
Retrospective
Grooming
Woordenlijst
- Project backlog
- Epics (thema's/categorieën)
- User stories
- Sprint planning
- Poker sessie
- Sprint backlog
- Sprint
- Daily stand-up
- Demo
- Retrospective
- Grooming