Uživatelské příběhy: Porovnání verzí
m |
m |
||
| (Není zobrazena jedna mezilehlá verze od stejného uživatele.) | |||
| Řádek 1: | Řádek 1: | ||
| + | [[Agilní přístup|Část sekce Agilní přístup]] | ||
| + | |||
= Vytváření uživatelských příběhů = | = Vytváření uživatelských příběhů = | ||
| Řádek 82: | Řádek 84: | ||
Příklady: | Příklady: | ||
| − | * | + | * 'Je to hotovo, když uživatel ví, jak se registrovat online' |
| − | * | + | * 'Je to hotovo, když uživatel ví, kam poslat vyplněný formulář' |
| − | * | + | * 'Je to hotovo, když uživatel ví, když uživatel zná výsledek žádosti' |
====Rozsáhlé uživatelské příběhy ==== | ====Rozsáhlé uživatelské příběhy ==== | ||
Aktuální verze z 16. 7. 2018, 14:37
Obsah
Vytváření uživatelských příběhů
Proč v agilních a Scrum týmech píšeme uživatelské příběhy (User Story) a proč nestačí jen tasky s popisem co se má udělat? K čemu je, že se držíme formátu Jako Uživatel, chci Funkcionalitu abych dostal Business Value? Není to zbytečné pořád dokola opakovat slovíčka ‘Jako’, ‘chci’ a ‘abych’? Může se to tak zdát. Pojďme se na to ale podívat od začátku.
Uživatelský příběh vám říká nejen, co chcete dělat, ale i pro koho a hlavně proč. Uživatelský příběh má vytvářet obrázek, popisuje příběh. Lidský mozek vnímá obrázky a příběhy daleko snadněji než technický popis v bodech.
Zkuste si teď porovnat jeden příklad z praxe:
1. UP: „Kontaktní formulář“ (jaký jste si představili?) 2. UP: „Jako administrátor chci kontaktní formulář, abych se včas dozvěděl o chybách systému“.
Jsem si téměř jistá, že když jste to četli, šlo o dvě různé věci. Myslíte si, že je to z kontextu firmy a produktu jasné? Ne vždy. Většinou je to jasné pouze Product Ownerům, ti mají v hlavách obrázky, jak přesně se má systém chovat a jak má vypadat. Ti jsou součástí příběhu zákazníka, ale v uživatelských příbězích jde o to, aby ten obrázek, co mají v hlavě, sdělili ostatním tak, aby ho ani oni nikdy nezapomněli. A aby se i oni stali jeho součástí.
User Story by měla být
- jednoznačně popsatelná,
- vytvářet obrázek,
- nezávislá,
- přinášet hodnotu,
- malá,
- testovatelná.
Je-li uživatelský příběh příliš velký, je většinou těžké říct co je jejím obsahem a co už ne, a je tak pro tým neuchopitelná. A jak se pozná, že je User Story hotová? Od toho jsou tu akceptační kritéria. [1]
Při vytváření a modifikaci služby musíte uživatelské příběhy. Jsou nutným základem pro budování a provozování služeb, které pokrývají potřeby uživatelů.
Ubezpečte se, že každý člen vašeho teamu píše uživatelské příběhy a používá je:
- k popsání všeho, co je potřeba ve službě dělat
- přemýšlet nad svojí práci z perspektivy uživatele
- diskutovat o své práci s kolegy a odbornou veřejností
- lépe stanovit své priority
- naplnit Digitální standardy služeb a splnit potřeby bodu 1 Pochopte potřeby občanů
Pro splnění potřeb bodu 4 Použijte agilní metody musíte ukázat, jak jste adoptovali agilní metody a nástroje, včetně použití uživatelských příběhů.
Pro splnění bodu 5 Rozvíjejte a vylepšujte službu průběžně musíte ukázat, jak jednotlivé uživatelské příběhy prioritizujete a jak je rychle a agilně přenášíte z etapy uživatelského průzkumu do produkce.
Jak psát uživatelské příběhy
Uživatelský příběh je takový způsob zadávání práce, kdy na konci vždy zůstane něco, co je pro někoho užitečné. Když budete psát uživatelské příběhy, čeká vás následující:[2]
- Práci může (a měl by) schvalovat produkt manager.
- Práce se dá nasadit do produkce (jde o konkretní věc).
- K práci se nebudete muset vracet, takže vám zpětně nezasahuje do plánování.
- Vše, co se dělá, vede k něčemu užitečnému
- Proces prioritizace se točí kolem přinesené hodnoty uživateli
- Vede k průběžnému refaktoringu
Co mají UP obsahovat
Každý uživatelských příběh by měl obsahovat dostatek informací pro produkt managera pro rozhodnutí, jak důležitý příběh je. Měl by vždy obsahovat:
- osobu, která služby používá (účastník)
- jaké jsou uživatelské potřeby od služby (příběh)
- proč, k čemu je potřeba (cíl)
Obvyklý formát UP
Uživatelské příběhy jsou obvykle psány ve formátu:
Jako (kdo je uživatel?)...
Potřebuji/chci/očekávám (co chce uživatel dělat)...
Aby dosáhl (proč to chce uživatel udělat)
Příklad: (TBD)
- Uživatelský příběh pro služby "registrace pro volby v zahraničí"
- Jako český občan jsem v době prezidenských voleb v zahraničí, proto se chci snadno zaregistrovat, abych mohl volit
Soustředte se na cíl
Nejdůležitější částí UP je cíl. Proto
- se ujistěte, že řešíto skutečný problém uživatele
- rozhodněte, kdy je příběh hotový a řeší uživatelskou potřebu
Pokud se vám nedaří UP napsat, zvažte, zda vůbec takovou funkcionalitu potřebujete.
Akceptační kritéria
Je vhodné, aby každý uživatelský příběh obsahoval i akceptanční kritéria. Akceptační kritéria tvoří seznam výsledků, který potvrzuje, že vaše služba vykonala svou práci a uspokojuje potřeby uživatele.
Často je psát formou "Je to hotovo, když ..."
Příklady:
- 'Je to hotovo, když uživatel ví, jak se registrovat online'
- 'Je to hotovo, když uživatel ví, kam poslat vyplněný formulář'
- 'Je to hotovo, když uživatel ví, když uživatel zná výsledek žádosti'
Rozsáhlé uživatelské příběhy
Je-li uživatelský příběh příliš velký, je většinou těžké říct co je jejím obsahem a co už ne, a je tak pro tým neuchopitelná. Také se to pozná tak, že jeho vytvoření a otestování trvá několik týdnů. Pokud je to možné (a to skoro vždy je), rozdělte ho na menší části.
Kam uživatelské příběhy psát
Pište uživatelské příběhy na karty, a každou kartu vhodně pojmenujte. Karta může být např. :
- skutečná karta nalepená na teamové zdi
- digitální, uložená ve sdíleném Google Spreadsheet či agilním SW (Trello apod).
- kombinace obou, dle priorit
Plánování
Když máte hodně uživatelských příběhů, můžete je evidovat v digitální formě, a překlápět je na fyzické karty podle priorit.
Pokud v rámci přípravy práce na uživatelkém příběhu probíhá hlubší diskuze mezi členy teamu, je dobré diskutované detaily uvést i v uživatelském příběhu.
Related guides You may also find these guides useful:
