User story, alebo Používateľský príbeh

Čo je Používateľský príbeh v Agile

Používateľský príbeh popisuje funkcionalitu, ktorá tvorí hodnotu systému pre budúceho používateľa, nákupcu. Príbeh sa skladá z troch aspektov:

• Písomný popis, ktorý sa používa pri plánovaní a zároveň ako pripomienka.
• Rozhovory, ktoré slúžia na spresnenie detailov príbehu.
• Testy, ktoré sprostredkúvajú a dokumentujú podrobnosti, ktoré môžu byť použité na určenie, kedy je príbeh dokončený.

Ron Jeffries pomenoval tieto tri aspekty jednoduchou, zato ale výstižnou aliteráciou 3K – Karta, Konverzácia, Konfirmácia. Karta je najviditeľnejším prejavom používateľského príbehu, ale nie najdôležitejším! Cieľom Karty je reprezentovať požiadavky zákazníkov, nie ich dokumentovať. Kým karta obsahuje text príbehu, podrobnosti sú rozpracované počas Konverzácie a ďalej sa Konfirmujú.

Ako príklad používateľského príbehu pozri nasledovnú Kartu:

„Ako člen skupiny sa môžem prihlásiť k RSS novinkám, takže zostanem dostatočne a ľahko informovaný.“

Pretože používateľský príbeh (ďalej len príbeh) reprezentuje funkcionalitu, ktorá má byť z pohľadu používateľa hodnotná, nasledovné príklady ukazujú nesprávne použitie tohto artefaktu:

• Softvér bude naprogramovaný v Jave.
• Program sa napojí na databázu cez jdbc.

Prvý príklad nie je správny príbeh, pretože používatelia neriešia akým programovacím jazykom je systém tvorený. Ak by to bol ale príbeh týkajúci sa programovania aplikačného rozhrania, potom by mohol používateľ tohto systému, samotný programátor, napísať, že „softvér bude programovaný pomocou C++“.

Druhý príklad v tomto prípade nie je dobrým príbehom, pretože používatelia tohto systému neriešia technické podrobnosti o tom, ako sa aplikácia pripája k databáze.

Možno ste sa práve pozastavili nad tým, že používanie prepojenia systému je v zozname vašich požiadaviek. Kľúčom k úspechu písania správnych príbehov leží v možnosti ich odhadnutia zákazníkom. Existujú spôsoby ako vyjadriť podobné technické príbehy tak, aby ich zákazník mohol naceniť. Pri tvorbe dobrých príbehov sa zameriavame na šesť atribútov:

1. Nezávislý
2. Obchodovateľný
3. Hodnotný
4. Odhadnuteľný
5. Malý
6. Testovateľný

V angličtine sa používa paralela skratky INVEST, ktorá je tvorená začiatočnými písmenami šiestich vyššie spomenutých aspektov.

Kde nájdem detaily?

Jedna vec je napísať „Ako pracovník pobočky chcem spravovať platobné karty klienta, aby ich mohol používať“. Ďalšia vec je, či je možné začať s programovaním a testovaním len takto bez návodu. Kde sa nachádzajú detaily? A kde sú všetky nezodpovedané otázky typu:

• Aké sú vyhľadávacie parametre klienta?
• Aké informácie sa mi zobrazia pri vyhľadaní majiteľa účtu? Je držiteľom karty? Akej karty? Zobrazí sa používateľovi zoznam dostupných kariet?
• Má používateľ možnosť pridať kartu? Odobrať kartu?
• Má používateľ možnosť pridať držiteľa karty? Odstrániť držiteľa karty?

Väčšinu z týchto detailov možno vyjadriť ako ďalšie používateľské príbehy. V skutočnosti je lepšie mať viac malých príbehov ako jeden veľký, vysoko komplexný. Napríklad, predchádzajúce detaily môžu byť zapísané nasledovne:

• Platobné karty (Nastavenia)
• Držiteľ karty

Jednoznačne môžeme povedať, že tieto dva príbehy sú veľmi veľké. Ak sa zaoberáme veľkosťou príbehu, ako východiskový bod je dobré mať príbehy, ktoré sú naprogramovateľné aj s testovaním v rámci poldňa až dvoch týždňov jedným vývojárom alebo skupinou vývojárov. Tieto dva príbehy by pokryli veľkú časť vývoja, takže každá z nich bude pravdepodobne trvať viac ako 2 týždne väčšine vývojárom.

V prípade, že je príbeh príliš veľký a tvorí skôr tému, označujeme ho ako epik, ktorý môže byť rozdelený do dvoch alebo viacerých príbehov menšej veľkosti. Napríklad „Držiteľ karty“ by mohol byť rozdelený do troch príbehov menšej veľkosti:

• Vyhľadanie držiteľa karty
• Pridanie držiteľa karty
• Odstránenie držiteľa karty

Príbehy delíme na menšie dovtedy pokiaľ nepokryjeme poslednú úroveň detailu. Skôr ako začneme ale všetky príbehy zapisovať, je nevyhnutné si uvedomiť, že diskusia medzi vývojovým tímom a zákazníkom je dôležitejšia. V praxi to znamená, že vediete rozhovor o detailoch v okamihu, keď sa detaily stávajú dôležitými. Kľúčová je konverzácia, nie poznámky na Karte príbehu. Príbehy nie sú zmluvnými záväzkami.

Ako vyzerá proces

Projekty, ktoré používajú príbehy, majú iný rytmus ako by sme mohli byť zvyknutí. Použitie vodopádového procesu nás prirodzene navádza k cyklu písania požiadaviek, analýze, návrhu riešenia, programovania a nakoniec testovania. Veľmi často sú pri takomto type procesu zákazníci a používatelia zapájaní na začiatku do písania požiadaviek a na konci do akceptácie, ale zároveň ich zapojenie medzi požiadavkami a prijatím môže úplne vymiznúť.

Prvú vec, ktorú si všimnete na projektoch s príbehmi je to, že zákazníci a používatelia zostávajú zapojení počas celého jeho trvania. Neočakáva sa, že zmiznú v polovici projektu. Zákazník (v zastúpení produktovým vlastníkom) píše príbehy z dvoch primárnych dôvodov. Po prvé, každý príbeh musí byť písaný v obchodnej reči, nie v technickom žargóne. Príbehy sú potom prioritizované a zaradené do iterácií a verzií. Po druhé je zákazník ako vizionár produktu v najlepšej pozícii, aby opísal správanie produktu.

Prvé iniciálne príbehy sa často píšu na workshopoch, ale taktiež môžu byť napísané kedykoľvek počas trvania projektu. Následne vývojári odhadujú ich veľkosť. Tím spoločne so zákazníkom rozhodnú dĺžku iterácie, ktorú použijú pre projekt. Zákazník je počas iterácie intenzívne angažovaný a rozpráva sa s vývojármi o príbehoch, ktoré sa práve vyvíjajú.

Prečo zmena

Prečo písať príbehy a viesť všetky konverzácie? Prečo nepokračovať v písaní dokumentácie s požiadavkami? Používateľské príbehy ponúkajú množstvo výhod oproti alternatívnym prístupom:

• Správnu veľkosť pre plánovanie
• Zrozumiteľné pre zákazníkov aj vývojárov
• Podpora verbálnej komunikácie
• Vhodné pre iteratívny vývoj
• Uplatnenie princípov ALAP pri písaní detailov.

Príbehy nás odrádzajú od predstierania, že všetko vieme vopred. Namiesto toho podporujú proces, pri ktorom je softvér iteratívne vylepšovaný na základe diskusií medzi zákazníkom a tímom.

Kontrolný zoznam

• Rozumiete hneď po prečítaní o čom je používateľský príbeh?
• Pridáva každý prvok používateľského príbehu hodnotu? Nie je duplicitný? Alebo čiastočnou duplicitou iných príbehov?
• Je používateľský príbeh očistený od diktovania spôsobu implementácie?
• Tvorí akceptačné kritéria menej ako šesť otázok?
• Je Rola natoľko špecifická, že každý rozumie, čo je jej úloha?
• Existuje v užívateľskom príbehu priestor pre poznámky?
• Definujú elementy používateľského príbehu jasne Kto, Čo, Prečo?
• Sú všetky akceptačné kritéria napísané bez akejkoľvek formy pseudokódu?
• Dosiahol používateľský príbeh svoj konečný stav Prečo?

Ďalšie tipy pre písanie user stories

Ako na delenie požiadaviek? Časť 1: Podľa krokov procesu

Ako na delenie požiadaviek? Časť 2: Podľa operácií

Ako na delenie požiadaviek, časť 3: Podľa obchodného pravidla

Príklad: Keď produktový vlastník chce záložku. Vyvarujte sa chýb pri písaní user story.

When to accept user story

Epik epicky

Stiahnite si šablóny pre user story

Pripravená požiadavka

Referencie

• Storyteller