Zákopová metóda - ako písať user story

Zákopová metóda - ako písať user story

Článok z blogchainu: zákopová metóda.

V ideálnom svete ako podklad na vytvorenie user stories disponujem customer jobmi (dopyt, prieskum problémov/príležitostí) vo forme job stories. User stories sú to be definiciou riešenie (ponuka).

When _ [role context]__ , I want to ____ [because] ____ , so I can _____ .

Adresovať biznisové požiadavky vo forme user story je mäso zákopovej metódy. Naučiť sa písať user stories dobre, trocha bolí, ale stojí to za to, a moja snaha je, aby evidencia v tejto forme nebolo limitované na nejakého špeciálneho pracovníka (biznis analytik, alebo product owner), ale aby to bol nástroj, ktorý môžu mať v ruke všetci (stakeholderi, používatelia, vývojári).

Ako písať kvalitné user story

User story

Hlavným cieľom user story zápisu je odpovedať na otázky:
1) koho sa potreba týka
2) čo konkrétne potrebuje
3) prečo to potrebuje

As a [role], I want [some action], so that [outcome]

Tento jednoduchý zápis je efektívnym spôsobom, ako odovzdať informáciu o tom, aké sú očakávania (čo by mal softvér dokázať).

Identifikácia rolí a ich vzťahov pri zrode projektu, pomáha tomu, aby som vedel písať plnohodnotné user stories, je to základny kameň okolo ktorého sa user story vyskladáva. Bližšie som sa roliam venoval v samostatnom článku.

As storeman see all orders for stockout (actual warehouse state) be able do stockout

Jednou z mnemotechnických pomôcok, ktoré pomáhajú s praktickým zápisom kvalitnej user story, je akronym INVEST, ktorý reprezentuje súhrn prívlastkov:

  • I - independent
  • N - negotiable
  • V - valuable
  • E - estimable
  • S - small
  • T - testable

User story je konštrukt, o ktorého splnení je možne sa (po)baviť (N), pri jeho doručovaní sa snažím minimalizovať ostatné závislosti (I), prináša biznis hodnotu zákaznikovi (V), je preferované, aby predmetná funkcionalita bola, čo najmenšia (S), aby ju bolo možné, čo najpresnejšie odhadnúť (E), a bolo ju možné otestovať (T).

Nad týmto akronymom by sme asi mohli viesť plodné, menej plodné, ale za to horúce diskusie. Každopádne je to dobrá pomôcka, ktorú je si dobré pripomínať. Zvyčajne to funguje tak, že najprv vznikne nejaká hrubá verzia user story a tá sa podrobí kontrole voči INVEST.

Akceptačné kritéria

Akceptačné kritéria detailizujú špecifikáciu a odstraňujú nejednoznačnosť, ktorá môže z jednoduchosti zápisu user story prameniť. Akceptačné kritéria slúžia ako šikovný zoznam ku kontrole toho, či je očakávanie požiadavky naplnené.

acceptance criteria:
1) default ordering for list of orders is based on latest stockout date DESC (e.g. orders that should leave are first in list)
2) list of orders will have these attributes: order date, order nr, sender name, sender address, recipient name, recipient address, order intake date
3) latest stockout date is calculated based on order arrival date plus 7 working days (take holidays and opening hours in consideration)
4) orders after latest stockout date will be visually marked (colour, sign)
5) able to search free text in attributes order number, consignee/consignor name/address

Ak akceptačné kritérium smrdí prílišnou komplikovanosťou treba zvážiť, či ním doručovanú hodnotu, nie je možné vytiahnuť do samostatnej user story (splitting, aplikácia I, V a S z akronymu INVEST).

Akceptačné kritéria bližšie špecifikujú, čo má byť podmienkou user story. Nič však nebráni aj tomu, aby v akceptačných kritériach bolo aj to, čo nemá user story robiť (to môže veľa krát usmerniť ambície programátora zavrtať sa do rabbit hole).


O INVESTe, základnej štruktúre user story, roliach (persónach), alebo akceptačných kritériach je na internetoch kopec teórie. Ja by som pridal zopár svojich odporúčaní overených v praxi, ktoré zvyknem k user story pridávať. 🙂

Status quo

Popis aktualnej situácie, problému, výzvy. Vyzdielanie kontextu, tak dobre, ako sa len dá. Popis aktuálneho riešenia tejto potreby, ak nejaké riešenie existuje (zvyčajne áno). Celá táto omáčka dáva riešiteľovi kontext, akému problému čelí. Keďže si pri riešení špecializujeme, tak programátor, aby od zeleného stola, čo najlepšie aproximoval očakávania zákazníka, ktoré sa takto aj sformalizujú (zapíšu).

Už tu mlátim slamu, ale keď chcem zákazníkovi pomôcť s transformáciou (je niekde, a chce byť niekde inde, na lepšom mieste, ako je teraz), tak potrebujem vedieť odkiaľ ide.

Apetít/timebox

Môj apetít na riešenie tejto požiadavky, alebo timebox, pomáha indikovať ako veľmi ochotný som akceptovať workaroundy (t.z. že aktuálne netúžim po dokonalom riešení, že sa jedná o dočasné riešenie).

Referenčné materiály

Zapísať  nejaký divoký špecifický vzorec, podľa ktorého očakávam, že aplikácia vyhodnotí biznis pravidlo (e.g. výpočet počtu dní skladovania, alebo očakávana výška odpisov do konca kalendárneho obdobia), je efektívnejšie ilustrovať  na pomocnom exceli, ako sa snažiť krvopotne opísať slovom (dostať to do akceptačných kritérii).

Otvorené otázky

V čase keď sa dokumentácia budúceho riešenia rodí, často vzniknú nezodpovedané otázky, ktoré je vhodné prekonzultovať s doménovými špecialistami, alebo vlastníkmi procesov, ktoré sa chystáme automatizovať. Keď už nám nejaké nejasnosti prebleskli hlavou, nie je naškodu si ich pozapisovať, a nájsť priestor na ich zodpovedanie. Rovnako po zodpovedaní týchto otázok, je dobré ich aj s odpoveďami ponechať pre referenciu (opäť pomáhajú zasadiť user story do širšieho kontextu).

Dáta

Ak viem  zákazníkové hypotézy, dohady a praxou overené zaručené čísla podrobiť kontrole, a mám na to možnosť (historické údaje), je dobrý nápad to urobiť. To môže pomôcť odhaliť závažnosť (bolesti), ktoré zákazník indikuje. Niekedy sa vážnosť problému nepotvrdí, alebo dáta vhodnejšie nasmerujú spôsob riešenia.

Wireframe

Jeden obrázok lepší ako tisíc slov. Odporúčanie je, aby wireframe len rámcoval, čo mám na mysli. Treba vedome minimaližovať snahu o detail. Detail riešenia mám nechať na dizajnéra/UX človeka (ak takých mám formálne, či neformálne).


User story je efektívny spôsob ako dokumentovať požiadavky biznisu. Zoznam user stories (user story index) dokáže efektívne odpovedať na otázky aj po tom, čo už softvér slúži svojím používateľom - stáva sa šikovnou dokumentáciou.

Show Comments