Gebruikersverhaal: verschil tussen versies

Uit Pareltaal
Naar navigatie springen Naar zoeken springen
(→‎‘De Gebruiker’: vertelt de behoefte en/of het doel van een gebruiker in een specifieke rol)
(Bronnen++)
 
Regel 38: Regel 38:
==Bronnen==
==Bronnen==
*[http://www.flexiblesoftwaresolutions.co.uk/content/capturing-software-requirements-user-stories-user-interface-and-entities-agile-approach Capturing Software Requirements, User Stories, User Interface and Entities - An Agile Approach]
*[http://www.flexiblesoftwaresolutions.co.uk/content/capturing-software-requirements-user-stories-user-interface-and-entities-agile-approach Capturing Software Requirements, User Stories, User Interface and Entities - An Agile Approach]
*http://shop.oreilly.com/product/0636920019879.do
*http://www.amazon.com/User-Stories-Applied-Development-ebook/dp/B0054KOL74/
*http://www.agileproductdesign.com/blog/the_new_backlog.html
*Jeff Patton
*Jeff Patton
*Mike Cohn
*Mike Cohn

Huidige versie van 26 apr 2012 om 11:24


…onvrede met de huidige situatie, en aan het begin van het in kaart brengen van de gewenste veranderingen.

✣  ✣  ✣

Je wilt helder en duidelijk communiceren wat je wensen zijn zodat ze door experts zodanig kunnen worden opgepakt en gerealiseerd dat beide partijen bij oplevering zonder twijfel weten dat ze voldoen aan de wensen en eisen.

Keer problemen altijd om naar wensen. Zeg bijvoorbeeld liever “Als webredacteur wil ik dat mensen kopij zoveel mogelijk klantklaar aanleveren zodat ik minder tijd kwijt ben met redigeren.” dan “Als webredeacteur wil ik niet dat mensen kopij in ruwe vorm en vol met fouten aanleveren omdat me dat veel te veel tijd kost.”

Daarom:

Schrijf elke wens op in de vorm “Als rol wil ik verhaal zodat voordeel. Voeg er glasheldere acceptatiecriteria aan toe zodat de oplevering en eventuele facturering soepel kan verlopen.

✣  ✣  ✣

Gebruik de verhalenhakker om verhalen van vergelijkbare grootte te krijgen voor maximale doorstroom en waardecreatie, helemaal als je personateams gebruikt.


✣  ✣  ✣



gebruikersverhalen:

  • zijn begrijpelijk:
    • ontwikkelaars en klanten begrijpen ze;
    • mensen onthouden gebeurtenissen makkelijker indien ze als verhalen georganiseerd zijn;
  • hebben de juiste grootte voor planning;
  • ondersteunen en moedigen iteratieve ontwikkeling aan:
    • je kunt makkelijk met een rivierverhaal of een epos starten en die verfijnen zodra je dichter bij de ontwikkeling en implementatie komt;
  • ondersteunen opportunistische ontwikkeling:
    • je ontwikkelt oplossingen door flexibel tussen benaderingen van bovenaf of onderop te bewegen;
  • ondersteunen deelnemend ontwerp:
    • de gebruikers van het systeem maken deel uit van het team dat het systeem ontwerpt—co-creatie;
    • ontwerpers van het systeem maken keuzes door gebruik van het systeem te bestuderen;

‘De Gebruiker’

Veel projecten gaan ten onrechte uit van het bestaan van slechts één gebruiker—‘de gebruiker’. Alle gebruikersverhalen worden dan vanuit het perspectief van die ene gebruiker geschreven.

Veel effectiever is het om een beperkt aantal levendige persona's te gebruiken als richtinggever en keuzehulp.

Een gebruikersverhaal:

  • vertelt de behoefte en/of het doel van een gebruiker in een specifieke rol;
  • is een item voor planning;
  • dient als geheugensteun voor een gesprek; en
  • is een mechanisme om een gesprek op te schorten.

Kent Beck bedacht de term user stories in Extreme Programming Explained

Bronnen