V první části článku jsme stručně zrekapitulovali techniky případů užití a uživatelských příběhů, aby byly patrné jejich odlišnosti. Nyní se pokusíme zamyslet nad jejich praktickým použitím v rámci agilních týmů.
Uživatelské příběhy, případy užití nebo oboje?
Zda váš projekt vyžaduje případy užití, uživatelské příběhy nebo obojí, to záleží na podmínkách projektu, dostupné spolupráci, úrovni formality a požadovaném prvotním výzkumu.
Tendenci používat případy užití je možné pozorovat převážně u vládních projektů, které mají přísnější požadavky na dokumentaci, nebo u projektů, které probíhají v organizacích s významnou regulací. U menších projektů s krátkou dobou trvání se týmy naopak častěji přiklání k uživatelským příběhům. Mnohaletá debata neukazuje, že by jedna z metod byla lepší, než druhá, ale že obě jsou použitelné v různé míře na základě podmínek projektu.
Načasování dělá rozdíl
Klíčem je načasování – uživatelské příběhy jsou záměrně abstraktní brzy na začátku projektu a teprve během času se vyvíjí na základě principů just-in-time a just-enough. Důvodem je to, že agilní projekty očekávají a předvídají změnu a reagují na tuto změnu tím, že přizpůsobí produkt vyvíjejícím se potřebám. Bude přidáno více uživatelských příběhů, některé budou vynechány a chápání mnoha příběhů se bude s postupem času měnit. Realita dnešního světa je taková, že změna je nevyhnutelná, takže pokus o definování detailů všech aspektů předem povede k plýtvání zbytečným úsilím a časem.
Jedním z mylných a nebezpečných mýtů o Agile je to, že „agilní projekty nemají žádnou dokumentaci“ – realitou je, že agilní projekty mají dokumentaci potřebnou k zajištění dodání hodnoty, nic víc. Filozofií je odložit práci až do okamžiku, kdy je potřeba výstup této práce (koncept vlastní Lean myšlení), a vykonávat pouze práci, která je nezbytná k dosažení požadovaného výsledku (zabránění plýtvání zbytečným úsilím a přepracování).
To je v ostrém kontrastu k myšlence případů užití, kde cílem je definovat v různých proudech případu užití všechny podrobnosti předem. Tento přístup nevyhnutelně vede ke zbytečnému úsilí, protože případy užití budou muset být udržovány a aktualizovány, jakmile se objeví měnící se potřeby. V agilním případě chceme vyvíjet řešení iterativně a postupně, protože se učíme na základě zpětné vazby od skutečných zákazníků/uživatelů, nikoli na základě přepracování dokumentace a požadavků.
Případy užití versus uživatelské příběhy – myšlení versus komunikace
Když používáte případy užití, přemýšlíte o tom, jak uživatel a systém vzájemně spolupracují. Zároveň přemýšlíte přesně o tom, kde se mohou vyskytnout variace, výjimky, co musí platit, než uživatel může začít případ užití a co musí platit po jeho skončení. Během tohoto procesu často objevujete otázky, na které byste nepomysleli při psaní dlouhého seznamu požadavků.
Je to proces myšlení, který je kritický, zejména pro začínající business analytiky. Mimo jiné, v tom spočívá hodnota případů užití, a proto je důležité, aby tuto dovednost business analytici měli, i když se později přesunou do agilnějšího prostředí.
Je to zajímavá věc … Jako zkušený business analytik jste pravděpodobně napsali stovky případů užití, udělali jste to tolikrát, že to máte zažité hluboko v podvědomí. Když píšete uživatelské příběhy, přemýšlíte podvědomě o případech užití a máte to vše v hlavě. Funguje to, jakmile to budete nějakou dobu dělat.
Pro začínající business analytiky je těžké se okamžitě dostat do tohoto stavu. To je důvod, proč má smysl budovat dovednosti psaní případů užití, které Vás dovedou k otázkám, o kterých jste ani nevěděli, že se na ně musíte zeptat.
Tímto způsobem si můžete být jisti, že jste nevynechali ani přehlédli nějaké požadavky. To jsou důležité oblasti důvěry a dovedností, které musí začínající business analytik budovat.
Jak přistupovat k případům užití, a jak k uživatelským příběhům
Uživatelské příběhy a případy užití sdílejí některé obecné prvky, jako např. uživatele, který provádí akci, události, které by se měly objevit v reakci na tuto akci a důvod nebo konečný výsledek akce. Rozdíl mezi případem užití a uživatelským příběhem je primárně v úrovni detailu zápisu.
Z porovnání uživatelských příběhů a případů užití ale nevychází žádný vítěz, protože se vzájemně nevylučují. Vývojáři mohou na jednom projektu použít oba přístupy, dokonce v rámci stejného iteračního cyklu. Volba formátu je věcí vhodnosti pro konkrétní projekt, situaci a úroveň formality, kterou organizace vyžaduje.
Například SW projekt na začátku životního cyklu, kdy jsou stále objevovány důležité funkce, může profitovat z důrazu na podrobné případy užití, ale později, až budou zavedeny komplexní funkce, mohou být přínosem jednoduché uživatelské příběhy, protože řeší menší a konkrétnější úkoly.
Volbu mezi případy užití a uživatelskými příběhy jistě ovlivňuje i typ zákazníka a soudržnost vývojového týmu, např. vývoj SW produktu pro zákazníka z oblasti podléhající významné regulaci vyžaduje rozsáhlou dokumentaci ve všech fázích životního cyklu projektu a to pak vede bezvýhradně k případům užití, aby byly splněny požadavky na dokumentaci.
Klíčem k psaní dobrých uživatelských příběhů je pochopit, že záměrem není poskytnout podrobnosti včas na začátku projektu, ale poskytnout rámec, kde je možné detaily přidat, až to bude potřeba.
Dekompoziční přístup pomocí mapy příběhů (Story Map)
Uživatelským příběhům je někdy vyčítána slabina v podobě nedostatečného kontextu. Tu je ale možné řešit pomocí dekompozičního přístupu na bázi mapy příběhů. Začátek mapy příběhů definuje páteřní příběhy – klíčové uživatelské aktivity nebo úkoly, které je třeba splnit, aby mohl produkt fungovat, velké diskrétní kousky funkčnosti, které je třeba dodat, abychom mohli říci, že jsme vyřešili problém či pokryli proces. Tyto velké kusy jsou často označovány jako Epics/eposy (velký příběh). Při vytváření mapy příběhů jsou tyto eposy obvykle položeny do jediného řádku zobrazujícího logickou sekvenci a předávání mezi kroky v procesu. Vizuálně je dobré tyto eposy zapisovat na karty s odlišnou barvou, než karty později objevených uživatelských příběhů.
Dalším krokem je naplnění mapy uživatelskými příběhy, které spadají pod jednotlivé eposy. Každý uživatelský příběh je malý, diskrétní kus funkčnosti, který má hodnotu pro určitého uživatele produktu a je rozkladem výše uvedeného eposu.
Zdroj: Agile and Business Analysis, BCS
Priorita a sekvence ukázaná na mapě – identifikace MVP
Jednou z výhod sestavené mapy příběhů je vizualizace jak posloupnosti, tak priority. Příběhy, které jsou výše na mapě, jsou důležitější než ty, umístěné dole.
Přístup k určování priorit a sekvencí podporuje objevení minimálního životaschopného produktu (MVP) – nalezení skutečné podstaty produktu a jeho uvedení do rukou skutečných zákazníků (pravděpodobně jen malá podskupina zpočátku, ale dost velká na získání zpětné vazby k ověření předpokladů při vývoji produktu) s cílem učit se a přizpůsobovat produkt na základě zpětné vazby.
Mapa příběhů je plynulý a měnící se nástroj – jakmile jsou příběhy dokončeny, jsou odstraněny, přidány nové a změna je přijímána jako normální součást způsobu, jak maximalizujeme poskytování hodnoty zákazníkům, pro které je produkt určen.
Trasovatelnost v uživatelských příbězích
Uživatelské příběhy ve skutečnosti mají silný mechanismus trasovatelnosti zabudovaný v návrhu této techniky na bázi kaskádového vztahu 1:M
- role (aktér) získává hodnotu z 1:M eposů
- jeden epos je dekomponován na 1:M uživatelských příběhů
- jeden uživatelský příběh bude nakonec mít 1:M akceptačních kritérií
- jedno akceptační kritérium bude mít několik testovacích případů, které prokáží, že funguje podle očekávání
Tato trasovatelnost je uzpůsobena prostřednictvím komponenty „so that“ uživatelského příběhu, která zajišťuje, že každý implementovaný kus má přímý vztah k business hodnotě, která má být odvozena od této komponenty/schopnosti.
Lze na agilním projektu použít případy užití místo uživatelských příběhů?
Teoreticky ano, můžete použít případy užití namísto uživatelských příběhů k vyjádření business potřeb, ale souvisí s tím významná rizika. Žádný z agilních přístupů nediktuje, jak máte vyjádřit seznam schopností/funkcí, které musí produkt obsahovat. Případy užití neobsahují jasné vymezení „PROČ“, nejsou proto vhodné k vyjádření jednotlivých business hodnot a podpoře iteračního, inkrementálního přístupu k vývoji produktu; mají tendenci být monolitické a povzbuzují způsob myšlení „vše nebo nic“ oproti adaptivnímu stylu učení a nalezení řešení společně pomocí rychlých sestavení a smyček zpětné vazby.
Rizika a nebezpečí případů užití v agilních projektech
- Kompromitovaná inovace
- případy užití přinášejí spoustu detailů, než získají zpětnou vazbu k produktu
- přináší uživatelské představy do předdefinované interakce a řešení, což vylučuje potenciál pro další inovace
- aspekt zkoumání a učení je ohrožen, zaměření na řešení potřeb se mění na zaměření na zdokonalení již definovaného řešení
- Kompromitované časové osy
- příliš mnoho detailů před budováním kompromituje výhody času v agilním přístupu
- trávit spoustu času detaily případů užití je plýtvání nad tím „co a jak“, aniž bychom se zaměřili na „proč“
- naopak, „co a jak“ je třeba odložit až do okamžiku, kdy je to skutečně potřeba
- Kompromitovaná hodnota
- případy užití matou roli akceptačních kritérií v uživatelských příbězích
- akceptační kritéria se vyvíjejí na úrovni detailů, jak se vyvíjí iterace a společné pochopení prostřednictvím agilního procesu
Uživatelské příběhy byly vyvinuty jako kondenzovaná technika s cílem zmírnit nedostatek „PROČ“ v případech užití a příliš mnoho detailů příliš brzy. Uživatelské příběhy a akceptační kritéria jsou techniky sladěné tak, aby přinášely kompromis výhody agilního přístupu a případů užití.
Týmy uvažující o použití případů užití by měly důrazně zvážit zkoumání metod a vývoje definování akceptačních kritérií (zejména modelu <given><when> <then>) s mnoha scénáři a úrovněmi podrobností, které se vyvíjejí jako zpětná vazba v iteračním cyklu a poskytování přírůstků produktu v průběhu jeho vývoje. Vedení uživatelských příběhů (včetně map a epických příběhů) spolu s dobře definovanými a postupně se vyvíjejícími akceptačními kritérii splní cíl využití výhod agility bez ohrožení časové osy a hodnoty.
Srovnání případů užití a uživatelských příběhů
Porovnejme v následující tabulce souvislosti elementů zápisu případu užití a uživatelského příběhu
0. „Jako student se chci registrovat na kurz, abych ho mohl absolvovat flexibilně online formou“
- Given – registrovaný student
- And – poskytnuty korektní přihlašovací údaje
- When – zvolí „Vytvořit osobní plán“ ze seznamu nabídnutých možností
- And – vybere kurz pro přidání do osobního plánu ze seznamu disponibilních kurzů
- And – kurz není obsazený
- And – student splňuje všechny předpoklady pro absolvování kurzu
- And – vybraný kurz není v konfliktu s jiným kurzem v osobním plánu
- Then – vybraný kurz je přidán do osobního plánu
- And – počet volných míst na kurzu je snížen o 1
| Element případu užití | Obsah | Element uživatelského příběhu | Řádek uživatelského příběhu |
|---|---|---|---|
| Název případu užití | Registrace kurzu | I want to What | 0 |
| Primární aktér | Student | As a Who | 0 |
| Sekundární aktér | Vedoucí kurzu, Administrátor portálu | N/A | N/A |
| Zájmy zainteresovaných stran | Student:
umožnit flexibilní absolvování kurzu online |
So that goal (benefit) | 0 |
| Vedoucí kurzu:
zajistit, že student má odpovídající základní znalosti pro absolvování kurzu |
N/A |
N/A | |
| Administrátor portálu:
zajistit bezpečné používání portálu |
N/A |
N/A | |
| Vstupní podmínky | Registrovaný student
Poskytnuty korektní přihlašovací údaje |
Given … And … | 1,2 |
| Scénář | Student na portálu zvolí „Vytvořit časový plán“ | When … | 3 |
| Student vyhledá kurz k přidání do plánu | And … | 4 | |
| Vybraný kurz je přidán do plánu studenta | Then … | 8 | |
| Alternativa | Kurz je obsazen | When … And … | 5 |
| Student nesplňuje předpoklady pro absolvování kurzu | When … And … | 6 | |
| Termínový konflikt kurzů v plánu | When … And … | 7 | |
| Výstupní podmínky | Počet volných míst na kurzu je snížen o 1 | Then … And … | 9 |
