Abstrakt
Kniha je vyprávěný algoritmus vedení vývojového procesu od nápadu po implementaci s použitím technik agile. Proces je rozdělen do kroků a v každém kroku jsou uvedeny metody pro daný krok procesu. Autor uvádí, že většina metod není originální a nesnaží se o originalitu. Ale dobrý styl vyprávění a určitá celistvost procesu činí knihu velmi užitečnou.
Klíčová technika mapy uživatelských příběhů spočívá ve strukturalizaci myšlenek a cílení v průběhu procesu, kterým uživatel prochází.
Přičemž proces může být vyprávěn různými způsoby. Krok může být postaven na základě dosažení klíčové hodnoty, nebo může být jednoduše představen pracovní den uživatelů, jak procházejí systémem. Autor se soustředí na to, že procesy by měly být vyprávěny, formulovány jako příběh uživatele na mapě procesu, což dalo název mapa uživatelských příběhů.
Komu to je potřeba
Pro IT analytiky a projektové manažery. Povinné k přečtení. Čte se snadno a příjemně, kniha má průměrnou velikost.
Odvolání
Ve své nejjednodušší podobě, jak to funguje.
Návštěvník přichází do kavárny, vybírá jídla, objednává, dostává jídlo, jí, platí.
Je možné psát požadavky, co od systému chceme v každé fázi.
Systém by měl zobrazovat seznam jídel, u každého jídla složení, váhu a cenu a měl by mít možnost přidat do košíku. Proč jsme si v těchto požadavcích jisti? V "standardním" popisu požadavků to není uvedeno a to vytváří rizika.
Vykonavatelé, kteří nechápou, proč je to potřeba, obvykle dělají něco jiného, než je potřeba. Vykonavatelé, kteří nejsou zapojeni do procesu vytváření nápadu, nejsou zapojeni ani do výsledku. Agile říká, pojďme se zaměřit především ne na systém, ale na lidi, na spotřebitele, jejich úkoly a cíle.
Vytváříme persony, abychom při empatii dodali detaily a z pohledu person začneme vyprávět příběhy.
Kancelářský pracovník Zachar šel na oběd a chce si rychle zakousnout. Co potřebuje? Nápad — asi chce business lunch. Další nápad, chce, aby si systém pamatoval jeho preference, protože drží dietu. Ještě nápad. Chce, aby mu hned přinesli kávu, protože je zvyklý pít kávu před obědem.
A existuje také podnik (orgsonáž - postava, která zastupuje zájmy nějaké organizace). Podnik chce zvýšit průměrnou útratu, zvýšit frekvenci nákupů, zvýšit zisk. Nápad - co kdybychom nabízeli neobvyklá jídla z nějaké kuchyně? Další nápad - co kdybychom zavedli snídaně.
Nápady je možné a nutné konkretizovat, transformovat a zpracovat do podoby uživatelského příběhu. Jako zaměstnanec obchodního centra Zachar chci, aby mě systém identifikoval, abych dostával menu v souladu s mými preferencemi. Jako číšník chci, aby mě systém upozornil, kdy mám přistoupit ke stolu, aby byl zákazník spokojen s rychlou obsluhou. A tak dále.
Desítky příběhů. Poté priorizace a backlog? Jeff poukazuje na vznikající problémy: uvázání v drobných detailech a ztráta konceptuálního porozumění, plus priorizace funkcionality vytváří roztříštěný obraz kvůli nesouladu s cíli.
Cesta autora: Prioritizujeme nikoli funkcionalitu, ale výsledek = to, co uživatel získává na konci.
Zřejmý nezřejmý bod: sesion priorizace neprobíhá celým týmem, protože je to neefektivní, ale třemi lidmi. První odpovídá za podnikání, druhý za uživatelskou zkušenost a třetí za realizaci.
Vymezíme minimálně pro řešení jednoho úkolu uživatele (minimální životaschopné řešení).
Detailujeme nápady prvního prioritu pomocí uživatelského příběhu, návrhů designu, omezení a obchodních pravidel na mapě uživatelských příběhů prostřednictvím vyprávění a diskuse s týmem, co je potřeba pro postavy a zúčastněné strany v každém kroku procesu. Ostatní nápady necháváme neprojednané, v backlogu možností.
Proces se zaznamenává ve formě karet zleva doprava, a nápady na kartách pod jednotlivými kroky procesu. Určitě je potřeba projít celou historickou cestu společně se členy týmu, aby došlo k vzájemnému pochopení.
Práce tímto způsobem vytváří celistvost souladu s procesy.
Získané nápady je potřeba ověřit. Člen týmu si nasazuje klobouk postavy a prožívá den postavy v hlavě, řeší její úkol. Existuje možnost, kdy nevidí dosavadní výstupy, vytváří karty znovu a tým objevuje alternativy.
Pak se provede detailní hodnocení. K tomu stačí tři lidé. Odpovědný za uživatelskou zkušenost, vývojář a tester s oblíbenou otázkou: „A co když…“.
V každé fázi se diskuse vede podle mapy procesů uživatelské historie, což umožňuje udržet na paměti úkol uživatele a vytvořit celkové porozumění.
Je podle autora potřeba dokumentace? Ano, je. Ale jako poznámky, které připomínají, o čem jsme se dohodli. Zapojení člověka zvenčí opět vyžaduje diskusi.
Autor se nezabývá hlouběji tématem dostatečnosti dokumentace, soustředí se na nezbytnost diskusí. (Ano, dokumentace je potřebná, ačkoli to lidé, kteří nejsou hluboce obeznámeni s agile, často popírají). Také zpracování jen části možností může vést k nutnosti úplného přepracování celého systému. Autor upozorňuje na riziko nadměrného zpracování v případě, že se nedaří najít správnou myšlenku.
Aby se snížila rizika, je třeba rychle získat zpětnou vazbu k vytvářenému produktu, abychom minimalizovali škody způsobené vytvořením „nesprávného“ produktu. Vytvořili jsme skicu myšlenky — validovali u uživatele, skicu prototypů rozhraní — validovali u uživatele atd. (Samostatně se uvádí, jak validovat programové prototypy). Cílem tvorby softwaru, zejména na počátečním stádiu — je učení prostřednictvím rychlé zpětné vazby, takže prvně vytvořený produkt je skicou, která může dokázat nebo vyvrátit hypotézu. (Autor se opírá o práci Erica Riese „Startup metodou Lean“).
Mapa příběhů pomáhá navázat komunikaci, pokud realizaci zajišťuje několik týmů. Co by mělo být na mapě? To, co je potřeba k podpoře diskuse. Nejen user story (kdo, co, proč), ale také nápady, fakta, skici rozhraní atd.
Rozdělením karet na mapě příběhů na několik horizontálních linií lze rozdělit práce na vydání — vyčlenit to nejnutnější, vrstvu na přidání funkčnosti a mašličky.
Přednášíme příběhy na mapě procesu.
Zaměstnanec přišel na oběd.
Co chce? Rychlost obsluhy. Aby jeho oběd na něj čekal na stole nebo alespoň na podnose. Oops — vynechaný krok: zaměstnanec si chtěl dát najíst. Přihlásil se do systému a vybral možnost business oběda. Viděl kaloričnost a shodu s nutričními hodnotami, aby dodržoval dietu a nepřibíral. Uviděl obrázky pokrmu, aby se rozhodl, zda jí v tomto místě nebo ne.
Dále se chystá pro oběd? Nebo mu snad oběd přinesou do kanceláře? Pak je dalším krokem výběr místa stravování. Chce vidět přesný čas dodání a kolik to bude stát, aby se rozhodl, kam investovat čas a energii — na sestup dolů nebo na práci. Chce vidět vytíženost kavárny, aby se vyhnul frontám.
Dále zaměstnanec dorazil do kavárny. Chce vidět svůj podnos, aby si ho vzal a hned šel na oběd. Kavárna chce přijmout peníze, aby na obsluze vydělala. Zaměstnanec chce strávit co nejméně času na platbách, aby neztrácel cenný čas. Jak to udělat? Zaplatit předem nebo naopak po obsluze na dálku. Nebo zaplatit v okamžiku pomocí kiosku. Co je z toho nejdůležitější? Kolik lidí je ochotno platit kartou za oběd? Kolik lidí důvěřuje uložení čísla karty pro opakované platby této jídelny? Bez výzkumu v terénu není jasné, potřebujeme testování.
Na každém kroku procesu je třeba nějakým způsobem zajistit funkčnost, k tomu je nutné vzít za základ nějakou osobu a určit, co je pro něj důležitější (ta samotná trojice vybírači). Příběh byl dokončen = bylo vytvořeno životaschopné řešení.
Nyní následuje podrobnosti. Zákazník chce vidět vytíženost kavárny, aby se vyhnul frontám. Co konkrétně chce?
Prohlížet předpověď, kolik lidí tam bude za 15 minut, když tam dorazí.
Sledovat průměrný čas obsluhy v kavárně a jeho dynamiku na půl hodiny dopředu.
Sledovat situaci a dynamiku obsazenosti stolků.
A co když systém předpovědi dává nejasné výsledky nebo přestane fungovat?
Sledovat fronty v kavárně přes video, stejně jako obsazenost stolků. Hm, proč to neudělat na prvním místě?!
Autor se zaměřuje na jednoduché cvičení pro procvičení praxe: zkuste si představit, co děláte ráno po probuzení. Jedna karta = jedna činnost. Zesvětlete karty (místo mletí kávy – vypít povzbudivý nápoj), abyste odstranili jednotlivé detaily a zaměřili se na cíl, nikoli na způsob realizace.
Pro koho je tato kniha – pro IT analytiky a projektové manažery. Povinné čtení.
Aplikace
Diskuse a rozhodování jsou efektivní ve skupinách o 3 až 5 osobách.
Napište na první kartě, co je třeba vyvinout, na druhé – co je třeba opravit z první, na třetí – co je třeba opravit z první a druhé.
Připravujte příběhy jako dorty – ne písemně recept na výrobu, ale zjistěte, pro koho, k jaké příležitosti, pro kolik lidí je dort. Pokud rozdělujete realizaci, nedělejte to na přípravu korpusů, krému atd., ale na výrobu malých hotových dortíků.
Vývoj softwaru je podobný natáčení filmu, kdy je potřeba důkladně vypracovat a vyladit scénář, zorganizovat scénu, herce atd. před zahájením natáčení.
Zdroje budou vždy nedostatečné.
20 % úsilí přináší viditelný výsledek, 60 % přináší nejasný výsledek, 20 % úsilí je kontraproduktivních – proto je důležité soustředit se na vzdělání a neztrácet naději v případě negativního výsledku.
Komunikujte přímo s uživateli, snažte se vidět svět z jejich pohledu. Zaměřte se na určité problémy.
Detailizace a zpracování příběhu pro hodnocení je ta nejúnavnější část scrum, udělejte z diskuzí setkání v režimu akvária (u tabule diskutuje 3-4 lidé, pokud se někdo chce zapojit, nahradí někoho jiného).
Zdroj: habr.com
