Anotace
Kniha je vyprávěným algoritmem pro provádění vývojového procesu od nápadu po implementaci pomocí agilních technik. Proces je uspořádán v krocích a v každém kroku jsou uvedeny metody pro krok procesu. Autor poukazuje na to, že většina metod není originální, aniž by si na ně dělal nárok. Ale dobrý styl psaní a určitá integrita procesu činí knihu velmi užitečnou.
Klíčovou technikou mapování uživatelského příběhu je strukturovat nápady a výkony, když uživatel prochází procesem.
Proces lze přitom popsat různě. Můžete vytvářet kroky, jak dosáhnete klíčové hodnoty, nebo si můžete jednoduše představit a představit si pracovní den uživatelů, jak prochází pomocí systému. Autor se zaměřuje na to, že procesy je třeba nastínit, vyslovit je formou uživatelského příběhu na procesní mapě, což nám dalo název uživatelská příběhová mapa.
Kdo to potřebuje
Pro IT analytiky a projektové manažery. Povinná četba. Snadno a příjemně se čte, kniha je střední velikosti.
odvolání
Ve své nejjednodušší podobě to funguje takto.
Návštěvník přijde do kavárny, vybere si jídla, objedná, dostane jídlo, nají se a zaplatí.
V každé fázi můžeme napsat požadavky na to, co od systému chceme.
Systém by měl zobrazovat seznam jídel, každé jídlo má složení, váhu a cenu a mít možnost vložit do košíku. Proč jsme si jisti těmito požadavky? Toto není popsáno ve „standardním“ popisu požadavků a to vytváří rizika.
Umělci, kteří nechápou, proč je to nutné, obvykle dělají špatnou věc. Účinkující, kteří nejsou zapojeni do procesu vytváření nápadu, se nepodílejí na výsledku. Agile říká, zaměřme se primárně ne na systém, ale na lidi, na spotřebitele, jejich úkoly a cíle.
Vytváříme persony, dáváme jim detaily pro empatii a začínáme vyprávět příběhy ze strany persony.
Zaměstnanec kanceláře Zakhar šel na oběd a chce si dát rychlou svačinu. co potřebuje? Myšlenka je taková, že pravděpodobně chce pracovní oběd. Další myšlenka je, že chce, aby si systém zapamatoval jeho preference, protože je na dietě. Další nápad. Chce, aby mu kávu přinesli hned, protože je zvyklý pít kávu před obědem.
A existuje také podnikání (organizační charakter je znak zastupující zájmy organizace). Firmy chtějí zvýšit průměrnou kontrolu, zvýšit frekvenci nákupů a zvýšit zisky. Myšlenka je - nabídněme neobvyklá jídla některé kuchyně. Další nápad - pojďme představit snídani.
Nápady mohou a měly by být konkretizovány, transformovány a prezentovány formou uživatelského příběhu. Jako zaměstnanec Zakhar Business Center chci, aby mě systém rozpoznal, abych mohl obdržet menu na základě svých preferencí. Jako číšník chci, aby mě systém upozornil, kdy mám přistoupit ke stolu, aby byl klient spokojen s rychlou obsluhou. A tak dále.
Desítky příběhů. Další je stanovení priorit a nevyřízených záležitostí? Jeff poukazuje na problémy, které vznikají: zabřednutí do malých detailů a ztráta koncepčního porozumění, plus upřednostňování funkčnosti vytváří roztrhaný obraz kvůli nekonzistenci s cíli.
Cesta autora: Upřednostňujeme nikoli funkčnost, ale výsledek = to, co uživatel nakonec získá.
Zřejmý nezřejmý bod: sezení o stanovení priorit neprovádí celý tým, protože je neúčinné, ale tři lidé. První je zodpovědný za obchod, druhý za uživatelskou zkušenost a třetí za implementaci.
Zvolme minimum pro řešení jednoho uživatelského problému (minimální schůdné řešení).
První prioritní nápady podrobně popisujeme pomocí uživatelských příběhů, návrhových náčrtů, omezení a obchodních pravidel na mapě uživatelského příběhu tím, že v každém kroku procesu sdělíme a prodiskutujeme s týmem, co lidé a zainteresované strany potřebují. Zbývající nápady necháváme neprozkoumané v nevyřízených příležitostech.
Proces je napsán na kartách zleva doprava s nápady na kartách pod kroky procesu. Je nezbytné, aby byla cesta celým příběhem prodiskutována společně se členy týmu, aby bylo zajištěno vzájemné porozumění.
Vypracování tímto způsobem vytváří integritu v souladu s procesy.
Získané nápady je třeba otestovat. Nečlen týmu si nasadí klobouk a prožívá den daného člověka v jeho hlavě a řeší jeho problém. Je možné, že nevidí vývoj, znovu vytváří karty a tým pro sebe objevuje alternativy.
Pak jsou zde detaily pro hodnocení. Na to stačí tři lidé. Zodpovědný za uživatelskou zkušenost, vývojář, tester s oblíbenou otázkou: „Co když...“.
V každé fázi se diskuse řídí procesní mapou historie uživatele, která umožňuje mít na paměti úkol uživatele a vytvořit koherentní porozumění.
Je podle názoru autora dokumentace nezbytná? Ano, potřebuji to. Ale jako poznámky, které vám umožní zapamatovat si, na čem jste se dohodli. Zapojení outsidera opět vyžaduje diskusi.
Autor se nezabývá tématem dostatku dokumentace, zaměřuje se na potřebu diskuse. (Ano, dokumentace je potřeba, bez ohledu na to, jak to tvrdí lidé, kteří nemají hluboké pochopení pro agilitu). Také rozpracování pouze části schopností může vést k nutnosti kompletního přepracování celého systému. Autor upozorňuje na riziko přílišné rozpracovanosti v případě, kdy je myšlenka chybná.
Pro eliminaci rizik je nutné rychle získat zpětnou vazbu na vytvářený produkt, aby se minimalizovaly škody při vytváření „špatného“ produktu. Udělali jsme náčrt nápadu - ověřili jsme to s uživatelem, načrtli prototypy rozhraní - ověřili to s uživatelem atd. (Samostatně je zde několik informací o tom, jak ověřovat prototypy programů). Cíle tvorby softwaru, zejména v počáteční fázi, jsou učení se prostřednictvím získávání rychlé zpětné vazby, takže prvním vytvořeným produktem jsou skici, které dokážou potvrdit nebo vyvrátit hypotézu. (Autor se opírá o práci Erica Riese „Startup using Lean method“).
Mapa příběhu pomáhá zlepšit komunikaci, když je implementace prováděna ve více týmech. Co by mělo být na mapě? Co potřebujete k udržení konverzace. Nejen uživatelský příběh (kdo, co, proč), ale nápady, fakta, náčrtky rozhraní atd...
Rozdělením karet na mapě historie do několika vodorovných linií můžete rozdělit práci na vydání - zvýraznit naprosté minimum, vrstvu zvyšující se funkčnosti a oblouky.
Vyprávíme příběhy na mapě procesu.
Zaměstnanec přišel na oběd.
Co chce? Servisní rychlosti. Aby na něj oběd už čekal na stole nebo alespoň na podnose. Jejda – zmeškaný krok: zaměstnanec chtěl jíst. Přihlásil se a vybral možnost pracovního oběda. Viděl obsah kalorií a nutriční obsah, aby mu pomohl při dietě a nepřibíral na váze. Viděl obrázky pokrmu, aby se rozhodl, zda bude na tomto místě jíst nebo ne.
Dále půjde na oběd a večeři? Nebo možná doručí oběd do jeho kanceláře? Pak je krokem procesu výběr místa k jídlu. Chce vidět, kdy mu to bude doručeno a kolik to bude stát, takže si může vybrat, kde stráví svůj čas a úsilí - jít dolů nebo jít do práce. Chce vidět, jak je kavárna vytížená, aby se nestrkal ve frontách.
Pak zaměstnanec přišel do kavárny. Chce vidět svůj tác, aby si ho mohl vzít a jít rovnou na večeři. Kavárna chce přijímat peníze, aby vydělala na službě. Zaměstnanec chce ztratit minimum času na vyřizování s kavárnou, aby zbytečně neztrácel drahocenný čas. Jak to udělat? Platba předem nebo naopak po servisu na dálku. Nebo zaplaťte na místě pomocí kiosku. Co je na tom nejdůležitější? Kolik lidí je ochotno zaplatit za oběd bankovní kartou? Kolik lidí by této kantýně věřilo, že si uloží číslo karty pro opakované platby? Bez terénního výzkumu to není jasné, je potřeba testování.
V každém kroku procesu musíte nějakým způsobem poskytnout funkčnost; k tomu musíte vzít nějakou osobu jako základ a vybrat si, co je pro něj důležitější (stejné tři selektory). Sledoval jsem příběh až do konce = udělal schůdné řešení.
Následuje detailování. Klient chce vidět, jak je kavárna vytížená, aby se netlačil ve frontách. Co přesně chce?
Podívejte se na předpověď, kolik lidí tam bude za 15 minut, až tam dorazí
Prohlédněte si průměrnou dobu obsluhy v kavárně a její dynamiku půl hodiny předem
Podívejte se na situaci a dynamiku obsazenosti stolu
Co když předpovědní systém poskytne nejasný výsledek nebo přestane fungovat?
Sledujte prostřednictvím videa fronty v kavárně a také obsazenost stolů. Hmm, proč to neudělat jako první?!
Autorka upozorňuje na malý cvik k procvičování: zkuste si představit, co děláte ráno po probuzení. Jedna karta = jedna akce. Zvětšete karty (místo mletí kávy vypijte povzbuzující nápoj), abyste odstranili jednotlivé detaily, zaměřte se nikoli na způsob provedení, ale na cíl.
Pro koho je tato kniha: IT analytiky a projektové manažery. Povinná četba.
Aplikace
Diskuse a rozhodování jsou efektivní ve skupinách 3 až 5 osob.
Na první kartu napište, co je potřeba rozvinout, na druhou - opravte, co jste udělali na první, na třetí - opravte, co se udělalo na první a druhé.
Připravte si příběhy jako dorty – ne tak, že napíšete recept, ale zjistíte, pro koho, pro jakou příležitost a pro kolik lidí je dort určen. Pokud bychom rozebrali tržby, tak by to nebylo na výrobu dortů, krémů apod., ale na výrobu malých hotových dortů.
Vývoj softwaru je podobný jako natáčení filmu, kdy je potřeba pečlivě vyvinout a vypilovat scénář, zorganizovat scénu, herce atd., než začne natáčení.
Vždy bude nedostatek zdrojů.
20 % úsilí přináší hmatatelné výsledky, 60 % přináší nepochopitelné výsledky, 20 % úsilí je škodlivých – proto je důležité soustředit se na učení a nezoufat v případě negativního výsledku.
Komunikujte přímo s uživatelem, vnímejte se v jeho kůži. Zaměřte se na některé problémy.
Detailování a rozvíjení příběhu pro hodnocení je nejošklivější část skrumáže, diskuse udělejte v režimu akvária (3-4 lidé diskutují u tabule, pokud se někdo chce zúčastnit, někoho nahradí).
Zdroj: www.habr.com