Story-Splitting-b-agile

Quindi, è più o meno una questione di gusti se si preferisce un diagramma grafico del caso d’uso o un elenco di storie utente (testuali).

Permettetemi di riassumere la discussione sui requisiti di strutturazione nel grande: Indipendente dalla notazione una decomposizione di un grosso problema in un processo attivato esternamente è il modo più neutro per ottenere questa ripartizione. NON si basa su alcuna struttura interna dei sistemi (non le sue funzioni, non i suoi sottosistemi, non i suoi oggetti,.,,) ma puramente sulle esigenze dell’ambiente.

Questo non vuol dire che le altre strategie di decomposizione sopra menzionate non funzionino, ma solo un suggerimento per non rimanere bloccati nelle discussioni strutturali interne.

Dividere nel piccolo

Come puoi vedere nel semplice esempio del sistema di navigazione sopra questo processo (indipendente dalla notazione che preferisci) sembra ancora troppo complesso per essere implementato in un’iterazione. Hai sicuramente bisogno di scomporlo in pezzi più piccoli. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) ha suggerito molti modi per affrontare pezzi più grandi e dividerli in storie abbastanza piccole per un’iterazione.

Mentre i metodi classici suggerivano principalmente di comprendere meglio un processo complesso osservando la sua sequenza di passaggi, ora stiamo affrontando un ulteriore problema nel mondo agile: vogliamo creare valore in ogni iterazione, cioè creare incrementi di prodotto potenzialmente spedibili. Non è sufficiente scomporre un grande processo (un caso d’uso o una grande storia) per capirlo meglio. Dopo la decomposizione, ciascuna parte deve comunque fornire un valore all’utente indipendentemente dalle altre parti.

Ciò inibisce le divisioni tecniche come la suddivisione nei suoi livelli tecnici come l’interfaccia utente, la funzionalità del dominio e il livello di persistenza, poiché l’implementazione del livello di persistenza prima (cioè la creazione di alcune tabelle di database) non fornisce alcun valore aziendale fino a quando non è possibile riempirli e visualizzarli. Lo stesso vale spesso per la decomposizione dei processi aziendali puri nei suoi passaggi: l’implementazione del solo passaggio 7 di un processo complesso potrebbe non fornire alcun valore finché non ci sono passaggi precedenti e successivi.

(Solo un’interessante osservazione storica sulle guerre terminologiche tra metodologi: Mike Cohn si è lamentato del fatto che le storie degli utenti non sono casi d’uso semplicemente usando l’argomento: potrebbero essere troppo grandi per implementarle in un’iterazione. Ivar Jacobson ha accettato questa argomentazione sulla dimensione, ma torna indietro sostenendo che le “sezioni dei casi d’uso” sono un modo molto migliore di pensare quindi lavorare con storie utente abbastanza piccole, poiché le sezioni dei casi d’uso forniscono un valore end-to-end.)