Story-Splitting-b-agile

dus, het is min of meer een kwestie van smaak of u liever een grafisch use case diagram of een lijst van (tekstuele) gebruikersverhalen.

laat me de discussie over structureringsvereisten in de grote samenvatten: onafhankelijk van de notatie is een ontleding van een groot probleem in extern getriggerd proces de meest neutrale manier om deze uitsplitsing te bereiken. Het is niet gebaseerd op een interne structuur van de systemen (niet zijn functies, niet zijn subsystemen, niet zijn objecten, .,,) maar puur op de behoeften van het milieu.

dit wil niet zeggen dat de andere hierboven genoemde afbraakstrategieën niet werken, maar slechts een suggestie om niet vast te komen te zitten in interne structurele discussies.

splitsen in de kleine

zoals u kunt zien in het eenvoudige voorbeeld van het navigatiesysteem hierboven lijkt dit proces (onafhankelijk van de notatie die u verkiest) nog steeds te complex om in één iteratie te worden geïmplementeerd. Je moet het zeker opsplitsen in kleinere brokken. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) stelde veel manieren voor om grotere brokken aan te pakken en te verdelen in verhalen die klein genoeg zijn voor één iteratie.

terwijl klassieke methoden voornamelijk suggereerden om een complex proces beter te begrijpen door te kijken naar de volgorde van de stappen, worden we nu geconfronteerd met een extra probleem in de agile wereld: we willen waarde creëren in elke iteratie, dat wil zeggen met potentieel shippable product increments komen. Het is niet goed genoeg om gewoon ontbinden van een groot proces (een use case of een groot verhaal) om het beter te begrijpen. Na ontbinding moet elk van het onderdeel nog steeds enige waarde leveren aan de gebruiker onafhankelijk van de andere delen.

dit remt technische splitsingen zoals splitsen in technische lagen zoals gebruikersinterface, domeinfunctionaliteit en persistence layer, aangezien het eerst implementeren van de persistence layer (dat wil zeggen het creëren van een aantal databasetabellen) geen bedrijfswaarde levert totdat u ze kunt vullen en weergeven. Hetzelfde geldt vaak voor pure business process decompositie in zijn stappen: het implementeren van slechts de enkele stap 7 van een complex proces kan geen waarde leveren zolang voorganger en opvolger stappen er niet zijn.

(een interessante historische kanttekening over terminologieoorlogen tussen methodologen: Mike Cohn klaagde dat gebruikersverhalen geen use cases zijn door simpelweg het argument te gebruiken: ze kunnen te groot zijn om ze in één iteratie te implementeren. Ivar Jacobson aanvaard dat argument over de grootte, maar beroerte terug door te beweren dat de “use cases slices” zijn een veel betere manier van denken dan het werken met kleine genoeg gebruiker verhalen, omdat use case slices leveren end-to-end-waarde.)