Story-Splitting-b-agile

takže je víceméně otázkou vkusu, zda dáváte přednost grafickému diagramu případů použití nebo seznamu (textových) uživatelských příběhů.

dovolte mi shrnout diskusi o požadavcích na strukturování ve velkém: nezávisle na notaci je nejutrálnějším způsobem, jak tohoto členění dosáhnout, rozklad velkého problému do externě spouštěného procesu. Není založen na žádné vnitřní struktuře systémů (ne jeho funkce, ne jeho subsystémy, ne jeho objekty, .,,) ale čistě na potřeby z prostředí.

to neznamená, že ostatní výše uvedené strategie rozkladu nefungují, ale pouze návrh, aby se nezachytil ve vnitřních strukturálních diskusích.

rozdělení v malém

jak můžete vidět na jednoduchém příkladu navigačního systému nad tímto procesem (nezávisle na notaci, kterou preferujete) se stále zdá být příliš složité na to, aby bylo možné implementovat v jedné iteraci. Určitě ji musíte rozdělit na menší kousky. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) navrhl mnoho způsobů, jak řešit větší kousky a rozdělit je do příběhů, které jsou dostatečně malé na jednu iteraci.

zatímco klasické metody navrhly hlavně lépe porozumět složitému procesu při pohledu na jeho posloupnost kroků, nyní čelíme dalšímu problému v agilním světě: chceme vytvářet hodnotu v každé iteraci, tj. přijít s potenciálně přepravitelnými přírůstky produktu. Nestačí jen rozložit velký proces (případ použití nebo velký příběh)pro lepší pochopení. Po rozkladu by každá část měla uživateli dodat určitou hodnotu nezávislou na ostatních částech.

to brání technickým rozdělením, jako je rozdělení do technických vrstev, jako je uživatelské rozhraní, funkčnost domény a vrstva persistence, protože implementace vrstvy persistence nejprve (tj. vytvoření některých databázových tabulek) nepřináší žádnou obchodní hodnotu, dokud je nebudete moci vyplnit a zobrazit. Totéž často platí pro čistý rozklad obchodních procesů do jeho kroků: implementace pouze jediného kroku 7 složitého procesu nemusí přinést žádnou hodnotu, pokud neexistují kroky předchůdce a nástupce.

(jen zajímavá historická poznámka o terminologických válkách mezi metodiky: Mike Cohn si stěžoval, že uživatelské příběhy nejsou případy použití jednoduše pomocí argumentu: mohou být příliš velké pro jejich implementaci v jedné iteraci. Ivar Jacobson přijal tento argument o velikosti, ale tah zpět tím, že tvrdí, že “řezy případů použití” jsou mnohem lepší způsob myšlení, než pracovat s dostatečně malými uživatelskými příběhy, protože řezy případů použití poskytují end-to-end-hodnotu.)