Convertire SRS tradizionali in User Story?

Molti progetti gestiti in modo tradizionale iniziano con una Software Requirements Specification (SRS). A un certo punto durante il progetto si decide di passare a un approccio agile. In questo caso sorge naturalmente la domanda se una SRS possa servire come nuovo Product Backlog agile. Alcuni team prendono addirittura in considerazione di riscrivere la SRS in un Product Backlog con User Story. Ma è davvero necessario?

Prima di affrontare questa domanda, vorrei spiegare brevemente cosa intendo con Requirements Specification o SRS. Ho notato che questi documenti possono variare molto da un’azienda all’altra. In linea di massima mi riferisco però a un tipico documento che contiene affermazioni come “Il sistema dovrebbe...”.

Il mio consiglio si adatta fondamentalmente a quasi tutti i documenti di specifica tradizionali. Questo vale per qualsiasi documento con requisiti integrati e numerati, indipendentemente dal fatto che tutte le affermazioni siano effettivamente formulate come “Il sistema dovrebbe...”.

Alcuni svantaggi nell’utilizzo di una SRS come Product Backlog

In un prodotto agile, il Product Backlog ha due compiti importanti:
- Serve come archivio per tutti i lavori da completare
- Facilita la prioritizzazione del lavoro

Il Product Backlog dice quindi a un team quali lavori devono essere svolti e può inoltre essere utilizzato come strumento di pianificazione per la sequenziazione del lavoro. Al contrario, una SRS tradizionale indica solo quali lavori devono essere svolti in un progetto.

Una SRS non mira né a scrivere requisiti che possano essere integrati in uno Sprint, né a prioritizzarli. Scrivere requisiti indipendenti è al massimo un obiettivo secondario, come si può notare dall’organizzazione gerarchica della maggior parte dei documenti SRS con i loro requisiti numerati (1.0, 1.1, 1.1.1 ecc.).

Finché una SRS viene vista come puro documento di requisiti, questo non crea alcun problema. Se però gli elementi di una SRS devono servire come Product Backlog Item ed essere prioritizzati, questo porterà a problemi.

Con una SRS spesso non è possibile per un team sviluppare il requisito 1.1.1 senza sviluppare contemporaneamente anche i requisiti 1.1.2 e 1.1.5. Queste dipendenze rendono tutto molto più difficile rispetto a scegliere e lavorare semplicemente una Story dopo l’altra da un Product Backlog ben elaborato.

La prioritizzazione degli elementi subordinati è altrettanto difficile in una SRS quanto l’identificazione delle funzionalità subordinate per la creazione di un Minimum Viable Product.

Una Software Requirements Specification è adatta come specifica dei requisiti. È adatta per rappresentare ciò che un sistema o prodotto dovrebbe fare. (Naturalmente non affronta tutti gli aspetti agili dei requisiti emergenti, della collaborazione, delle scoperte ecc. Presumo comunque che queste cose avvengano.)

Il mio consiglio sulle SRS nello Sprint

In linea di massima non consiglierei di investire tempo per riscrivere una SRS perfettamente funzionante. Certo, alla luce dei problemi appena citati potrebbe essere utile riscrivere la SRS in User Story e in un bel Product Backlog, ma nella maggior parte dei casi lo sforzo semplicemente non ne vale la pena.

Qualcuno dovrebbe prendersi il tempo per farlo, ma quella persona può normalmente utilizzare quel tempo in modo molto più sensato. Sconsiglio in particolare di riscrivere una SRS se altri membri del team dovessero aspettare il nuovo Product Backlog per poter iniziare a lavorare.

Lo Scrum Master o un altro membro del team deve trovare un modo per misurare i progressi anche con una SRS e assicurarsi che nessun requisito vada perso. Di solito è una buona idea coinvolgere il Quality Assurance per garantire che tutto nella SRS sia stato completato o inserito nel Backlog.

Inoltre è importante comunicare a chi è coinvolto nella creazione dei documenti SRS di farlo in futuro in un modo che sia più compatibile con Agile. Se ci riesci, nei prossimi progetti potrai evitare i problemi derivanti dalla discrepanza tra Agile e un documento SRS tradizionale.

Questo testo proviene dal blog di Mike Cohn ed è stato da noi tradotto in italiano.

Requisiti non funzionali

=> Scopri qui come trasformare i requisiti non funzionali in User Story.

Sprint Planning orientato al commitment

=> Qui scopri perché preferisco lo Sprint Planning orientato al commitment rispetto allo Sprint Planning orientato alla Velocity.