Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : MA: Mapování user stories
MA: Mapování user stories
Kód úlohy

Standardní kód úlohy v MBI.

:
U466G
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Franek, O. (etnetera)
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.3
Charakteristiky úlohy

Charakteristiky úlohy

1. Obsah úlohy
  • V agilních metodikách jsou požadavky ve formě user stories obvykle řazeny do prioritizovaného seznamu , který se nazývá backlog . Nevýhodou jednorozměrného produktového backlogu je obtížné sestavování verzí aplikace tak, aby byla hodnotná a použitelná.
  • Klasický jednorozměrný nebo také plochý backlog obsahuje jednotlivé stories seřazené za sebou podle priority. Při plánování použitelné verze aplikace ale obvykle nestačí zkombinovat jen prioritní požadavky. Aby byl produkt funkční, je občas potřeba zařadit i ty méně podstatné.
2. Účel mapování user stories
  • Mapování user stories je technika , která vnáší přehled do práce s požadavky ve formě user stories. Jejím autorem je Jeff Patton (2014). User story mapping je skupinová technika , kterou provádí tým tvorbou produktového backlogu. Podobně jako user story klade i tato technika velký důraz na konverzaci mezi členy týmu.
  • Vizuální prezentace produktového backlogu pomáhá všem členům týmu pochopit rozsah a komplexitu produktu. Tato technika ale není určena jen pro nové produkty, ale i pro rozšíření existujících produktů. Pomocí story mapy je tedy možné vizualizovat backlog celého produktu nebo jen jedné funkce . Mezi výhody story mappingu patří (Parekh 2015):
    • Budování sdíleného porozumění v projektovém týmu,
    • Identifikace slepých míst v produktovém backlogu,*
  • Odhalení závislostí mezi jednotlivými částmi produktu,
    • Jednodušší krájení backlogu a plánování verzí.
3. Anatomie user story mapy
  • Story mapa se skládá z jednotlivých uživatelských úkolů , které jsou organizovány formou matice. Jednotlivé uživatelské příběhy by ideálně měly vycházet ze struktury user stories. Jednotlivé úkoly jsou na mapě seřazeny zleva doprava podle toho, jak na sebe navazují v životním cyklu uživatele aplikace .
  • Pořadí jednotlivých uživatelských úkolů reprezentuje příběh uživatele v používání produktu . Mapa by neměla popisovat pouze ideální průchod ideálního uživatele, ale měla by zachytit i méně časté scénáře . Detaily, alternativy a variace vyplňují tělo mapy směrem dolů pod aktivitami. Páteř celé mapy tvoří aktivity neboli úkoly na vysoké úrovni (high-level tasks).
  • Aktivity organizují mapu vertikálně – sdružují pod sebe podobné úkoly, které vedou k dosažení podobného cíle. Mapa je dále rozdělena horizontálně podle priorit . Úkoly, které výrazně přispívají k dosažení dílčího cíle, mají vyšší prioritu než méně významné úkoly.
  • První verze produktu by podle Pattona (2014) měla být experiment , ten následují další experimenty, dokud nenajdeme ten pravý produkt. Minimální životaschopné řešení je nejmenší možná verze aplikace, která úspěšně povede k dosažení stanoveného výsledku. Mapování stories pomáhá sestavit produkt, který od své první verze obsahuje funkce, které zadavatel požaduje, a zároveň je použitelný pro uživatele.
4. Proces mapování user stories
  • Proces mapování stories se skládá z několika navazujících kroků . Měli by se do něj zapojit zástupci všech zúčastněných stran – vývojáři, designeři, analytici, testeři, zástupci zákazníka a uživatelů:
    • Zarámování - před zahájením mapování produktu je vhodné připravit základní artefakty, pomocí kterých produkt představíme účastníkům aktivity. Pro základní informace o produktu úplně stačí Lean Canvas, Nositelem informací o uživatelích a dalších zúčastněných stranách jsou persony. Cílem tohoto kroku je představit účastníkům základní myšlenku a nezahlcovat je zbytečnými detaily,
    • Zmapování základní kostry produktu - po představení produktu může začít samotné mapování. Cílem tohoto kroku je zmapovat základní průchod uživatele aplikací a vytvořit tak páteř mapy. Úkoly tvořící páteř mapy, které spolu souvisí, tým následně sdruží do aktivit. Jeff Patton doporučuje začít s nejdůležitějším uživatelem, tedy s primární personou. Po zmapování průchodu primárního uživatele tým identifikuje způsoby, jakými produkt používají další persony,
    • Průzkum - rozpad větších úkolů na menší, další detaily a alternativy. Cílem je zmapovat všechny možnosti, kterými se produkt může ubírat a najít prázdná místa, kde část příběhu uživatele chybí. Tento krok je velmi podobný aktivitě brainstorming a má podobná pravidla – cílem je vyprodukovat větší množství požadavků, které budou v dalším kroku prioritizovány,
    • Nakrájení možných verzí produktu - z doposud identifikovaných požadavků sestavit jednotlivé verze produktu. Jednotlivé řádky mapy tvoří inkrementální plán produktu, ve kterém každá verze představuje minimální životaschopné řešení (minimum viable product). U každé verze tým popíše i její cíl, aby bylo zřejmé, jakým způsobem přispívá k dosažení dlouhodobé vize produktu, a způsob, jakým dosažení tohoto cíle změří,
    • Rozfázování vývoje v rámci verze - tým vývojářů, designerů a testerů připraví plán vývoje první verze aplikace, případně první verze prototypu. Strategie vývoje by měla vycházet z principů iterativního vývoje.
5. Poznámky, reference:
  • Franek, O. (etnetera): Proces tvorby zadání a správy požadavků pro vývoj mobilní aplikace, VŠE, Praha. 2018,
  • PATTON, Jeff, 2014. User story mapping: discover the whole story, build the right product. First edition. Beijing , Sebastopol, CA: O’Reilly. ISBN 978-1-4919-0490-9.