Wat is een gebruikersverhaal?
gebruikersverhalen zijn korte, eenvoudige beschrijvingen van een functie die verteld wordt vanuit het perspectief van de persoon die de nieuwe mogelijkheid wenst, meestal een gebruiker of klant van het systeem. Ze volgen meestal een eenvoudige sjabloon:
als a , dat wil ik .
gebruikersverhalen worden vaak geschreven op indexkaarten of sticky notes, opgeslagen in een schoenendoos en gerangschikt op muren of tafels om planning en discussie te vergemakkelijken., Als zodanig, ze sterk verschuiven de focus van het schrijven over functies te bespreken. In feite zijn deze discussies belangrijker dan welke tekst er ook wordt geschreven.
kunt u enkele voorbeelden van gebruikersverhaal tonen?
een van de voordelen van agile gebruikersverhalen is dat ze op verschillende detailniveaus kunnen worden geschreven. We kunnen een gebruikersverhaal schrijven om grote hoeveelheden functionaliteit te dekken. Deze grote gebruikersverhalen zijn over het algemeen bekend als epics. Hier is een epic agile user story voorbeeld van een desktop backup product:
- als gebruiker kan ik mijn hele harde schijf back-uppen.,
omdat een epic over het algemeen te groot is voor een agile team om in één iteratie te voltooien, wordt het opgesplitst in meerdere kleinere gebruikersverhalen voordat er aan wordt gewerkt. Het epic hierboven kan worden opgesplitst in tientallen (of mogelijk honderden), waaronder deze twee:
- Als power user Kan Ik bestanden of mappen opgeven om een back-up te maken op basis van Bestandsgrootte, Datum gemaakt en datum gewijzigd.
- als gebruiker kan ik aangeven dat mappen niet moeten worden geback-upt, zodat mijn back-upstation niet gevuld is met dingen die ik niet moet opslaan.
Hoe wordt detail toegevoegd aan gebruikersverhalen?,
Detail kan op twee manieren aan gebruikersverhalen worden toegevoegd:
- door een gebruikersverhaal op te splitsen in meerdere, kleinere gebruikersverhalen.
- door toevoeging van ” voorwaarden waaraan moet worden voldaan.”
wanneer een relatief groot verhaal wordt opgesplitst in meerdere, kleinere agile user stories, is het natuurlijk om aan te nemen dat detail is toegevoegd. Er is immers meer geschreven.
the conditions of satisfaction is simply a high-level acceptance test that will true after the agile user story is complete., Beschouw het volgende als een ander voorbeeld van een agile gebruikersverhaal:
als vice president of marketing wil ik een vakantieseizoen selecteren dat gebruikt moet worden bij het bekijken van de prestaties van eerdere reclamecampagnes, zodat ik winstgevende campagnes kan identificeren.
Detail kan worden toegevoegd aan dat gebruikersverhaal Voorbeeld door de volgende voorwaarden van tevredenheid toe te voegen:
- zorg ervoor dat het werkt met grote retailvakanties: Kerstmis, Pasen, Presidentsdag, Moederdag, Vaderdag, dag van de Arbeid, Nieuwjaarsdag.
- ondersteunt vakanties die twee kalenderjaren bestrijken (geen vakanties die drie jaar beslaan).,
- feestdagen kunnen worden ingesteld van de ene vakantie naar de volgende (zoals Thanksgiving naar Kerstmis).
- feestdagen kunnen worden ingesteld op een aantal dagen voorafgaand aan de vakantie.
Wie schrijft gebruikersverhalen?
iedereen kan gebruikersverhalen schrijven. Het is de verantwoordelijkheid van de producteigenaar om ervoor te zorgen dat een product achterstand van agile gebruiker verhalen bestaat, maar dat betekent niet dat de producteigenaar is degene die ze schrijft. In de loop van een goed agile project, moet je verwachten dat de gebruiker verhaal voorbeelden geschreven door elk teamlid.,
merk ook op dat wie een gebruikersverhaal schrijft veel minder belangrijk is dan wie er bij de discussies betrokken is.
Wanneer worden gebruikersverhalen geschreven?
gebruikersverhalen worden door het hele agile-project geschreven. Meestal wordt een verhaal-schrijven workshop gehouden in de buurt van de start van het agile project. Iedereen in het team neemt deel met het doel van het creëren van een product achterstand die volledig beschrijft de functionaliteit die moet worden toegevoegd in de loop van het project of een drie – tot zes maanden release cyclus erin.
sommige van deze agile gebruikersverhalen zullen ongetwijfeld epics zijn., Epics zal later worden ontbonden in kleinere verhalen die beter passen in een enkele iteratie. Daarnaast kunnen nieuwe verhalen worden geschreven en toegevoegd aan het product achterstand op elk gewenst moment en door iedereen.
vervangen gebruikersverhalen een document met vereisten?
Agile projecten, vooral Scrum projecten, maken gebruik van een product backlog, wat een geprioriteerde lijst is van de functionaliteit die ontwikkeld moet worden in een product of dienst. Hoewel product achterstand items kan worden wat het team wenst, gebruiker verhalen zijn naar voren gekomen als de beste en meest populaire vorm van product achterstand items.,
hoewel een product achterstand kan worden gezien als een vervanging voor het vereisten document van een traditioneel project, is het belangrijk om te onthouden dat het geschreven deel van een agile user story (“As a user, I want …”) onvolledig is totdat de discussies over dat verhaal plaatsvinden.
Het is vaak het beste om het geschreven deel te zien als een verwijzing naar de echte eis. Gebruikersverhalen kunnen wijzen op een diagram met een workflow, een spreadsheet die laat zien hoe u een berekening uitvoert, of een ander artefact dat de producteigenaar of het team wenst.,
aanbevolen bronnen gerelateerd aan gebruikersverhalen
- voordelen van het “As a user, I want” gebruikersverhaal sjabloon.,
- A Sample Format for a Spreadsheet-Based Product Backlog
- voordelen van gebruikersverhalen voor vereisten
- niet-functionele vereisten als gebruikersverhalen
- Inleiding tot gebruikersverhalen
Leave a Reply