Introductie User Stories. SYSQA B.V. Almere

Transcriptie

1 Introductie User Stories SYSQA B.V. Almere

2 Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding Wat zijn User Stories? Definitie Voordelen Verschillen tussen user stories en use cases User Stories zijn geen Requirements Voorbeelden van user stories Eisen te stellen aan User Stories Hoe User Stories te gebruiken? Waar begin je? Wanneer is user story succesvol afgerond? User stories en de planning Referenties... 9 Versiebeheer Versie Datum Opmerkingen Auteur Initiële versie Sysqa Vertaling resterende Engelse teksten Sysqa Review Sysqa Aanpassen opmaak Sysqa Verzendlijst Versie Ontvanger 0.1 Sysqa 0.2 Sysqa 0.9 Sysqa

3 Organisatie SYSQA B.V. Pagina 3 van 9 1 Inleiding Een user story is een definitie van een requirement op een erg hoog niveau. Het wordt veel gebruikt in SCRUM en Extreme Programming (XP) project teams. Het bevat nét genoeg informatie om de ontwikkelaars in staat te stellen een schatting te maken van de inspanning benodigd voor de implementatie ervan. In deze introductie komen de volgende onderwerpen kort aan de orde: Wat zijn User stories? Eisen te stellen aan User stories. Hoe User stories te gebruiken.

4 Organisatie SYSQA B.V. Pagina 4 van 9 2 Wat zijn User Stories? 2.1 Definitie User Stories is de bij agile softwareontwikkeling aanbevolen requirementsontwikkeltechniek voor het ontwikkelen van requirements. Een user story geeft aan wat het systeem voor de gebruiker moet doen. Dit moet voor de gebruiker of voor de klant van waarde zijn en in de terminologie van de business zijn geformuleerd. De beschrijving van een user story bevat slechts één of enkele zinnen. De definitie van een user story is: Een user story is functionaliteit van het systeem dat waarde heeft voor de gebruikers, gezien vanuit het gezichtspunt van de gebruiker. User stories hebben een vaste zinsopbouw: Als <gebruikersrol> wil ik <iets doen> zodat ik <er iets aan heb>. Deze zinsbouw dwingt af de user story vanuit het gezichtspunt van de gebruiker te schrijven en de aandacht te richten op de toegevoegde waarde voor de gebruiker. 2.2 Voordelen Omdat stories sommige karakteristieken van use cases of traditionele requirements statements vertonen, is het van belang na te gaan wat stories onderscheidt van deze requirements technieken. Deze verschillen kunnen leiden tot vele voordelen van user stories, waarvan enkele onderstaand zijn opgesomd. 1. User stories leggen de nadruk op verbale communicatie. Geschreven taal is vaak voor meerdere interpretaties vatbaar, en er is geen garantie dat de klant en de ontwikkelaar een statement op dezelfde manier zullen interpreteren. 2. User stories maken planning mogelijk: User stories kunnen worden gebruikt in project planning. Ze zijn zo geschreven dat van elk een schatting kan worden gemaakt van de moeilijkheidsgraad en de benodigde ontwikkelingstijd; use cases zijn over het algemeen te groot om een bruikbare inschatting te kunnen maken. Tevens wordt een story in een enkele iteratie van een agile project geïimplementeerd, terwijl het gebruikelijk is een use case te verdelen over meerdere iteraties (hoewel die iteraties normaal langer duren dan in een story gedreven project). 3. IEEE 830 style requirements statements ( Het systeem zal... ) representeren een ander probleem. Als je denkt aan de duizenden of zelfs tienduizenden items in een software requirements specificatie voor een typische applicatie, en daarbij hun onderlinge afhankelijkheden in beschouwing neemt, is het duidelijk dat het prioriteren hiervan bijna onbegonnen werk is. Als die prioritering beperkt blijft tot de gebruikelijke indeling 'hoog - middel - laag' is het onmogelijk om de requirements in een iteratief en incrementeel ontwikkelproces, dat elke 2 tot 4 weken een werkende versie moet opleveren, aan te pakken. User stories moedigen het team aan om het verzamelen van details uit te stellen. Een algemene user story ("Een recruiter kan een nieuwe vacature publiceren") kan als referentiekader dienen dat later wordt vervangen door meerdere gedetailleerde userstories. Deze techniek maakt User stories geschikt voor projecten met strenge tijdsbeperkingen, time boxes. Een team kan in korte tijd enkele tientallen user stories opstellen om een totaalbeeld van het systeem te krijgen. Vervolgens kunnen ze voor een klein aantal stories de details verzamelen en veel eerder aan het ontwerp beginnen dan wanneer ze besluiten eerst een complete set specificaties volgens IEEE 830-normen uit te werken.

5 Organisatie SYSQA B.V. Pagina 5 van Verschillen tussen user stories en use cases User stories en use cases hebben hetzelfde doel, namelijk de gebruikersrequirements communiceren aan de ontwikkelaars en de testers. Het verschil is dat user stories dit zoveel mogelijk mondeling doen en use cases hoofdzakelijk schriftelijk. Een ander belangrijk verschil tussen user stories en use cases is de scope. User stories zijn kleiner dan use cases. Een user story moet binnen tien dagen gebouwd kunnen worden. Een use case moet daarentegen alle requirements bevatten die nodig zijn bij het uitvoeren van een procestaak inclusief alle uitzonderingssituaties. 2.4 User Stories en requirements Hoewel User Stories hetzelfde effect beogen als andere software requirementspecificaties, use cases en soortgelijke documenten, wijken ze op een aantal subtiele maar fundamentele punten hiervan af. Het zijn geen gedetailleerde requirements (iets wat het systeem moet doen), maar eerder uitspraken over het doel van het systeem (het moet bij benadering dit kunnen doen), waarbij over de noodzaak en details nog onderhandeld kan worden; Ze zijn bondig en eenvoudig te lezen, en daardoor begrijpelijk voor ontwikkelaars, belanghebbenden en gebruikers; Ze representeren kleine maar waardevolle delen van de functionaliteit, die binnen enkele dagen tot weken kunnen worden gerealiseerd; Door hun geringe grootte is het eenvoudig de hoeveelheid werk die voor ontwerp, bouw en ontwikkeling nodig is te schatten; Ze zijn niet ondergebracht in grote onhandelbare documenten, maar opgenomen in lijsten, waardoor herschikking op basis van nieuwe inzichten makkelijker is; Ze zijn bij aanvang van het project nog niet gedetailleerd vastgelegd, maar worden via een 'just in time' methode uitgewerkt. Hierdoor wordt vertraging van het project vermeden, het beheer van de requirements vereenvoudigd, en voorkomen dat er te veel constraints in het ontwerp worden ingebouwd; Ze hebben weinig onderhoud nodig, en kunnen na implementatie worden afgevoerd. De user stories en de daaruitvolgende programmacode zijn input voor de documentatie, die daardoor incrementeel groeit. 2.5 Voorbeelden van user stories. Onderstaand enkele voorbeelden van user stories: Als klant wil ik de beoordelingen van een geselecteerd boek lezen zodat ik beter kan beslissen of ik het boek wil kopen. Al student wil ik mijn cijfers online bekijken zodat ik sneller weet of ik het examen heb gehaald. Als sollicitant wil ik mijn CV op de vacaturesite publiceren zodat ik hopelijk benaderd wordt door geïnteresseerde werkgevers.

6 Organisatie SYSQA B.V. Pagina 6 van 9 3 Eisen te stellen aan User Stories De eisen waaraan User Stories dienen te voldoen zijn gevangen in het Engelse acroniem INVEST. I N V E S T Independent (Onafhankelijk) Negotiable (Onderhandelbaar) Value (Waarde) Estimable (Inschatbaar) Small (Klein) Testable (Testbaar) Stories moeten zo veel mogelijk los van elkaar staan. Immers, hoe onafhankelijker ze van elkaar zijn hoe makkelijker het is om de prioriteiten tussen stories te wijzigen. Dit is soms lastig, maar op te lossen door maar soms kun je dit oplossen door de story te splitsen of twee stories juist te combineren. De beschrijving van de story moet het mogelijk maken tijdens de bouw discussie te voeren over de beschreven requirements. Stories zijn geen vervanging van het functioneel ontwerp, maar te zien als referentiepunt, om tijdens de bouw samen met de product eigenaar de details uit te werken. Userstories die functioneel helemaal afgerond zijn, kunnen de impressie wekken dat er geen discussie meer nodig of mogelijk is, terwijl dat nou juist de essentie is van user stories. De user story moet toegevoegde waarde hebben gezien vanuit de business. Een voorbeeld hiervan is wederom de eerder genoemde productcatalogus. Alleen het scherm voor het opvoeren van producten heeft geen business waarde. Immers, zolang een potentiële klant die producten nog niet kan bekijken heb je daar weinig aan. Beide schermen volledig realiseren is ook geen optie omdat dat mogelijk te lang kan duren. Maar voor de product eigenaar zou het voldoende kunnen zijn als de klant in een eerste versie alleen nog een beschrijving en een prijs kan zien. De mogelijkheid om er een foto bij te plaatsen zou wellicht in de volgende versie gebouwd kunnen worden, en is dus een aparte user story. Helaas is deze manier van opsplitsen niet zonder gevaar, dus is het zaak om samen met de product eigenaar te bekijken wanneer een story nog toegevoegde waarde heeft. Elke story dient estimable oftewel inschatbaar te zijn. Zodra je merkt dat het moeilijk is om de omvang van een user story te schatten, dan is het waarschijnlijk dat de scope van die story te groot is. Overigens mogen de schattingen voor stories die in een vroeg stadium van het project worden opgesteld nog best grof zijn. Pogingen hier een gedetailleerde schatting aan te hangen creëeren de illusie dat alle belangrijke aspecten bekend waren ten tijde van de schatting. Dit is echter zelden het geval. Het is veel belangrijker om later met alle kennis en ervaring die dan beschikbaar is een realistischer schatting te maken. Een belangrijk middel of te zorgen dat user stories schatbaar zijn is door ze klein (Small) te houden. Een goed voorbeeld: iemand in het team vragen een schatting te geven van de hoeveelheid werk voor een redelijk grote story. Als hij/zij deze vraag beantwoordt met: "Ehm, iets van een maandje of zo", dan kun je er vergif op innemen dat de ontwikkelaar nog helemaal geen beeld heeft van de inhoud en de scope van die story. In zo'n geval is het verstandig om te proberen deze story op te splitsen in een aantal kleinere stories met business value en een beperkte scope. Een user story moet voorzien zijn van een aantal meetbare criteria waarmee ondubbelzinnig bepaald kan worden of de interpretatie van het team overeenkomt met de story zoals die door de product eigenaar bedoeld was. Omdat de product eigenaar het resultaat natuurlijk nog niet gezien heeft, krijg je dit niet makkelijk boven water. Maar een hulpmiddel kan zijn te vragen hoe product eigenaar de gewenste functionaliteit zou demonstreren aan andere gebruikers. Dit wordt ook wel de how-to-demo van een story genoemd.

7 Organisatie SYSQA B.V. Pagina 7 van 9 4 Hoe User Stories te gebruiken? 4.1 Waar begin je? Stel dat je na veel overleg een lijst van user stories hebt en je begint met het realiseren van een nieuw systeem. De eerste story zal buiten de gewenste functionaliteit ook het bouwen van het skelet van je architectuur omvatten. Hoe voorkom je dat dit veel te lang duurt 1? Eén van die oplossingen is om in overleg met de product eigenaar een story te definiëren die weliswaar minimale functionaliteit biedt, maar toch toegevoegde waarde voor het project heeft. Zo n story wordt vaak de backbone story genoemd, omdat je daarmee de ruggengraat van je systeem realiseert. Een vaak voorkomend compromis is om de backbone story te gebruiken als proof-of-concept van de gekozen architectuur. Omdat hij daarmee het vertrouwen verkrijgt dat het team in staat is om een dergelijk product te bouwen, zou dat voor de product eigenaar al voldoende toegevoegde waarde kunnen bieden. 4.2 Wanneer is user story succesvol afgerond? Hoe weet je of een user story succesvol is afgerond? Als het goed is conformeren alle stories aan INVEST en zijn ze voorzien van een aantal criteria (de how-to-demo) opgesteld door de product eigenaar. Daarmee is al bepaald of een gerealiseerde story functioneel correct is. Wat dan nog ontbreekt zijn een aantal afspraken zodat alle stakeholders, inclusief de product eigenaar, weten wanneer het team vindt dat de story af is. Wat dat precies inhoudt kan per team wisselen, maar meestal worden meerdere van de onderstaande criteria aangehouden. De code compileert en er zijn geen warnings of errors. De code voldoet aan de coding standards van het project of de organisatie. De code is gereviewed. Alle unit- en integratietesten zijn geslaagd. De Code Analysis van Visual Studio geeft geen waarschuwingen. ReSharper geeft geen meldingen over potentiële fouten (alles is groen ). De dagelijkse integratiebuild heeft succesvol gedraaid. De functionaliteit is getest door een ander lid van het team dan de ontwikkelaar. De oplossing is gecontroleerd aan de hand van een interne checklist. De functionaliteit is getest door een systeemtester. De look-and-feel is gecontroleerd door een medewerker van de afdeling communicatie. Het totaal van die afspraken en de how-to-demo van de story wordt de definition-of-done genoemd. 4.3 User stories en de planning. Stories zijn ook uitstekend geschikt om te gebruiken als eenheid in je planning. In principe hebben Agile projecten geen lange termijn planning en wordt de functionaliteit iteratief gerealiseerd waarbij de prioriteit continu kan worden bijgesteld. Maar in de realiteit, vaak door de omgeving afgedwongen, ontkom je er vaak niet aan om een planning te maken. Hoe los je dat dan op? Vaak worden workshops georganiseerd, waarin met alle stakeholders en met behulp van de use case modellen als context alle stories op papier worden gezet. Daarbij moet je waken dat je niet te veel in de detail treedt. Dat zou alle betrokkenen een vals gevoel van precisie 1 Het artikel Managing the Bootstrap Story van Jennitta Andrea behandelt deze uitdaging in meer detail en biedt een aantal alternatieve oplossingen.

8 Organisatie SYSQA B.V. Pagina 8 van 9 kunnen geven waardoor ze de stories toch als functioneel ontwerp gaan zien. Zijn er brokken functionaliteit waarvan niemand nog precies weet hoe dat zou moeten gaan werken, maak er dan een epic story (user stories, die te groot zijn om in één iteratie te worden geïmplementeerd, en daarom dienen te worden opgesplitst in kleinere user stories die aan de eisen (INVEST) voldoen) van en introduceer een spike (een speciaal type story dat wordt gebruikt om risico s en onzekerheden in een user story of een ander facet van het project weg te werken) om later in het project tijd te reserveren om die epic verder uit te werken. Organiseer daarna een aantal korte meetings met het projectteam, of, als dat er nog niet is, met een aantal ervaren ontwikkelaars. Laat hier alle stories de revue passeren en probeer de omvang te schatten in zogenaamde story points. Sommige mensen uit de Agile community zeggen dat je hier alleen relatief moet schatten. Dus een story die gevoelsmatig twee keer zo veel werk is als een andere story moet ook dubbel zoveel story points krijgen. Een uitgangspunt kan zijn dat elke story point overeenkomt met de ideale dag van een ervaren senior software ontwikkelaar. Met andere woorden, één story point betekent dat een ervaren ontwikkelaar die bekend is met de gekozen architectuur, aanpak en technologie 8 uur lang moet werken, zonder gestoord te worden door telefoon, en andere afleidingen 2. Idealiter is elke story tussen de 1 en 8 story points, maar vooral aan het begin van het project kunnen er nog epics zijn die nog niet op te splitsen zijn. Na die meetings heb je een schatting van de totale omvang van het systeem. Om nu tot een aantal uren te komen moet je een schatting maken van de productiviteit van het verwachte team ten opzichte van die ideale senior ontwikkelaar. Mike Cohn doet dit door een tabel te maken met de verwachte rollen, hun inzet, en hun productiviteit in een percentage af te zetten. Het aantal mandagen kun je bepalen door het aantal story points te delen door de gemiddelde productiviteit. Bijvoorbeeld, een team met een gemiddelde van 75% heeft voor 10 story points 10 / 0,75 = 13,5 mandagen nodig. Het resultaat van dit alles is een planning om een vast aantal story points te realiseren. Natuurlijk is het maar een schatting, want zowel de productiviteit kan tegenvallen als de schatting in story points kunnen afwijken, maar het geeft je wel een initiële schatting die gebruikt kan worden voor een globale planning en budgetbesprekingen. Uiteraard is het van belang om te zorgen dat je de daadwerkelijke productiviteit continu blijft meten. 2 Mike Cohn, schrijver van het boek User Stories Applied, heeft hier een groot aantal hoofdstukken aan gewijd.

9 Organisatie SYSQA B.V. Pagina 9 van 9 5 Referenties 1 Ron Jeffries, Essential XP: Card, Conversation, and Confirmation, XP Magazine, August 30, Ivar Jacobson, Object-Oriented Software Engineering (Addison-Wesley, 1992, ISBN ). 3 Alistair Cockburn, Writing Effective Use Cases (Addison-Wesley, 2000, ISBN ). 4 Larry L. Constantine and Lucy A. D. Lockwood, Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design (Addison-Wesley, 1999, ISBN ). 5 IEEE Computer Society, IEEE Recommended Practice for Software Requirements Specifications, John M. Carroll, Making Use: Scenario-Based Design of Human-Computer Interactions (MIT Press, 2000). 7 Adapted from Alan Cooper s The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How To Restore The Sanity (Sams, 1999, ISBN ). 8 Personal communication, November 7, 2003.