Story-Splitting-b-agile

så det er mer eller mindre et spørsmål om smak om du foretrekker et grafisk bruksdiagram eller en liste over (tekstlige) brukerhistorier.

la meg oppsummere diskusjonen om strukturering krav i det store: Uavhengig av notasjon en nedbrytning av et stort problem i eksternt utløst prosess er den mest nøytrale måten å oppnå dette sammenbrudd. Det er IKKE basert på noen intern struktur av systemene (ikke dens funksjoner, ikke dens delsystemer, ikke dens objekter, .,,) men rent på behov fra miljøet.

Dette er ikke å si at de andre nedbrytningsstrategiene nevnt ovenfor ikke virker, men bare et forslag om ikke å bli sittende fast i interne strukturelle diskusjoner.

Splitting i den lille

som du kan se i det enkle eksempelet på navigasjonssystemet over denne prosessen (uavhengig av notasjonen du foretrekker) synes fortsatt å være for komplisert til å bli implementert i en iterasjon. Du må definitivt bryte den ned i mindre biter. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) foreslo mange måter å takle større biter og dele dem i historier som er små nok til en iterasjon.

mens klassiske metoder hovedsakelig foreslo å forstå en kompleks prosess bedre ved å se på trinnsekvensen, står vi nå overfor et ekstra problem i den smidige verden: vi ønsker å skape verdi i hver iterasjon, dvs. komme opp med potensielt shippable produktinkrementer. Det er ikke godt nok å bare dekomponere en stor prosess (et brukstilfelle eller en stor historie) for å forstå det bedre. Etter dekomponering skal hver del fortsatt levere noen verdi til brukeren uavhengig av de andre delene.

dette hemmer tekniske splittelser som splitting i sine tekniske lag som brukergrensesnitt, domenefunksjonalitet og persistenslag, siden implementering av persistenslaget først (dvs. å lage noen databasetabeller) ikke gir noen forretningsverdi før du kan fylle dem og vise dem. Det samme gjelder ofte for ren forretningsprosess dekomponering i trinnene: implementering av bare enkelt trinn 7 i en kompleks prosess kan ikke levere noen verdi så lenge forgjengeren og etterfølgertrinnene ikke er der.

(Bare en interessant historisk side bemerkning om terminologi kriger mellom metodologer: Mike Cohn klaget over at brukerhistorier ikke er brukstilfeller bare ved å bruke argumentet: de kan være for store til å implementere dem i en iterasjon. Ivar Jacobson aksepterte det argumentet om størrelse, men slår tilbake ved å hevde at “use cases slices” er en mye bedre måte å tenke på enn å jobbe med små nok brukerhistorier, siden use case slices leverer ende-til-ende-verdi.)