V posledním díle našeho seriálu článků o praktických metodách, které mohou zachránit (nejen agilně řízený) projekt v nesnázích, vám představíme techniku User Story Mapping (USM).

Jedním z hlavních cílů přípravné fáze projektu vývoje nového produktu je sběr požadavků ve spolupráci s byznysem a jejich následná prioritizace. Již jsme si v předchozích dílech představili metodu Impact mapping, která pomůže na high-level úrovni pojmenovat klíčové oblasti funkcionalit a jejich vazbu na cíle projektu, nebo prioritizační nástroje MoSCoW a KANO. Nyní se na požadavky podíváme z jiného úhlu pohledu a daleko více v detailu. Metoda User Story Mapping je vhodná v okamžiku, kdy sbíráme detailní požadavky (ideálně například zaznamenané ve formátu User Stories) a snažíme se o co nejlepší porozumění mezi byznysem a vývojovým týmem. Na rozdíl od běžně používaných seznamů, pracuje metoda USM s kontextem a přidává i vizuální složku, čímž jednoznačně přispívá k lepšímu vzájemnému pochopení.

Obr. 1: Metoda User Story Mapping používá vizuální složku, čímž přispívá k lepšímu vzájemnému pochopení.

User Story Mapa, jak název již trochu napovídá, je vizuální záznam „příběhu“, tedy procesu, z pohledu určitého uživatele. Při vytváření User Story Mapy zvolíme konkrétního uživatele a následně popíšeme jeho zamýšlenou interakci se systémem (jedná se o sled aktivit, jinými slovy proces, které uživatel vykonává). Nejdříve popisujeme jen základní proces, bez větví a negativních scénářů (co se stane, když něco není podle předpokladů), později se dopracovávají i tyto detaily.

Jako příklad jsme zvolili online zakoupení jízdenky na vlak. Na obrázku níže vidíte jednotlivé high-level aktivity procesu, rozpadnutí dále do podrobnějších činností a User Stories. V rámci vizualizace jsme schopni také zaznamenat, které User Stories budou zahrnuty do jednotlivých releasů.

Obr. 2: Na obrázku níže vidíte jednotlivé high-level aktivity procesu a jejich rozpadnutí dále do podrobnějších činností a User Stories.

Při čtení User Story Mapy postupujeme zleva doprava – zde sledujeme osu času, a dále pro jednotlivé aktivity a jejich zpodrobnění do činností pak ze shora dolů. Čím níže je v této ose user story umístěna, tím má nižší prioritu a bude zahrnuta do pozdějších releasů. Na nejnižší úrovni můžeme mít požadavky zaznamenané i v hrubším detailu, než je User Story, například jako Epic, protože v danou chvíli nemusí být ještě potřebný detail k dispozici.

User Story Mapu můžeme vytvořit z User Stories v backlogu, hlavní přidanou hodnotou je zde kontext průchodu uživatele systémem (proces). Právě díky přiřazení User Stories k jednotlivým aktivitám procesu je vidět logické provázanosti a také oprávněnost zařazení User story do mapy. Velikou přidanou hodnotou je lepší vzájemné porozumění mezi IT a byznysem z hlediska toho, co má systém dělat, jaká jsou očekávání a jaké množství funkcionalit bude zahrnuto do daného release. Toho lze využít i pro účely změnového řízení. Pokud přijde prioritní požadavek ze strany byznysu na určitou funkčnost, lze na USM přehledně ukázat naplněnost release a provázanost požadavků a dále diskutovat o tom, zda se nový požadavek do releasu vejde, zda má smysl ho zařazovat do tohoto release a v neposlední řadě také o tom, kterou funkčnost bude potřeba z release přesunout na později, aby bylo možno tuto změnu kapacitně a časově zvládnout. Formát User Story Mapy je přehledný a pochopitelný i pro lidi bez analytických znalostí, lze ho tedy použít i při komunikaci na management. V některých případech může User Story Mapa nahradit i část analýzy.

Je praktické vytvořit pro každý proces či logicky provázanou skupinu činností jednu User Story Mapu. Je pak snáze čitelná a lépe se udržuje. V případě, že určitou činnost (nebo její větší část) mohou v systému vykonávat dva různí uživatelé, je toto možné zachytit přidáním řádku s vyznačením uživatelů a relevantních činností, není nutné USM vytvářet duplicitně. Formát mapy je potřeba přizpůsobit vždy konkrétním potřebám projektu tak, aby co nejlépe podporoval komunikaci a spolupráci na požadavcích.

User Story Mapu lze vytvářet jak ve fyzické, hmatatelné verzi, pomocí samolepících papírků umístěných na zdi, nebo v některém ze SW nástrojů. Každá z variant má své přednosti a slabé stránky. U papírové verze je potřeba mít prostor, kde může mapa nějakou dobu viset přístupná všem členům týmu, a dále je nutno zvolit kvalitní samolepící štítky, aby nedocházelo k jejich opadávání. Tuto variantu záznamu nemůžeme doporučit pro fyzicky distribuované pracovní týmy. Naproti tomu elektronická verze umožňuje snadné sdílení bez ohledu na umístění pracovníků, nemusí být ale bezprostředně přístupná všem (je zapotřebí login do systému).

Pokud vás dané téma zaujalo, více informací naleznete například v knize User Story Mapping: Discover the Whole Story, Build the Right Product z nakladatelství O’REILLY. Pro zachycení User Story Map v elektronické podobě existuje také cela řada softwarových nástrojů, některé jsou i zdarma. Pro ukázku v tomto článku byl zvolen nástroj Realtime Board.

http://bit.ly/evamachackova http://bit.ly/zdenekmachacek

Eva a Zdeněk Macháčkovi Autoři článku pracují jako konzultanti ve společnosti Principal engineering. Zaměřují se na strategické poradenství a vzdělávání v oblasti nových trendů businessu a podnikového IT. Stojí také za zrodem projektu www.agileware.eu, který má za cíl zpřístupnit metody a nástroje pro efektivnější práci a úspěch projektů.