Story-Split – B-agile

deci, este mai mult sau mai puțin o chestiune de gust dacă preferați o diagramă de caz de utilizare grafică sau o listă de povești de utilizator (textuale).

permiteți-mi să rezum discuția despre structurarea cerințelor în mare: Independent de notație o descompunere a unei mari probleme în procesul declanșat extern este cel mai neutru mod de a realiza această defalcare. Nu se bazează pe nicio structură internă a sistemelor (Nu funcțiile sale, nu subsistemele sale, nu obiectele sale, .,,) dar pur și simplu pe nevoile mediului.

asta nu înseamnă că celelalte strategii de descompunere menționate mai sus nu funcționează, ci doar o sugestie de a nu rămâne blocați în discuțiile structurale interne.

împărțirea în micul

după cum puteți vedea în exemplul simplu al sistemului de navigație de deasupra acestui proces (independent de notația pe care o preferați) pare încă prea complexă pentru a fi implementată într-o singură iterație. Cu siguranță trebuie să o împărțiți în bucăți mai mici. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) a sugerat multe modalități de a aborda bucăți mai mari și de a le împărți în povești suficient de mici pentru o iterație.

în timp ce metodele clasice au sugerat în principal să înțeleagă mai bine un proces complex, analizând secvența sa de pași, ne confruntăm acum cu o problemă suplimentară în lumea agilă: vrem să creăm valoare în fiecare iterație, adică să venim cu creșteri de produse potențial expedibile. Nu este suficient de bun pentru a descompune doar un proces mare (un caz de utilizare sau o poveste mare) pentru a înțelege mai bine. După descompunere, fiecare parte ar trebui să ofere o anumită valoare utilizatorului independent de celelalte părți.

aceasta inhibă divizările tehnice, cum ar fi împărțirea în straturile sale tehnice, cum ar fi interfața cu utilizatorul, funcționalitatea domeniului și stratul de persistență, deoarece implementarea stratului de persistență mai întâi (adică crearea unor tabele de baze de date) nu oferă nicio valoare de afaceri până când nu le puteți umple și afișa. Același lucru este adesea valabil și pentru descompunerea pură a proceselor de afaceri în etapele sale: implementarea doar a unui singur pas 7 al unui proces complex poate să nu ofere nicio valoare atâta timp cât pașii predecesori și succesori nu există.

(doar o remarcă istorică interesantă despre războaiele terminologice dintre metodologi: Mike Cohn s-a plâns că poveștile utilizatorilor nu sunt cazuri de utilizare pur și simplu folosind argumentul: pot fi prea mari pentru a le implementa într-o singură iterație. Ivar Jacobson a acceptat acest argument cu privire la dimensiune, dar accident vascular cerebral înapoi susținând că “felii de cazuri de Utilizare” sunt un mod mult mai bun de a gândi, apoi de a lucra cu povești de utilizator suficient de mici, deoarece felii de cazuri de utilizare oferă valoare end-to-end.)