User story neboli Uživatelský příběh

Co je uživatelský příběh v Agile

Uživatelský příběh popisuje funkcionalitu, která tvoří hodnotu systému pro budoucího uživatele nebo kupujícího. Příběh se skládá ze tří aspektů:

• Písemný popis, který se používá při plánování a zároveň jako připomínka.
• Rozhovory, které slouží na zpřesnění detailů příběhu.
• Testy, které zprostředkovávají a dokumentují podrobnosti, které mohou být použité na určení, kdy je příběh dokončený.

Ron Jeffries pojmenoval tyto tři aspekty jednoduchou, zato výstižnou aliterací 3K – Karta, Konverzace, Konfirmace. Karta je nejviditelnějším projevem uživatelského příběhu, ale ne nejdůležitějším. Cílem Karty je reprezentovat požadavky zákazníků, ne je dokumentovat. Zatímco Karta obsahuje text příběhu, podrobnosti jsou rozpracované během Konverzace a dále se Konfirmují.

Jako příklad uživatelského příběhu se podívejte na následující Kartu:

„Jako člen skupiny se můžu přihlásit k RSS novinkám, takže zůstanu dostatečně a lehko informovaný.“

Protožeuživatelský příběh (dále jen příběh) reprezentuje funkcionalitu, která má být z pohledu uživatele hodnotná, následující příklady ukazují nesprávné použití tohoto artefaktu:

• Software bude naprogramovaný v Javě.
• Program se napojí na databázi přes JDBC.

První příklad není správný příběh, protože uživatelé neřeší, jakým programovacím jazykem je systém tvořený. Pokud by to ale byl příběh týkající se programování aplikačního rozhraní, potom by mohl uživatel tohoto systému, samotný programátor, napsat, že „software bude programovaný pomocí C++“.

Druhý příklad v tomto případě není dobrým příběhem, protože uživatelé tohoto systému neřeší technické podrobnosti o tom, jak se aplikace připojuje do databáze.

Možná jste se právě pozastavili nad tím, že používání propojení systému je na seznamu vašich požadavků. Klíčem k úspěchu psaní správných příběhů je v možnosti jejich odhadu zákazníkem. Existují způsoby, jak vyjádřit podobné technické příběhy tak, aby je zákazník mohl nacenit.

Při tvorbě dobrých příběhů se zaměřujeme na šest atributů:

1. Nezávislý
2. Obchodovatelný
3. Hodnotný
4. Odhadnutelný
5. Malý
6. Testovatelný

V angličtině se pro tyto atributy používá zkratka INVEST, která je tvořená počátečními písmeny těchto aspektů.

Kde najdu podrobnosti?

Jednou věcí je napsat„Jako pracovník pobočky chci spravovat platební karty klienta, aby je mohl používat.“ Další věcí je, jestli je možné začít s programováním a testováním jen takto bez návodu. Kde se nacházejí bližší podrobnosti? A kde jsou všechny nezodpovězené otázky typu:

• Jaké jsou vyhledávací parametry klienta?
• Jaké informace se mi zobrazí při vyhledání majitele účtu? Je držitelem karty? Jaké karty? Zobrazí se uživateli seznam dostupných karet?
• Má uživatel možnost přidat kartu? Odebrat kartu?
• Má uživatel možnost přidat držitele karty? Odstranit držitele karty?

Většinu z těchto detailů můžeme vyjádřit jako další uživatelské příběhy. Ve skutečnosti je lepší mít víc malých příběhů než jeden velký a příliš komplexní. Například předcházející detaily mohou být zapsané následovně:

• Platební karty (Nastavení)
• Držitel karty

Jednoznačně můžeme říci, že tyto dva příběhy jsou dost velké. Když řešíme velikost příběhu, jako výchozí bod je dobré mít příběhy, které jsou naprogramovatelné i s testování v rámci půl dne až dvou týdnů jedním vývojářem nebo skupinou vývojářů.

Tyto dva příběhy by pokryly velkou část vývoje, takže každý z nich bude pravděpodobně většině vývojářů trvat déle než dva týdny.

V případě, že je příběh příliš velký a tvoří spíše téma, označujeme ho jako epik, který může být rozdělený do dvou nebo více příběhů menší velikosti. Například„Držitel karty“ by mohl být rozdělený do tří příběhů menší velikosti:

• Vyhledání držitele karty
• Přidání držitele karty
• Odstranění držitele karty

Příběhy dělíme na menší do té doby, dokud nepokryjeme poslední úroveň detailu. Dřív než začneme všechny příběhy zapisovat, je nezbytné si uvědomit, že je důležitější diskuze mezi vývojovým týmem a zákazníkem. V praxi to znamená, že vedete rozhovory o detailech až v okamžiku, kdy se detaily stávají důležitými. Klíčová je konverzace, ne poznámky na Kartě příběhu. Příběhy nejsou smluvními závazky.

Jak vypadá proces

Projekty, které používajú příběhy, mají jiný rytmus, než jsme zvyklí. Použití vodopádového procesu nás přirozeně navádí k cyklu psaní požadavků, analýze, návrhu řešení, programování a nakonec testování. Velmi často jsou při tomto typu procesu na začátku zákazníci a uživatelé zapojeni do psaní požadavků a na konci do akceptace a jejich zapojení může mezi požadavky a přijetím úplně vymizet.

První věcí, které si všimnete na projektech s příběhy, je to, že zákazníci a uživatelé zůstávají zapojeni během celého jeho trvání. Neočekává se, že zmizí v půlce projektu.

Zákazník (zastoupený projektovým vlastníkem) píše příběhy ze dvou primárních důvodů. Za prvé musí být každý příběh psaný v obchodní řeči, ne v technickém žargonu. Příběhy jsou poté prioritizované a zařazené do iterací a verzí. Za druhé je zákazník jako vizionář produktu v nejlepší pozici, aby popsal chování produktu.

První iniciální příběhy se často píší na workshopech, ale také mohou být napsané kdykoliv během trvání projektu. Následně vývojáři odhadují jejich velikost. Tým společně se zákazníkem rozhodne o délce iterace, kterou použije pro projekt. Zákazník je během iterace intenzivně angažovaný a baví se s vývojáři o příbězích, které se právě vyvíjejí.

Proč změna?

Proč psát příběhy a vést všechny konverzace? Proč nepokračovat v psaní dokumentace s požadavky? Uživatelské příběhy nabízejí množství výhod oproti alternativním přístupům:

• Mají správnou velikost pro plánování.
• Jsou srozumitelné pro zákazníky i vývojáře.
• Podporují verbální komunikaci.
• Jsou vhodné pro iterativní vývoj.
• Uplatňují principy ALAP při psaní detailů.

Příběhy nás odrazují od předstírání, že všechno předem víme. Namísto toho podporují proces, při němž je software iterativně vylepšovaný na základě diskuzí mezi zákazníkem a týmem.

Kontrolní seznam

• Rozumíte hned po přečtení, o čem je uživatelský příběh?
• Přidává každý prvek uživatelského příběhu hodnotu? Není duplicitní nebo částečnou duplicitou jiných příběhů?
• Je uživatelský příběh očištěný od diktování způsobu implementace?
• Tvoří akceptační kritéria méně než šest otázek?
• Je Rola natolik specifická, že každý rozumí, co je její úlohou?
• Existuje v uživatelském příběhu prostor pro poznámky?
• Definují elementy uživatelského příběhu jasně KDO, CO, PROČ?
• Jsou všechna akceptační kritéria napsané bez jakékoliv formy pseudokódu?
• Dosáhl uživatelský příběh svůj konečný stav Proč?

Další tipy pro psaní 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

Nový kurz: User Story – tvoríme a píšeme požiadavky agilne

Pripravená požiadavka