Důvodů proč rozdělit UserStory může být hned několik.
Ten nejčastější je, že je moc velká a nevejde se do Sprintu. A protože základem Scrum procesu je pravidlo že tým vybere co během Sprintu dokončí a to na konci prezentuje zákazníkovi na customer demu, takovým UserStory které by dokončit nešly se musíme vyvarovat. Jak UserStory dělit? Po menších funkcionalitách. Nikdo neříká že takto rozdělěnou UserStory si zákazník musí nutně chtít koupit, ale jen že mu musí přinášet hodnotu. A ta je třeba i v tom, že si představí, co vlastně od dané funkčnosti chce. Tedy např. pakliže chce fakturace, asi si nekoupí jen readonly seznam faktur, ale bude je chtít i vytvářet a tisknout a filtrovat… ale jako mezivýsledek po prvním Sprintu mu hodnotu přinese i jen obyčejný seznam.
Druhým důvodem je různá priorita jednotlivých funkčních celků. Ono je to jedno spojeno s druhým. Když je UserStory moc velká, tak se obvykle Product Owner ptá, co jí dělá tak náročnou a komplexní. A přijde se obvykle na to, že udělat seznam faktur je snadné, ale tým ještě nikdy nedělal print preview a daná komponenta ho neumí a tedy je to pro ně náročné. Ono ale obvykle ne všechno je nutné a ne všechno stojí za tu cenu, kterou to má. A může se stát, že možnost print preview pro zákazníka vlastně nemá takovou priorotu a že ji odloží, na čas, či úplně.
Scrum vám umožňuje funkcionalitu řídit. Tím že složité celky musíte rozpadnout na menší kusy aby je tým stihnul v rámci Sprintu vás nutí přemýšlet o tom, jestli opravdu všechny drobné funkcionality potřebujete a jestli estimate odpovídá ceně, kterou jsme ochotni za očekávanou business value dané funkcionality v UserStory zaplatit.
Naučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
Dodávat pouze částečnou funkcionalitu většího celku může být dost riziková záležitost. Zákazníkovi se může pomíchat “nedokončená” a “špatná” funkcionalita a nepříjemnosti jsou na světě.
Často používáme prototypování, abychom co nejdříve odhalili rozpory se specifikací a s potřebami zákazníka. Prototyp ale nikdy nedodáváme jako součást produkční verze. Z Vašeho příspěvku jsem pochopil, že částečná funkcionalita je součástí produkčního vydání. Rozsáhlejší úpravy vyvíjíme přes více iterací a máme obvykle vlastní vývojovou větev.
Zdravim, dik za komentare.
Tak jsem to rozhodne nemyslela. “spatna” funkcionalita asi nepatri ani na demo… a “nedokoncena” no ono to zalezi na tom jak ten pojem definujeme a co si pod nim predstavime: seznam zamestnancu muze jit do produkce i bez jejich fotek a seznamu skoleni – ty se pridaji nektery z dalsich Sprintu, nicmene neco co neni konzistentni a je jen prototyp jiste casti by asi byt online nemel… ale to hodne zalezi na tom konkretnim produktu…