Analisi del software con la tecnica delle 3C: le User Story

Ascolta “Analisi del software con la tecnica delle 3C: le User Story” su Spreaker.

L’interazione continua con il cliente è una componente fondamentale nell’utilizzo delle metodologie Agili per la produzione del software. Fin dall’inizio del progetto, nel metodo Agile, si opera una definizione dei requisiti attraverso frequenti riunioni cui partecipa sia il team di lavoro, sia il cliente. Tali riunioni hanno il duplice scopo di definire in modo incrementale le funzionalità del prodotto e di concordare le priorità di rilascio.

Negli ultimi vent’anni il processo di analisi del software è mutato da estese documentazioni al ricorso a espedienti narrativi che vedono il software con gli occhi dell’utente finale. La redazione del gantt di progetto, con il ricorso alle metodologie Agile, predilige come strumento di comunicazione tra il team ed il cliente le User Story.

La tecnica, piuttosto semplice da utilizzare, vede in prima battuta la redazione di stories con un livello di dettaglio molto basso e, solo successivamente, l’arricchimento delle User Story con dettagli sempre più simili ai requisiti.

Ron Jeffries, uno dei tre fondatori della metodologia di sviluppo del software Extreme Programming, descrive le fasi successive di questa tecnica con l’acronimo 3C: Card, Conversation e Confirmation.

Fase Card

La fase Card contiene la descrizione sommaria delle funzionalità da realizzare. Una moltitudine di brevi frasi sono assimilabili a tanti piccoli episodi che si aprono e si chiudono assai velocemente.

Tale approccio consente al cliente di comprendere facilmente la funzionalità come va delineandosi, ma consente anche un notevole feedback da parte sua lasciando il dovuto spazio alla conversazione.

Un requisito della funzionalità negoziato in tale maniera diventa una proposta dalla quale possono originarsi ulteriori idee. Si descrivono le necessità del cliente con un’ampia visione palesando così i vantaggi per l’utente, ma rimandando a un secondo momento il dettaglio implementativo, evitando al cliente di definire le specifiche nella loro interezza fin dall’inizio.

Interessanti sinergie possono svilupparsi mediante ricorso a tale tecnica proprio grazie alla condivisione delle funzionalità con tutto il team; in tal modo è possibile che altri componenti del team ravvisino funzionalità simili a quelle già oggetto di analisi. Un gruppo di più User Story simili tra loro, viene definita Epic.

Fase Conversation

Successivamente alla fase Card, si entra nel merito delle funzionalità con un maggiore livello di dettaglio in modo da dirimere ogni ambiguità per il tecnico. L’interazione con il cliente avviene allorquando ci si trova in possesso delle informazioni necessarie a identificare il livello di dettaglio derivante dai dati e non più dalle previsioni, che sovente si rivelano errate.

La User Story viene articolata in task assegnati a specifici membri del team. Per fare questo, i tecnici forniscono stime e comunicano le conseguenze delle scelte che vengono intraprese nel realizzare le funzionalità richieste, mentre il cliente definisce la priorità rispetto alle schede di lavorazione che il team di tecnici è in grado di prendere in carico per quella iterazione.

Fase Confirmation

Siamo infine alla fase di Confirmation quando, congiuntamente con il cliente, si definisce il termine del lavoro.

L’Extreme Programming prevede che sia il cliente a determinare il completamento di una funzionalità e a decretarne l’accettazione in fase di Confirmation. Una funzionalità si ritiene completata quando il test preventivamente concordato e predisposto con il cliente ha avuto esito positivo. È proprio per questo che, nell’Extreme Programming, la predisposizione dei test costituisce una parte fondamentale del processo.

La prima tecnica formulata in Extreme Programming è stata la Acceptance Test Driven Development (A-TDD) nella quale lo sviluppo è guidato dai test di accettazione scritti con il cliente. Tale tecnica si è nel tempo evoluta con la Specification By Example (SBE) con la quale si procede scrivendo piccoli esempi delle funzionalità da realizzare e con la Behavior Driven Design (BDD) cioè con lo sviluppo guidato dai comportamenti dell’utente.

Bibliografia

• DevOps Guida per integrare Development e Operations e produrre software di qualità, Fabio Mora
• User Stories Applied: For Agile Software Development, Mike Cohn