Archiv autora: Radek Gajdušek

Zažili jste někdy situaci, kdy máte před sebou obrovskou věc a nevíte z které strany začít? Řešíte, jak uchopit rozpad nové funkcionality tak, abyste co nejdříve dodali zákazníkovi co největší hodnotu a až poté dělali na dalších částech? Právě pro vás může být velmi užitečná metoda User Story Mapping, která se používá pro rozpad velkých celků na menší. Připravili jsme pro vás proto praktický návod krok za krokem, který vás technikou provede.

O co se jedná?

• Vizualizace uživatelského toku v čase – vizualizuje akce, které dělá uživatel v systému, aby dosáhl (předem) definovaného cíle.

• Užitečný nástroj na tvorbu kostry Backlogu pro Tým nebo Squad.

• Výsledná mapa pomáhá týmu a Product Ownerovi s prioritizací a určením toho, co je pro zákazníka skutečně důležité.

• Prvním výstupem User Story Mappingu je množina User Stories, které dohromady tvoří MVP (Minimal Viable Product).

Jak metodu použít?

1. Vyberte zástupce různých rolí – Vývojář, Designér, Tester, Product Owner (ideálně max. 10 lidí).
2. Požádejte Product Ownera o sepsání krátkého popisu toho, co je potřeba zmapovat, ideálně ve formátu:
   1. CO? – produkt, nová funkcionalita, kterou chce přidat, nebo problém, který potřebuje vyřešit;
   2. PRO KOHO? – popisuje zákazníky produktu nebo uživatele, kteří budou danou funkcionalitu využívat. Pro každého takového uživatele explicitně popsat, co mu to přináší;
   3. PROČ? – popisuje důvod, proč se firma rozhodla danou funkcionalitu nebo produkt vytvořit. 
3. Vyhraďte si 2-3 hodiny času a prostor s velkou tabulí nebo zdí.
4. Začnete představením vstupu Product Ownera a pokračujte společnou definicí:
   1. Startovacího bodu – bod, ve kterém uživatel vstoupí do systému, začne svou interakci (např. Uživatel se přihlásí do webového rozhraní internetového bankingu);
   2. Cílového stavu – cílový stav, kdy je potřeba firmy/zákazníka naplněna (např. Uživatel provedl finanční transakci).
      
5. Společně ve skupině vytvořte tzv. Páteř (Backbone) Story Mapy tak, že pojmenujete větší aktivity, které uživatel musí v systému udělat, aby dosáhl cíle definovaného v minulém kroku. Aktivity vizualizujte na zdi/tabuli zleva doprava tak, jak jdou za sebou v čase.
6. Každou aktivitu rozpadněte na menší části – tzv. Uživatelské úkoly (User Tasks). Přemýšlejte nad:
   1. Alternativními způsoby, jak lze danou aktivitu v systému realizovat;
   2. Jaké okrajové případy mohou nastat (něco nebude fungovat, spadne server apod.)?
   3. Jak by k dané aktivitě přistupovali různí uživatelé systému?
   4. Detaily aktivity a různými vylepšeními;
7. Při tvoření se snažte vertikálně prioritizovat podle hodnoty a důležitosti daného zákaznického úkolu. 
8. Vyznačte na mapě první nejmenší řez zleva doprava, kterým je zákazník schopen dosáhnout definovaného cíle – vzniká MVP release (na obrázku znázorněn červenou čarou).
9. Pokračujte vyznačením dalších řezů, z nichž každý přidá další novou ucelenou funkcionalitu pro zákazníka. Platí pravidlo – 1 řez = 1 release. Při určování dalších řezů můžete zvažovat:
   1. Různé persony – můžete zacílit konkrétní inkrementy/release na konkrétní typy uživatelů (např. po doručení MVP se zaměřit na firemní zákazníky a na základě toho prioritizovat jednotlivé uživatelské úkoly);
   2. Přidání dalších klíčových možností a alternativ do produktu podle důležitosti nebo nejčastějšího způsobu využití.
10. Po vybudování User Story Mapy a vydefinování řezů můžete výsledek “překlopit” například do JIRA a máte tak vytvořený iniciální Backlog.
    1. Jeden řez reprezentuje ideálně jeden Epic. 

    2. Priorita v Backlogu je dána řezem shora dolů a pak po sloupcích zleva doprava (viz. čísla v pravém dolním rohu kartiček na obrázku).

Kdy není technika vhodná?

• Nový produkt nebo funkcionalita nevyžaduje žádné nebo pouze minimálni interakce uživatele v systému (např. technické změny na pozadí, refaktoring apod.).

• Nová funkcionalita je pouze malá změna v obrovském fungujícím systému (mapování stávajícího systému by zabralo hodně času).

• Chcete si pouze namapovat Stories, které už máte předem vymyšlené (lidé nebudou brát výsledek za svůj, protože je už vše dáno dopředu).

• Pokud nejste schopni svolat na jedno místo dostatek rozdílných rolí – můžete přijít o důležité nápady, perspektivy, otázky, poznatky (minimum je Product Owner, Vývojář, Tester a Designér).

Pokud byste si chtěli vyzkoušet techniku v praxi, neváhejte se nám ozvat, velmi rádi vás workshopem provedeme od začátku až do konce na konkrétním příkladu z vaší praxe.

Jeden z principů Agilního manifesta říká: ,,Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším a následně koriguje a přizpůsobuje své chování a zvyklosti.“ Jedním z klíčových nástrojů pro naplnění tohoto bodu jsou nepochybně retrospektivy.

Mnoho týmů je s železnou pravidelností praktikuje, vkládá do nich nemalé usílí, ale očekávaný výsledek se stále ne a ne dostavit. Častou příčinou může být to, že v nich chybí ingredience, které způsobí, že budou mít tu správnou šťávu.

Přinášíme vám proto 11 praktických tipů, které pomohou vaše retrospektivy posunout ještě dále – k mistrovství.

1. Přesnost je výsadou králů

Čekáte 15 minut po začátku, než si všichni uvaří kafe a sejdou se v místnosti? Začínejte vždy na čas a případným opozdilcům neshrnujte, co se probralo do jejich příchodu. Uvidíte, že se časem naučí chodit včas, aby o nic zajímavého nepřišli. To mimochodem platí i u ostatních meetingů. Facilitátor by měl vždy dorazit o pár minut dříve, aby si stihl připravit místnost a vše nezbytné pro hladký průběh retrospektivy.

2. Vyhnívající akční kroky

Generujete akční kroky, ale nikdo je neplní? Ještě důležitější, než dělat retrospektivy, je systematická práce s akčními kroky. Každá retrospektiva musí začínat tím, že zkontrolujeme akční kroky z minula a pobavíme se o tom, v jakém jsou stavu. Když to uděláte poprvé, možná se stane hlavním tématem retrospektivy téma, proč jako tým neplníme akční kroky a co je potřeba změnit. I toto je v pořádku. Dobrou praxí, jak mít úkoly neustále na očích, je jejich přepsání na fyzickou tabuli v kanceláři nebo se domluvit s týmem a procházet je alespoň dvakrát do týdne na konci Daily stand-upu. 

3. Děláme pořád stejný formát

Lidé vědí, co čekat, přicházejí s již napsanými lístečky a generujete pořád stejná témata? Zkuste něco nového, nabídněte týmu jiný úhel pohledu na jejich práci a přineste jako facilitátor něco zábavnějšího než + a -. Dobrým odrazovým můstkem je Retromat, kde si můžete generovat náhodný formát. Nebo si zkuste vymyslet úplně vlastní formát. Uvidíte, že to není nic složitého. 

4. Řešíme stále jen problémy

Už jste zkusili udělat pouze pozitivní retrospektivu? Určitě neděláte vše špatně a je spousta věcí, které jako tým děláte dobře a můžete se za ně poplácat po zádech. Zkuste pro jedenkrát zakázat hovořit o problémech a uvidíte efekt. Máme velice rádi tzv. KUDOS, kdy můžete ocenit kohokoliv z týmu a poděkovat mu za pomoc nebo něco neobyčejného, co vykonal v tomto sprintu.

5. Chceme vyřešit všechna témata

Když už jsme si dali práci s generováním témat, tak máme pocit, že je nemůžeme nechat nevyřešené. Je naprosto v pořádku, když po prioritizaci proberete pouze jedno téma s největším počtem hlasů, kvalitně a do hloubky. Pokud jsou ostatní věci důležité, objeví se hned na další retrospektivě.

6. Tým ukazuje na všechny okolo

Retrospektiva je primárně záležitostí týmu, i když se samozřejmě mohou objevit i témata, ke kterým potřebuje někoho dalšího. Měli bychom však pokaždé začínat u sebe a svého týmu, neboť to jsou věci, na které máme stoprocentní vliv a můžeme je okamžitě změnit. Jakmile máme uklizeno “doma”, jdeme za hranice týmu. Dobrý facilitátor toto dokáže týmům zvědomit a vrátit je zpět k myšlenkám, co mohou oni sami změnit.

7. Musíme nutně využít všechen čas

Dobrá zpráva pro vás – rozhodně nemusíte. Pokud není dnes co k řešení a nebo jsme již vše probrali, skončete klidně po 20ti minutách. To nejhorší, co můžete udělat je, že budete neustále zkoušet generovat na sílu další témata a snažit se vyplnit čas. Využijte ho například tím, že si dáte jako tým společné kafe nebo procházku na čerstvém vzduchu – bude v tom rozhodně větší hodnota. Pokud se však tato situace opakuje už potřetí, je na čase zkusit jiný formát, protože už tým mohl spadnout do stereotypu a “zlenivět”.

8. Hledání svatého grálu

Již několik retrospektiv se vrací to samé téma, diskutujeme jej neustále dokola a bez jakéhokoliv výsledku. Zkuste na místo hledání ideálu udělat už konečně aspoň malý krůček vpřed, malý experiment, který vás posune vpřed. Možná nebude ideální, možná bude úplně mimo, ale pořád lepší něco vyzkoušet, než to půl roku do posledního detailu pouze promýšlet.

9. Prázdné akční kroky

Dbejte vždy na to, aby všechny akční kroky, které vypadnou z vaší retrospektivy, byly přiřazeny na konkrétního člověka, bylo specifikováno, co konkrétně se má udělat a do kdy má být úkol splněn. Můžete využít například techniku SMART. Každá retrospektiva by měla končit alespoň jedním akčním krokem. Scrum Guide dokonce hovoří o tom, že by alespoň jeden akční krok měl být naplánován do dalšího sprintu.

10. Všechny úkoly jsou na Scrum Masterovi (SM)

Typickou situací je, že je SM zodpovědný za proces a nasazení Scrumu, a proto tým nabyl dojmu, že je také zodpovědný za všechny úkoly z retrospektivy. V tomto případě může SM nabídnout týmu, že úkol udělá s některým členem týmu v páru nebo si vezme na sebe maximálně jeden úkol a zbytek si musí rozebrat tým.

11. Retrospektiva je monotónní

Zkuste naplánovat retrospektivu na nějakém netradičním místě. Někdy postačí meetingovka se sedacími vaky, která vykouzlí neformální atmosféru nebo zajděte ven do parku. Alternativou může být posezení u (nealko) pivka v hospůdce, kterou má tým nejraději. Nebojte se popustit uzdu své fantazii a experimentovat.

Pokud Vás některý z tipů zaujal, neváhejte ho vyzkoušet a dejte nám vědět, jak tento experiment zafungoval ve vašem týmu.