Story-spliting-b-agile

tehát többé-kevésbé ízlés kérdése, hogy inkább egy grafikus Használati esetdiagramot vagy a (szöveges) felhasználói történetek listáját részesíti előnyben.

hadd foglaljam össze a vita strukturálása követelmények a nagy: független jelölés bomlása egy nagy probléma a külsőleg kiváltott folyamat a leginkább semleges módon elérni ezt a bontást. Nem a rendszerek belső struktúráján alapul (nem a funkciói, nem az alrendszerei, nem az objektumai, .,,), hanem pusztán a környezeti igényekre.

ez nem azt jelenti, hogy a fent említett többi bomlási stratégia nem működik, hanem csak egy javaslat arra, hogy ne ragadjunk bele a belső strukturális vitákba.

felosztása a kis

mint látható az egyszerű példa a navigációs rendszer fenti folyamat (független a jelölést szeretne) még mindig úgy tűnik, hogy túl bonyolult kell végrehajtani egy iteráció. Mindenképpen kisebb darabokra kell bontania. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) számos módszert javasolt a nagyobb darabok kezelésére, és olyan történetekre osztására, amelyek elég kicsik egy iterációhoz.

míg a klasszikus módszerek elsősorban egy összetett folyamat jobb megértését javasolták a lépések sorrendjének áttekintésével, most egy további problémával állunk szemben az agilis világban: értéket akarunk teremteni minden iterációban, azaz potenciálisan szállítható terméknövekményekkel. Nem elég jó egy nagy folyamat (használati eset vagy nagy történet) lebontása a jobb megértés érdekében. A bomlás után az egyes részeknek továbbra is valamilyen értéket kell adniuk a felhasználónak, függetlenül a többi alkatrésztől.

ez gátolja a technikai felosztásokat, például a technikai rétegekre, például a felhasználói felületre, a tartomány funkcionalitására és a perzisztencia rétegre való felosztást, mivel a perzisztencia réteg első megvalósítása (azaz néhány adatbázis-tábla létrehozása) nem eredményez üzleti értéket, amíg meg nem tudja tölteni és megjeleníteni őket. Ugyanez gyakran igaz a tiszta üzleti folyamatok szakaszokra bontására is: egy összetett folyamat egyetlen 7.lépésének végrehajtása nem biztos, hogy értéket eredményez, amíg az előző és az utódlépések nincsenek ott.

(csak egy érdekes történelmi megjegyzés a metodológusok közötti terminológiai háborúkról: Mike Cohn panaszkodott, hogy a felhasználói történetek nem használati esetek, egyszerűen az érv használatával: túl nagyok lehetnek ahhoz, hogy egy iterációban megvalósítsák őket. Ivar Jacobson elfogadta ezt az érvet a méretről, de a “használati esetek szeleteinek” követelésével sokkal jobb gondolkodásmód, mint az elég kicsi felhasználói történetekkel való munka, mivel a használati esetek szeletei végpontok közötti értéket nyújtanak.)