Story-Splitting-B-agile

så det er mere eller mindre et spørgsmål om smag, om du foretrækker et grafisk brugsdiagram eller en liste over (tekstlige) brugerhistorier.

lad mig opsummere diskussionen om strukturering af krav i det store: uafhængig af notation er en nedbrydning af et stort problem i eksternt udløst proces den mest neutrale måde at opnå denne sammenbrud på. Det er ikke baseret på nogen intern struktur af systemerne (ikke dens funktioner, ikke dens delsystemer, ikke dens objekter, .,,) men udelukkende på behov fra miljøet.

dette betyder ikke, at de andre nedbrydningsstrategier, der er nævnt ovenfor, ikke fungerer, men kun et forslag om ikke at sidde fast i interne strukturelle diskussioner.

opdeling i den lille

som du kan se i det enkle eksempel på navigationssystemet over denne proces (uafhængig af den notation, du foretrækker) synes stadig at være for kompleks til at blive implementeret i en iteration. Du skal helt sikkert bryde det ned i mindre bidder. Laurence (https://agileforall.com/resources/how-to-split-a-user-story/) foreslog mange måder at tackle større bidder og opdele dem i historier, der er små nok til en iteration.

mens klassiske metoder primært foreslog at forstå en kompleks proces bedre ved at se på dens rækkefølge af trin, står vi nu over for et yderligere problem i den smidige verden: vi ønsker at skabe værdi i hver iteration, dvs.komme med potentielt forsendelige produktforøgelser. Det er ikke godt nok bare at nedbryde en stor proces (en brugssag eller en stor historie) for at forstå det bedre. Efter nedbrydning skal hver del stadig levere en vis værdi til brugeren uafhængig af de andre dele.

dette hæmmer tekniske splittelser som opdeling i dets tekniske lag som brugergrænseflade, domænefunktionalitet og persistenslag, da implementering af persistenslaget først (dvs.oprettelse af nogle databasetabeller) ikke leverer nogen forretningsværdi, før du kan udfylde dem og vise dem. Det samme gælder ofte for ren forretningsprocesnedbrydning i dens trin: implementering af kun det enkelte trin 7 i en kompleks proces leverer muligvis ikke nogen værdi, så længe forgænger-og efterfølgertrin ikke er der.

(bare en interessant historisk side bemærkning om terminologi krige mellem metodologer: Mike Cohn klagede over, at brugerhistorier ikke er brugssager blot ved at bruge argumentet: de kan være for store til at implementere dem i en iteration. Ivar Jacobson accepterede dette argument om størrelse, men slår tilbage ved at hævde, at “brugssager skiver” er en meget bedre måde at tænke på, så man arbejder med små nok brugerhistorier, da brugssager skiver leverer ende-til-ende-værdi.)