In deze tutorial leer je over een belangrijk onderdeel van de Agile-aanpak voor softwareontwikkeling: gebruiksverhalen.

Ik neem je mee door wat gebruiksverhalen zijn, veelvoorkomende valkuilen die ik heb gezien bij het creëren van gebruiksverhalen, en de kaders die bestaan om te valideren of jouw gebruiksverhaal “goed” is.

Hier is wat we zullen behandelen:

De Beginjaren van Agile

De kans is groot dat je hebt gehoord van Agile Ontwikkeling en Gebruikersverhalen. Maar als dat niet het geval is, laten we een korte geschiedenisles hebben:

Gebruikersverhalen maken deel uit van een groter concept genaamd Agile methodologieën.

Agile methodologieën bestaan sinds 2001 toen 17 gerespecteerde software-ingenieurs elkaar ontmoetten in een skioord in Utah en het nu beruchte Agile Manifesto creëerden.

Als namen als Robert Martin, Martin Fowler en Kent Beck je niets zeggen, zoek ze dan op nadat je dit artikel hebt gelezen. Ze hebben een schat aan kennis en hebben samen de wereld van software een meer vloeibare manier van projecten opleveren gegeven, genaamd Agile.

Wat is Agile?

Agile is meer een manier van denken dan een voorgeschreven methode. Voorgeschreven methoden bestaan, zoals Scrum en Kanban, maar Agile is een concept.

Agile bevordert samenwerking, snelle feedback en het vaak leveren van waarde aan de gebruiker.

De Agile manier van denken moedigt flexibiliteit aan in projectplanning, wat in schril contrast staat met zijn concurrent op dat moment, de Waterval-projectplanning, die zeer star was met wat er werd geleverd en wanneer.

Agile methodologieën bevorderen het doen van “net genoeg” onderzoek in het begin om het project te starten, en vervolgens leren, itereren en het ontwerp en het eindproduct aanpassen zoals nodig gedurende het project totdat de uiteindelijke code wordt opgeleverd. Deze “veranderen en leren terwijl je bezig bent” benadering wordt “adaptieve planning” genoemd.

Agile bevordert het snel en vaak leveren van iets van waarde, meestal in de vorm van het opleveren van code naar productie aan het einde van elke twee weken durende “sprint”. Dit is opnieuw zeer verschillend van traditionele watervalplanning die vaak maanden ontwikkeling vereist voordat er enige zichtbare verandering voor de gebruiker kan worden geleverd aan productie.

Nog een belangrijk onderdeel van Agile is de focus die het legt op stakeholders die nauw en vaak samenwerken. Product, QA, Engineering en Sales hebben allemaal een grote inbreng en voortdurende feedback op het project gedurende de levenscyclus van het project.

Nu je wat meer weet over hoe Agile werkt, laten we dieper ingaan op hoe we waarde valideren voor de gebruiker.

Enter the User Story.

Wat is een User Story?

Een user story is een manier in eenvoudig Engels om de ingenieur te verbinden met het uiteindelijke doel van de software.

Het is ontworpen zodat een niet-techneut het kan lezen en begrijpen wat er wordt geleverd, en zodat een ingenieur ernaar kan kijken en de waarde kan zien en hoe te valideren dat je die waarde hebt geleverd.

Structuur van een User Story

Als een [type gebruiker], wanneer ik [actie uitvoer], [verwachte uitkomst]

Op zijn meest basale niveau is dat het.

Je legt de nadruk op de eindgebruiker en de “waarde” die je zult leveren.

Laten we de invoer nader bekijken:

  • Type gebruiker: Er is geen “one size fits all” “gebruiker”. Je hebt “beheerder gebruikers”, je hebt “ingelogde gebruikers”, je hebt “gebruikers met toestemming X” of “gebruikers in rol Y”. Dit is specifiek over wie de actie uitvoert.

  • Voer actie uit: Wat doet de gebruiker? Op de knop “inloggen” klikken? Een record verwijderen? Een formulier indienen?

  • Verwachte uitkomst: Zodra je gebruiker de actie heeft uitgevoerd, wat zou er dan moeten gebeuren? Als ze op “inloggen” hebben geklikt met het juiste e-mailadres en wachtwoord, waar zouden ze dan naartoe moeten worden geleid? Als ze op “inloggen” hebben geklikt met een onjuist e-mailadres en wachtwoord, wat zou er dan moeten gebeuren?

Voorbeeld van gebruikersverhalen:

Laten we eens kijken naar voorbeelden van gebruikersverhalen voor een inlogpagina.

Er is niets beter dan voorbeelden.

Laten we de situatie schetsen. Je hebt een inlogpagina met een invoerveld voor een e-mailadres en een invoerveld voor een wachtwoord. Je hebt een verzendknop. Dat is het.

Wat zijn de verschillende combinaties die vanuit het perspectief van de gebruiker op deze pagina kunnen plaatsvinden?

Als ingelogde gebruiker, wanneer de pagina wordt geladen, word ik doorgestuurd naar de ingelogde startpagina

Als ik al ingelogd ben, wil ik niet opnieuw mijn gegevens hoeven in te voeren, stuur me gewoon door naar de ingelogde startpagina.

Als niet-ingelogde gebruiker, wanneer ik het juiste e-mailadres invoer maar het verkeerde wachtwoord en op Inloggen klik, verschijnt er een foutmelding

Ik ben een gebruiker die niet is ingelogd, en ik heb de verkeerde gegevens ingevoerd. Ik zou niet ingelogd moeten zijn.

Als niet-ingelogde gebruiker, wanneer ik een onjuist e-mailadres en wachtwoord invoer en op inloggen klik, verschijnt er een foutmelding.

Nogmaals. Ik ben geen ingelogde gebruiker. Ik heb onjuiste gegevens ingevoerd, ik zou niet ingelogd moeten zijn.

Als niet-ingelogde gebruiker, wanneer ik het juiste e-mailadres en wachtwoord invoer en op inloggen klik, word ik doorgestuurd naar de ingelogde startpagina.

Deze keer ben ik niet al ingelogd, ik voer de juiste gegevens in en klik op inloggen. Ik ben ingelogd in het systeem.

Kun je zien hoe al deze gericht zijn op de gebruiker?

Je zult misschien opmerken dat sommig van het “verwachte gedrag” hierboven niet volledig is gedefinieerd. Dat zullen we later behandelen in de acceptatiecriteria.

Hoe maak je goede User Stories

Er is een goed model genaamd het INVEST-model dat heel eenvoudig laat zien hoe je kunt weten of je user stories goed zijn.

INVEST Model:

  • Independent: Kan afzonderlijk worden ontwikkeld.

  • Negotiable: Open voor discussie en verandering.

  • Valuable: Levert waarde voor de gebruiker.

  • Estimable: Kan worden geschat qua inspanning.

  • Small: Past binnen een sprint.

  • Testable: Heeft duidelijke acceptatiecriteria.

Laten we dit INVEST-model toepassen op een van de voorbeelden van user stories hierboven:

Als een niet-ingelogde gebruiker, wanneer ik het juiste e-mailadres en wachtwoord invoer en op inloggen klik, word ik doorgestuurd naar de ingelogde startpagina.

(Ik ga hier een paar aannames doen, aangezien dit een theoretische codebasis en een theoretisch project is)

Is dit verhaal Onafhankelijk? Ik zou zeggen van wel, ja. Het is een klein verhaal dat slechts een paar componenten bevat die waarschijnlijk al bestaan. Als de database echter nog niet is aangemaakt voor het project, zou dat ons een afhankelijkheid geven. Dit zou niet langer onafhankelijk zijn.

Is het Onderhandelbaar? Nou, nogmaals, ja. Dit verhaal kan gemakkelijk worden aangepast om door te verwijzen naar de profielpagina van de gebruiker in plaats van hun startpagina.

Dit verhaal is zeker waardevol. Zodra het is geïmplementeerd, kan de gebruiker inloggen. Als het verhaal was:

Als een niet-ingelogde gebruiker, wanneer ik het juiste e-mailadres en wachtwoord invoer en op inloggen klik, gebeurt er niets

zou dit niet waardevol zijn. De gebruiker zou hier niets aan hebben.

Is het verhaal schatbaar? Nogmaals, we moeten enkele aannames doen in dit verzonnen scenario, maar ik zou zeker hopen dat dit gemakkelijk te schatten zou zijn. Het is een beknopt verhaal, met weinig componenten, in een domein waar iedereen mee bekend is en heeft duidelijke acceptatiecriteria.

Het verhaal is zeker klein. Er is weinig ambiguïteit over wat er moet gebeuren, er is slechts één gebruikerspad en duidelijke uitkomsten. Laten we eens kijken naar een verhaal dat te groot zou zijn:

Als een niet-ingelogde gebruiker, zou de inlogpagina moeten werken zoals verwacht.

Zoals eerder in dit artikel besproken, zijn er veel manieren waarop de inlogpagina kan en zou moeten werken. “Zou moeten werken zoals verwacht” lijkt al deze permutaties te dekken. Dit zou te groot zijn om effectief te schatten als een verhaal, en waarschijnlijk te groot om in één sprint te worden voltooid.

Het verhaal is zeker Testbaar. Er zijn duidelijke gebruikersacties die moeten worden uitgevoerd met een duidelijke uitkomst. Dit gebruikersverhaal kan worden gedekt door Unit Tests, Integratietests en Handmatige Tests.

Het ziet ernaar uit dat we een goed gebruikersverhaal hebben gemaakt!

Als je de structuur gebruikt die ik hierboven heb gedefinieerd, en het verhaal voldoet aan de criteria van het INVEST-model, is het waarschijnlijk een goed verhaal.

Veelvoorkomende valkuilen bij het maken van gebruikersverhalen

Ik heb in het verleden gezien dat gebruikersverhalen fout gaan wanneer mensen een paar cruciale aspecten van het gebruikersverhaal missen:

Te veel focussen op technische aspecten

Zoals mijn voorbeelden hierboven laten zien, is het gebruikersverhaal niet-technisch.

Er mag geen verwijzing zijn naar een servicenaam, een databasenaam, of validatie gebaseerd op iets dat de gebruiker niet kan zien.

Zodra je verhaal niet langer begrepen kan worden door de eindgebruiker, ben je fout gegaan.

Richt je op wat de gebruiker gaat doen en wat de gebruiker gaat zien.

Laten we eens kijken naar een voorbeeld van een technisch gericht verhaal:

Als een niet ingelogde gebruiker, wanneer ik klik op de link voor het vergeten wachtwoord met een correct e-mailadres, wordt er een record gelogd in een databasetabel waarin staat dat de wachtwoordresetlink is verzonden.

Dit verhaal kan niet worden geverifieerd door een gebruiker en niet-technische gebruikers begrijpen mogelijk niet wat het betekent.

Laten we het repareren:

Als een niet ingelogde gebruiker, wanneer ik klik op de link voor het vergeten wachtwoord met een correct e-mailadres, wordt er een e-mail verzonden naar het opgegeven e-mailadres met een wachtwoordresetlink.

Niet-technische gebruikers kunnen dit begrijpen en het richt zich op de gebruiker, niet op het product.

Stakeholder Samenwerking

Agile is samenwerkend.

Gebruikersverhalen hebben input nodig van Product, BA, QA, Engineers, en het belangrijkste, Gebruikers.

Zo zorg je ervoor dat je levert wat de gebruiker wil. Vele handen maken licht werk.

Als bijvoorbeeld alleen een engineeringteam met gebruikersverhalen zou komen, zouden ze er misschien zo uitzien:

Als ingelogde gebruiker, wanneer de pagina laadt, word ik doorgestuurd naar de homepagina voor ingelogde gebruikers

Als niet-ingelogde gebruiker, wanneer ik het juiste e-mailadres invoer maar het verkeerde wachtwoord en klik op Inloggen, verschijnt er een foutmelding

Als niet-ingelogde gebruiker, wanneer ik een onjuist e-mailadres en wachtwoord invoer en op inloggen klik, verschijnt er een foutmelding.

En dat is goed. Maar laten we nu QA erbij betrekken, die vanuit een ander perspectief komen omdat ze andere ervaringen hebben met software:

Als niet-ingelogde gebruiker, wanneer ik een correct e-mailadres in het Hebreeuws invoer en een correct wachtwoord, word ik doorgestuurd naar de homepagina

Als niet-ingelogde gebruiker, wanneer ik een correct e-mailadres en wachtwoord invoer en herhaaldelijk op inloggen klik, word ik doorgestuurd naar de homepagina

Goed. We krijgen nu een meer afgeronde set gebruikersverhalen die meer situaties bestrijken. Maar wat gebeurt er als we Product erbij betrekken?

Als niet-ingelogde gebruiker, wanneer de pagina laadt, moet mijn wachtwoordbeheerder mijn gebruikersnaam en wachtwoord vooraf laden, wanneer ik op inloggen klik, word ik doorgestuurd naar de homepagina

Het productteam kent de gebruikers. Ze weten dat mensen echt wachtwoordbeheerders gebruiken. We moeten ervoor zorgen dat wanneer de gebruiker eigenlijk niets typt (aangezien de tekst door de wachtwoordbeheerder wordt geladen), de login nog steeds correct werkt.

Vage gebruikersverhalen

Het idee achter een goed gebruikersverhaal is dat iedereen, ongeacht expertise, het kan begrijpen.

Als je een gebruikersverhaal hebt geschreven dat op 10 verschillende manieren kan worden geïnterpreteerd door 10 verschillende mensen, dan ben je een beetje verkeerd gegaan.

Ik heb hierboven vermeld dat ik het zou hebben over acceptatiecriteria, en nu is het tijd om dat te doen.

Laten we het volgende gebruikersverhaal opnieuw bekijken:

Als een niet ingelogde gebruiker, wanneer ik een onjuist e-mailadres en wachtwoord invoer en op inloggen klik, verschijnt er een foutmelding.

Daarin zit vaagheid.

Welke boodschap moet verschijnen? Wanneer de pagina opnieuw laadt na een ongeldige inlogpoging, moet het tekstvak voor de gebruikersnaam dan weer leeg zijn, of vooraf ingevuld met de eerder ingevoerde waarde? Wat betekent “onjuist e-mailadres”? Een e-mailadres dat nog nooit eerder is gezien, of een e-mailadres dat op dat moment niet geldig is (niet betaald voor het abonnement, abonnement geannuleerd, enz.)

Dus zoals je kunt zien, details zijn belangrijk.

Dit gebruikersverhaal is een vrij geforceerd eenvoudig voorbeeld en ik heb veel vragen daarover kunnen vinden.

Laten we het probleem oplossen:

Als een niet ingelogde gebruiker, wanneer ik een e-mailadres invoer dat niet geregistreerd is in het systeem, wanneer ik op inloggen klik, verschijnt er een foutmelding.

Dat heeft de vragen rond de gebruikersactie verwijderd, maar heeft het probleem met het verwachte foutbericht niet opgelost.

Voer de acceptatiecriteria in.

Binnen het gebruikersverhaal moet je een set acceptatiecriteria hebben die definieert of de implementatie van het gebruikersverhaal is zoals verwacht.

Dingen zoals:

  • Foutmelding: “Ongeldig e-mailadres of wachtwoord”

  • E-mailadres en wachtwoord tekstvak worden leeg gereset bij opnieuw laden

  • Gebruiker kan geen toegang krijgen tot pagina’s waar inloggen vereist is

  • Gebruiker krijgt een suggestie voor “wachtwoord vergeten”.

De acceptatiecriteria geven aan wat er van de implementatie wordt verwacht.

Hoe te beginnen met gebruikersverhalen

Begin klein.

Je zult niet perfect zijn in het verfijnen en creëren van gebruikersverhalen in het begin.

Het creëren van gebruikersverhalen is zowel een kunst als een wetenschap. Oefening baart kunst.

Het creëren van gebruikersverhalen moet in groepsverband gebeuren. Vaak gebeurt dit met de “3 Amigo’s” aanpak, waarbij je een engineer, een productpersoon en een QA samen laat zitten om verschillende variaties te brainstormen die je moet ondersteunen.

Nadat je je project hebt opgeleverd, kijk terug. Bekijk wat voor hiaten er zijn in je gebruikersverhalen. Er zullen bugs zijn die de gebruikers vinden, die QA en UAT vinden, en deze worden veroorzaakt door hiaten in je gebruikersverhalen of hiaten in je testen. Hoe dan ook, je zou ervan moeten leren voor de volgende keer.

Conclusie

Agile is samenwerkend. Scrum is samenwerkend. Het maken van gebruikersverhalen is samenwerkend. Onthoud dat.

Hoe meer mensen met verschillende expertisegebieden die betrokken zijn bij het brainstormen van het maken van gebruikersverhalen, hoe waarschijnlijker het is dat je het volledige scala aan werkstromen bestrijkt.

De gebruiker staat centraal. Als je ooit terminologie opneemt die je gebruiker niet begrijpt, heroverweeg dan het gebruikersverhaal.

Je zult hier niet perfect in zijn vanaf het begin, maar naarmate je meer doet, word je sneller en effectiever. Neem het van iemand die dit al meer dan 10 jaar doet. Het verschil in snelheid en kwaliteit van mijn gebruikersverhalencreatie vandaag vs 10 jaar geleden is enorm.

Bekijk mijn blogberichten op mijn website, Just Another Tech Lead, of meld je aan voor mijn wekelijkse e-mailnieuwsbrief hier.