Story-Splitting-b-agile

så det är mer eller mindre en smakfråga om du föredrar ett grafiskt användningsfallsdiagram eller en lista över (textliga) användarhistorier.

låt mig sammanfatta diskussionen om att strukturera krav i det stora: oberoende av notation en nedbrytning av ett stort problem i externt utlöst process är det mest neutrala sättet att uppnå denna uppdelning. Det är inte baserat på någon intern struktur av systemen (inte dess funktioner, inte dess delsystem, inte dess objekt, .,,) men rent på behov från miljön.

Detta är inte att säga att de andra nedbrytningsstrategierna som nämns ovan inte fungerar, men bara ett förslag att inte fastna i interna strukturella diskussioner.

delning i den lilla

som du kan se i det enkla exemplet på navigationssystemet ovanför denna process (oberoende av den notation du föredrar) verkar fortfarande vara för komplex för att implementeras i en iteration. Du måste definitivt bryta ner det i mindre bitar. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) föreslog många sätt att ta itu med större bitar och dela dem i berättelser som är tillräckligt små för en iteration.

medan klassiska metoder främst föreslog att förstå en komplex process bättre genom att titta på dess stegföljd, står vi nu inför ett ytterligare problem i den smidiga världen: vi vill skapa värde i varje iteration, dvs komma med potentiellt fraktbara produktsteg. Det är inte tillräckligt bra att bara sönderdela en stor process (ett användningsfall eller en stor historia) för att förstå det bättre. Efter sönderdelning ska varje del fortfarande leverera ett visst värde till användaren oberoende av de andra delarna.

detta hämmar tekniska splittringar som att dela upp i sina tekniska lager som användargränssnitt, domänfunktionalitet och persistenslager, eftersom implementeringen av persistenslager först (dvs. skapa några databastabeller) inte levererar något affärsvärde förrän du kan fylla dem och visa dem. Detsamma gäller ofta för ren affärsprocessnedbrytning i sina steg: att implementera bara det enda steget 7 i en komplex process kanske inte ger något värde så länge som föregångare och efterföljande steg inte finns där.

(bara en intressant historisk sidoanmärkning om terminologikrig mellan metodologer: Mike Cohn klagade över att användarhistorier inte använder fall helt enkelt genom att använda argumentet: de kan vara för stora för att implementera dem i en iteration. Ivar Jacobson accepterade det argumentet om storlek, men slår tillbaka genom att hävda att “användningsfallsskivorna” är ett mycket bättre sätt att tänka då man arbetar med tillräckligt små användarhistorier, eftersom användningsfallsskivor levererar end-to-end-värde.)