Lidé se často ptají na otázku, zda by měl agilní tým používat případy užití (Use Case) nebo uživatelské příběhy (User Story). Jsou to záměnné techniky? Jsou stejné? Pokud ne, která je lepší? Kterou má tým použít? Nebo může použít obě?
Ačkoli existují určité podobnosti mezi případy užití a uživatelskými příběhy, nejsou to rovnocenné techniky, obě identifikují uživatele a popisují jeho cíl, ale slouží různým účelům. Uživatelské příběhy jsou zaměřeny na výsledek a hodnotu popisované věci. Zatímco případy užití bývají podrobnější a popisují, jak bude systém fungovat.
Tento článek se věnuje rozdílům mezi případy užití a uživatelskými příběhy.
Co jsou případy užití?
Případy užití, které představil Ivar Jacobson před více než 20 lety, se používají k zachycení uživatelského pohledu na komunikaci se systémem při popisu funkčních požadavků. Popisují kroky scénáře, kterým uživatel prochází za účelem dosažení jednoho uživatelského cíle pomocí softwarového systému.
Kompletní katalog případů užití reprezentuje popis všech způsobů, jakými chce koncový uživatel systém „používat“. Případy užití zachycují všechny možné způsoby interakce uživatele a systému, které vedou k dosažení uživatelských cílů. Zachycují také všechny situace, kdy se během cesty něco pokazí.
Model případů užití se skládá z několika prvků, mezi ně patří
- katalog aktérů
- diagramy případů užití, které zřetelně vizualizují aktéry, případy užití a vztahy mezi nimi
- podrobné specifikace případů užití ve formě zápisu scénářů strukturovaným textem, které zachycují interakci aktéra se systémem (akce uživatele a reakce systému) a mohou zahrnovat
- záměr případů užití
- spouštěč
- vstupní podmínky
- hlavní aktér
- další účastníci
- hlavní úspěšný scénář
- 0+ alternativních úspěšných scénářů
- 0+ výjimečných scénářů
- body rozšíření scénářů
- výstupní podmínky
Případy užití jsou svou povahou velmi podrobné, chcete-li vytvořit užitečnou funkci (= zadat ji někomu, kdo ji vyvine), musíte detailně definovat sadu interakcí, pochopit související business pravidla, alternativy, které bude aktér mít při provádění činnosti a také způsoby, jak by se věci mohly pokazit. To vše bude vyžadovat nějaký čas a úsilí typu BDUF – Big Design Up Front, což je přesný opak agility.
Co je uživatelský příběh?
Uživatelské příběhy byly původně reakcí na toto velké úsilí BDUF. Když Kent Beck definoval eXtreme Programming (XP), přišel s konceptem uživatelských příběhů jako nástroje na podporu iterativního a inkrementálního přístupu, který je vlastní všem agilním metodám.
Uživatelský příběh je poznámka, která zachycuje, co uživatel dělá nebo musí udělat v rámci své práce. Každý příběh sestává z krátkého popisu psaného z pohledu uživatele, přirozeným jazykem. Na rozdíl od zachycení tradičních požadavků se příběh zaměřuje na to, co uživatel potřebuje, místo toho, co by měl systém poskytnout. To ponechává prostor pro další diskusi o řešeních a výsledku systému, který se skutečně hodí jako podpora práce uživatelů.
Uživatelské příběhy mají řadu podobností s případy užití, v obou případech je popisován jeden způsob použití systému, popis je soustředěn na dosažení cíle, je psán z pohledu uživatele a používá přirozený jazyk. Ale uživatelské příběhy nevypráví celý příběh, detaily zdaleka nejsou dokumentovány tak precizně, jako v případech užití. Uživatelské příběhy záměrně vynechávají spoustu důležitých podrobností, slouží jako základ pro diskuzi, až na ni přijde čas.
Koncept 3C
Dobré uživatelské příběhy zahrnují tři kritické aspekty
- The Card – standardizovaný formát karty
- karty představují medium příběhů a mají formát As a [role], I want [to do something], so that [benefits]
- The Converstation
- detailní podoba příběhu vzniká kontinuální diskuzí zákazníka a vývojového týmu
- zde se zaznamenávají klíčové detaily z verbální konverzace, navrhuje základ uživatelského rozhraní pomocí techniky wireframes apod.
- The Confirmation
- akceptační kritéria příběhu sloužící pro ověření korektního chování implementovaného příběhu
- pro zápis se často používá formát BDD jazyka Gherkin, založený nad vzorcem Given-When-Then, který následně umožňuje automatizaci testů
Objasnění uživatelských příběhů
Sprint planning meeting
Na tomto setkání vlastník produktu prezentuje příběhy z backlogu s nejvyšší prioritou a tým:
- klade otázky k objasnění příběhu a jeho akceptačních kritérií
- je schopen rychle potvrdit či upravit předpoklady a nejasnosti při
- odhadování příběhu (v případě značných rozdílů v odhadu je třeba další objasnění)
- odvození technických úkolů pro každý příběh
- potvrzuje, zda tyto příběhy bude schopen dodat v následující iteraci
Během sprintu
Tým obvykle používá techniku Stand-Up meetingů a dobrou praxí je, aby se jich účastnil i vlastník produktu, to dává týmu další šanci klást otázky, upozornit vlastníka produktu na restrikce, problémy a příležitosti, které se objeví při rozpracování příběhů.
Wireframing
V rámci diskuzí o příběhu s vlastníkem produktu může vzniknout řada náčrtků a ty je někdy vhodné transformovat na wireframe (prototypy uživatelského rozhraní s nízkou věrností), které akcelerují pochopení příběhu a zároveň slouží jako základ pro diskuzi s designery a vývojáři příběhu, která možná vynese na povrch další otázky.
Návrh a vývoj
- ačkoli většina detailů byla detailně diskutována během wireframingu, v této fázi se může objevit řada dalších otázek na vlastníka produktu, týkajících se přesného chování systému
- párové programování je zde užitečné, protože dva páry očí zaměřené na element funkčnosti znamenají ještě více otázek a objasnění
- žádný příběh není předán k akceptaci, dokud nejsou splněna jeho akceptační kritéria a definice „done“
To vše může vypadat jako poměrně zdlouhavý proces, ve skutečnosti je to přesně to, co dělá Scrum každý den. Spíše než jedna osoba, která pracuje na případech užití, pracuje tým společně a postupně plní všechny požadavky. Vlastník produktu může upřesnit původní akceptační kritéria v reakci na nové informace v průběhu vývoje příběhu.
Co má tedy tým používat? Případy užití nebo uživatelské příběhy? Odpověď se pokusíme dát ve druhém dílu tohoto článku.
