een van de grootste uitdagingen in softwareontwikkeling is de bijna onmogelijke taak om duidelijke vereisten te verzamelen en die vereisten vervolgens ongewijzigd te laten tijdens de ontwikkeling van code. In de waterval aanpak van software—ontwikkeling-ondanks inspanningen om te definiëren, documenteren en goedkeuren van elke mogelijke onvoorziene voordat de ontwikkeling begint—het geleverde product is zelden wat de klant wil.
het agile alternatief? Gebruiker verhaal creatie.,
een van de grootste voordelen van het gebruik van een agile benadering van software-ontwikkeling is dat de eisen niet in steen zijn vastgelegd, maar naar verwachting zullen veranderen, met constante feedback van belanghebbenden en het bedrijf. Agile methodologieën zoals Scrum en extreme programming (XP) vervangen traditionele, lange vereisten documenten met een prioriteit product achterstand bestaat uit beknopte gebruikers verhalen, waarvan de details komen dichter bij wanneer het verhaal klaar is om te worden geïmplementeerd.,
hoewel het maken van gebruikersverhalen meer kunst is dan wetenschap, geeft deze handleiding je de informatie, voorbeelden en stappen die je nodig hebt om gebruikersverhalen van hoge kwaliteit te maken.
de geschiedenis van gebruikersverhalen
XP introduceerde voor het eerst het concept van gebruikersverhalen in 1998, waarbij ze werden vergeleken met use cases. In Object-Oriented Software Engineering: A Use Case Driven Approach introduceerde Ivar Jacobson use cases als een manier om vereisten te documenteren door interacties te definiëren tussen een rol (een persoon die het systeem gebruikt) en het systeem zelf om een doel te bereiken met behulp van de Unified Modeling Language (UML).,
deze aanpak was populair in objectgeoriënteerde ontwikkeling en wordt nog steeds gebruikt als een sleutelproces in softwareontwikkelingskaders, zoals het Unified Process (UP), het IBM Rational Unified Process (RUP) en de Oracle Unified Method (OUM). Het gebruik van use cases, in plaats van user stories, staat voor iteratieve en incrementele ontwikkeling toe en wordt beschouwd als een agile benadering van vereisten definitie.,
met de introductie van de veel kortere user stories en de populariteit van XP en Scrum, werd een product achterstand bestaande uit user stories de meer algemeen bekende benadering van agile requirements definitie. Veel beoefenaars denken nog steeds dat gebruikersverhalen de enige aanvaardbare agile aanpak zijn. Alistair Cockburn, een van de Ondertekenaars van het Agile Manifest, geeft echter de voorkeur aan use cases boven user stories.
hoewel er veel sterke meningen zijn over de Betekenis van “agile”, zijn zowel use cases als user stories compatibel met die benadering., Sommigen zeggen dat gebruikersverhalen uiteindelijk vergelijkbaar worden met use cases zodra het team het eens is over de details van de implementatie. In de vroege stadia, de gebruiker verhaal is gewoon een korte zin, maar het is niet compleet totdat de details en acceptatiecriteria zijn gedefinieerd.
Creating user stories
Er zijn verschillende meningen over de definitie van een user story en hoe je er het beste mee om kunt gaan., Enkele richtlijnen voor een goed verhaal zijn de volgende:
- Het moet geschreven worden door iemand die staat voor business gebruikers (meestal de product owner)
- Het moet in eerste instantie zijn korte beschrijvingen van de “wie, wat, en waarom,”maar niet het “hoe”
- Het moet produceren een verticale snee van werkende code
- Het is klein genoeg dat het kan worden gecodeerd en getest in een iteratie (meestal een één-op-vier-weken periode)
Verschillende sjablonen, technieken en acroniemen worden gebruikt om te helpen de product owners schrijven van user stories., Drie van de meest voorkomende technieken zijn de role-feature-reason template, De Drie C ‘ s (kaart, gesprek, bevestiging), en investeren (onafhankelijk, verhandelbaar, waardevol, schatbaar, klein, toetsbaar).
voorbeelden
geven aan dat u een applicatie ontwikkelt waarmee trainers cursusmateriaal kunnen uploaden en leerlingen kunnen aantrekken die geïnteresseerd zijn in het volgen van een les. Hier is hoe je zou toepassen gebruiker verhaal technieken.,
Role-Feature-Reason
zoals Mike Cohn van Mountain Goat Software uitlegt, ziet het Role-feature-reason template, of RGB (role, goal, benefit) er ongeveer zo uit:
“Als Een Ik wil, zodat .”
hoewel er variaties zijn, houdt deze korte zinsstructuur de focus op wie, wat en waarom. Dit voorkomt dat de producteigenaar het ontwikkelingsteam te veel informatie geeft over hoe ze een oplossing moeten implementeren. Door zich te richten op wie, wat en waarom, is het ontwikkelteam in staat om de beste technische oplossing te vinden.,
Voorbeeld 1: Geef een trainer de mogelijkheid om een cursus toe te voegen
als trainer wil ik graag een nieuwe cursus kunnen toevoegen, zodat ik het potentieel heb om nieuwe studenten aan te trekken.
Voorbeeld 2: Geef een student de mogelijkheid om naar een cursus te zoeken
als student wil ik graag in staat zijn om het cursusaanbod te doorzoeken, zodat ik een aanbod kan vinden dat mij het meest interesseert.
de rol (wie)
de rol beschrijft wie baat zal hebben bij deze functie. Merk op dat de rol niet alleen “de gebruiker” is.,”Er zijn verschillende soorten gebruikers, en dus willen we dat de rol specifieker is dan “gebruiker”, maar het type gebruiker beschrijven dat zal profiteren van het verhaal. Producteigenaren zijn vaak belast met het krijgen in de geest van hun gebruikers om te begrijpen wat het meest waardevol voor hen zou zijn.
Voorbeeld 1 rol = trainer
Voorbeeld 2 Rol = student
De functie (wat)
deze stap beschrijft heel kort wat de gebruiker wil. Dit komt het meest overeen met de eis die u beschrijft in de traditionele software-ontwikkeling., Je moet echter oppassen dat je niet te specifiek bent of beschrijft hoe je de code moet schrijven. Dat zal uiteindelijk bepaald worden, maar niet wanneer je voor het eerst het verhaal van de gebruiker maakt. Het verhaal van de gebruiker moet worden geschreven vanuit het perspectief van de gebruiker die zal profiteren van de functie, niet vanuit het perspectief van de ontwikkelaar die het zal coderen.
Voorbeeld 1 Feature = Een nieuwe cursus toevoegen
Voorbeeld 2 Feature = het cursusaanbod doorzoeken
de reden (waarom)
tenslotte willen we aangeven waarom de gebruiker deze functie wil. Welke waarde zal de gebruiker ervan krijgen?, Dit helpt de eigenaar van het product te evalueren hoe de gebruiker story prioriteren op de backlog. Als de waarde of het voordeel niet kan worden gearticuleerd, is het misschien iets dat niet nodig is. Het begrijpen van de waarde helpt het ontwikkelingsteam vaak om innovatieve manieren te vinden om de code te implementeren om het doel op te lossen—manieren die kunnen verschillen van wat de producteigenaar in gedachten heeft.,
Voorbeeld 1 Reden = nieuwe studenten aantrekken
Voorbeeld 2 reden = een aanbod vinden dat mij het meest interesseert
de drie C ‘s: kaart, gesprek, bevestiging
De drie C’ S formule, ontwikkeld door Ron Jeffries, helpt om overeenstemming te bereiken tussen het bedrijf en het technische team over de Betekenis van het gebruikersverhaal. De drie C ‘ s begeleiden hen door de progressieve uitwerking van een verhaal, van een korte verklaring tot een volledig ontwikkeld gebruikersverhaal.,
kaart
het gebruikersverhaal begint doelbewust kort, met een eenvoudig statement dat op een 3×5-indexkaart past, meestal volgens het rol-functie-voordeel-formaat dat ik zojuist heb behandeld. Bijvoorbeeld:
als trainer zou ik graag een nieuwe cursus willen kunnen toevoegen, zodat ik het potentieel heb om nieuwe studenten aan te trekken.
conversatie
hoewel het gebruikersverhaal begint als een eenvoudig statement, moeten details naar voren komen voordat het team aan het verhaal begint te werken., In plaats van te beschrijven wat er nodig is in de documentatie, zal het team omvatten 1) vertegenwoordiging van het bedrijf (meestal de eigenaar van het product), en 2) de ontwikkeling team zelf, met inbegrip van ontwikkelaars, testers, business analisten, of iemand anders in het team.
dit gesprek stelt het ontwikkelteam in staat om vragen te stellen om er zeker van te zijn dat ze een duidelijk begrip hebben van wat er gevraagd wordt en de waarde die gegeven wordt. Bijvoorbeeld:
Ontwikkelaar: moet de trainer de cursusmateriaal uploaden naar een website?,
producteigenaar: Nee, de trainer voegt alleen informatie toe over de cursus die wordt aangeboden, en de functie moet een manier bevatten waarop de student op een interesselijst kan komen. Dit verhaal geeft de trainer de mogelijkheid om een cursus te adverteren.
Ontwikkelaar: welke velden moeten worden opgenomen?
producteigenaar: Cursustitel, samenvatting, data en tijden, locatie.
Ontwikkelaar: zal dit alleen voor reclame face-to-face klassen?
producteigenaar: Ja., We kunnen later een virtuele klasse optie toevoegen, maar dit verhaal zal alleen betrekking hebben op het toevoegen van cursusinformatie voor face-to-face klassenaanbod.
Ontwikkelaar: welke informatie moet worden verzameld wanneer een potentiële student vraagt om op een lijst met interesses te komen?
producteigenaar: naam, telefoonnummer en e-mailadres.
het team zal het gebruikersverhaal bijwerken met de informatie die ze uit het gesprek hebben verzameld, en ze zullen de implementatie bespreken—of het “hoe”—dat vaak specifieke taken creëert die moeten worden gedaan om het verhaal te voltooien., Hoewel het verhaal van de gebruiker is geschreven vanuit het perspectief van de gebruiker, het ontwikkelingsteam schrijft de taken voor de ontwikkelaars en bevat de technische implementatie details.
bevestiging
het ontwikkelteam moet een duidelijk inzicht hebben in hoe de functie zal werken in verschillende situaties, inclusief foutcondities. Zij moeten bevestiging krijgen met betrekking tot de acceptatiecriteria van de producteigenaar. Dit zijn de criteria waaraan moet worden voldaan om het verhaal te worden beschouwd als gedaan en geaccepteerd., Hier is een voorbeeld van acceptatiecriteria:
- een trainer kan een nieuwe cursus toevoegen door cursustitel, samenvatting, datums en tijden en locatie in te voeren aan een formulier en op de knop “cursus toevoegen” te drukken.
- als er velden ontbreken of datums of tijden ongeldig zijn, zullen er foutmeldingen verschijnen.
- zodra de cursus correct is toegevoegd, zal deze openbaar worden weergegeven op de website van de cursus en zal er een knop voor een student om interesse te uiten.,
- met de interest-knop kan een gebruiker naam, e-mailadres en telefoonnummer invoeren, en deze gegevens worden opgeslagen en gekoppeld aan de nieuwe cursus.
INVEST: de attributen van een solid user story
INVEST is een acroniem dat helpt te evalueren of u een gebruikersverhaal van hoge kwaliteit hebt. Hier is hoe de attributen in het acroniem van toepassing zijn op het verhaal waar we aan gewerkt hebben.
i = onafhankelijk-kan dit verhaal worden ingevuld door het team? We willen dat het team in staat is om het hele verhaal te voltooien in plaats van afhankelijk te zijn van een ander team om bijvoorbeeld de GUI te doen.,
N = Negotiable – het verhaal is niet zo gedetailleerd om precies te beschrijven hoe lang de velden moeten zijn of details te geven over datumformaten en dergelijke. Hoogstwaarschijnlijk zullen er gemeenschappelijke routines of bibliotheken zijn die het ontwikkelteam in staat stellen om te implementeren op de manier die het meest zinvol voor hen is.
v = waardevol-de eigenaar van het product beschrijft dat de waarde die wordt gezocht de mogelijkheid is voor de trainer om aankomende lessen te kunnen adverteren. Dit is duidelijk in het” waarom ” van de oorspronkelijke verklaring en opnieuw benadrukt in het gesprek.,
E = Estimable – het team zal genoeg vragen stellen en de details verzamelen om zeker te zijn van hun vermogen om het verhaal te schatten.
S = Small-het team moet er zeker van zijn dat ze het verhaal binnen een sprint kunnen voltooien. Als ze dat niet doen, kunnen ze het verhaal delen. Bijvoorbeeld, in onze steekproef verhaal, ze kunnen besluiten om de mogelijkheid om de student informatie te verzamelen een ander verhaal te maken en gewoon weer te geven informatie over de klas voor dit verhaal.
T = testbaar – met duidelijke acceptatiecriteria kunnen zowel de happy path als de error voorwaarden worden getest.,
uitlijnen naar een visie
Ik heb de basisprincipes van het maken van een gebruikersverhaal behandeld, maar je moet nog steeds het grote plaatje begrijpen voordat je je eigen gebruikersverhalen maakt. Er is veel werk dat je moet doen op voorhand, op een hoger niveau, om te bepalen wat de hoogste waarde functies zijn die moeten worden geleverd aan de klanten. Die worden uiteindelijk ontbonden in gebruikersverhalen.
Het is belangrijk voor het team om eerst de visie op hoog niveau te begrijpen en ervoor te zorgen dat de functies, en uiteindelijk de gebruikersverhalen, aansluiten op die visie op hoog niveau.,
gewoonlijk splitst u het product op in groepen met namen zoals “themes” of “features.”Hoewel de etikettering van deze backlog items kan verschillen, afhankelijk van de agile methode en tools die u gebruikt om ze te beschrijven, het idee is om ervoor te zorgen dat ze op één lijn, zodat het werk kan worden getraceerd tot uw visie, die ervoor zal zorgen dat u voldoet aan de doelstellingen en waarden van het product visie.
opnieuw, start een project niet door gebruikersverhalen aan te maken; begin met het maken van een visie., Voor ons voorbeeld, Ik toon gewoon een sample vision statement, die leidt tot een aantal sample functies, die verder kunnen worden ontbonden in gebruikersverhalen.
Vision
biedt een website van hoge kwaliteit waarmee trainers cursussen kunnen adverteren en studenten die cursussen kunnen volgen.
Features
- bieden een pagina met cursusaanbod waarmee studenten zich kunnen aanmelden voor cursussen.
- Geef een startpagina die gebruikers zal vertellen waar onze site over gaat.
- biedt een registratieproces dat gebruikers in staat stelt om in te loggen, een profiel aan te maken en hun klassen bij te houden.,
- bieden een blog die zal helpen adverteren ons aanbod en krijgen publiciteit voor onze website.
gebruikersverhalen
- bieden trainer de mogelijkheid om een cursus toe te voegen aan de pagina met cursusaanbod.
- studenten de mogelijkheid bieden om naar een cursus te zoeken.
in het voorbeeld hierboven kunt u zien hoe de gebruikersverhalen zijn ontstaan. De verhalen van gebruikers maakten deel uit van een functie om “een pagina met cursusaanbod te bieden” die aansluit bij de visie op hoog niveau.,
Impacttoewijzing
hoewel uitlijnen naar een visie u zal helpen uw initiële achterstand in te vullen, is het niet de enige manier om dit te doen. Er zijn veel tools en technieken die productmanagers kunnen gebruiken om de verhalen te creëren die in een nieuwe achterstand gaan en die aansluiten bij de visie.
een strategische planningstechniek die werd gebruikt om het grote plaatje te begrijpen, impact mapping, werd gepopulariseerd door Gojko Adzic, auteur van vijftig Quick Ideas to Improve Your User Stories and Impact Mapping: Making a big impact with software products and projects., Impact mapping is een mindmap die begint met het doel, dat de kwestie van waarde moet aanpakken en waarom je het product bouwt.
het volgende niveau toont de “acteurs” of mensen die zullen helpen het doel te bereiken. Vervolgens geeft de kaart een overzicht van het gedrag, of “impact”, dat de acteurs zullen uitvoeren om dat doel te bereiken. Het laatste niveau van de kaart toont de “deliverables” die het team kan implementeren. Deze maken het mogelijk en ondersteunen de actoren om de gewenste effecten te creëren. Het is uit deze deliverables dat u de software functies en verhalen af te leiden.,
- doelstelling: op grote schaal beschikbare cursussen aanbieden die studenten zullen willen volgen
- acteurs: Trainers, studenten
- Effecten: Trainers zullen klassen van hoge kwaliteit aanbieden die interessant zijn voor studenten; studenten zullen verwijzingen en aanbevelingen verstrekken
- Deliverables: klassen van hoge kwaliteit die toegankelijk zijn voor studenten
- potentiële verhalen:
- “als trainer wil ik klassen adverteren, zodat ik studenten kan krijgen.
- ” als trainer wil ik feedback krijgen van studenten, zodat ik voortdurend kan verbeteren.,”
- ” als trainer wil ik weten wat studenten willen, zodat ik aan mijn curriculum kan toevoegen.”
- ” als student wil ik klassen vinden die mij het meest interesseren.”
- ” als student wil ik lessen vinden die ik online kan volgen, zodat ik niet hoef te reizen.”
- ” als student wil ik recensies van anderen lezen, zodat ik kan beslissen welke klassen het beste bij mij passen.”
het op deze manier in kaart brengen van gebruikersverhalen maakt traceerbaarheid mogelijk in het denkproces van hoe de verhalen uiteindelijk waarde creëren en hoe je ze gebruikt om het einddoel te bereiken., Het idee is niet om alles te implementeren, maar om de kortste weg door de kaart te vinden om je doel te bereiken.
verhalen splitsen
een van de meest voorkomende problemen die agile teams tegenkomen is wanneer verhalen te groot zijn en niet in een iteratie kunnen worden voltooid. Wanneer het team maakt de taken in verband met het verhaal, ze beseffen dat er te veel onbekenden, of dat de betrokken taken meer tijd in beslag nemen dan het team beschikbaar heeft in een enkele iteratie. Teams pakken dit soms aan door een groter verhaal op te splitsen in kleinere verhalen.,
onthoud echter dat u wilt dat een gebruikersverhaal werkende software levert die waarde toevoegt aan de gebruiker. In plaats van het creëren van een gebruiker verhaal dat slechts gedeeltelijk een functie te voltooien, splitsen verhalen in “verticale slices” die end-to-end functionaliteit zal leveren.
richt u tot de Gemeenschap voor dieper leren
Gedetailleerde oplossingen voor het oplossen van de moeilijkste problemen met betrekking tot vereisten en gebruikersverhalen zijn uniek voor elke situatie. Echter, een gemeenschappelijke eigenschap van succesvolle agile beoefenaars is dat ze staan te popelen om anderen te helpen en te delen wat ze weten.,
Cohn ‘ s userStories website stelt degenen die werken met product backlogs en gebruikersverhalen in staat om producten, bronnen en kennis te delen. De producten pagina bevat een indrukwekkende lijst van tools, veel gratis beschikbaar, met mogelijkheden voor gebruikers reviews en input. Cohn merkt op de site dat hij hoopt om de site uit te breiden, zodat het product achterstanden kunnen worden gedeeld.
er zal nooit een one-size-fits-all antwoord zijn over het schrijven van perfecte gebruikersverhalen., Echter, na verloop van tijd, met een gezonde mix van ervaring, advies van de experts, en experimenteren met voorgestelde tools en technieken, kunt u voortdurend verbeteren.