Business Analyst e Project Manager

La metodologia SCRUM sta rivoluzionando il modo di operare nell’industria dello sviluppo software per restare allineati al veloce sviluppo tecnologico. Sembra facile adottare nuove procedure, ma in realtà cosa accade per migrare dal’approccio a cascata (Waterfall) all’approccio Agile (SCRUM)? In certi ambienti il passaggio può diventare molto traumatico se non affrontato nel verso giusto.

Il primo paradigma da comprendere e governare è il ruolo che giocano gli “USE CASES”.

Con l’approccio Waterfall il ciclo dello sviluppo software è molto lungo e, non essendo iterativo, è necessario per prima cosa raccogliere tutti i requisiti, producendo un sacco di documentazione di dettaglio preventivamente.

La metodologia Waterfall prevede la formalizzazione di tutti i requisiti prima di avviare lo sviluppo, per ridurre il rischio con la fornitura di tutti i dettagli possibili. Con l’evoluzione delle nuove tecnologie, sta diventando impossibile conoscere tutti i dettagli dei requisiti in anticipo.

L’approccio Agile, invece, consente di catturare e comprendere i dettagli gradualmente nel corso dello sviluppo dell’intero progetto software, dando all’utente la possibilità di adeguare i requisiti all’evoluzione tecnologica. La filosofia “Agile” è che non c’è bisogno di raccogliere tutti i requisiti per sviluppare un prodotto.

• Una istanza, detta “USE CASES” con l’approccio tradizionale, è un documento dettagliato che specifica il ruolo dell’utente ed il ruolo del sistema nel software da sviluppare.
• Una “USE STORIES” è una breve spiegazione di una funzionalità dell’applicazione software dal punto di vista dell’utente soltanto. Spesso, diventa difficoltoso per Business Analyst e Project Manager dare il giusto valore al backlog di prodotto e ricavare i requisiti dalle User Stories.

Durante la transizione da “Use Cases” a “User Stories”, senza la giusta mentalità, alcuni credono sempre di non disporre di informazioni sufficienti. In realtà, i due approcci hanno molte cose in comune.

Componenti

• Una “Use Case” contiene un attore, un flusso e delle condizioni.
• Una “User Story” contiene gli stessi componenti con ruolo dell’utente, giustificazione e rispettivi criteri di accettazione. I dettagli vengono discussi apertamente con gli stakeholder durante le varie riunioni di rito dell’approccio Agile prescelto. Alcune informazioni tecniche di base devono essere documentate, ma quelle specifiche fanno parte di altri documenti.

Vediamo un breve confronto dei componenti nei due approcci:

Componenti della USE CASE	Componenti della USER STORY
Use Case Titolo Descrizione Ambito Schema Diagramma Attori Precondizioni Flusso base Descrizione, Soglie, Passi Flussi alternativi Descrizione, Passi Post condizioni Specifiche speciali Punti di estensione	Come Utente (ruolo utente) io voglio (goal) in modo da poter (giustificazione) Criteri di Accettazione (condizioni di soddisfazione che rilasciano il valore atteso) Componenti simili nei due approcci Attori o Ruolo Utente Flusso base o Goal e Giustificazione Post condizioni o Criteri di accettazione

Quali sono le vere differenze?

Timing

• Con l’approccio tradizionale , una Use Case richiede il coinvolgimento di più persone per raccogliere tutte le informazioni tecniche.
• Con l’approccio Agile , una User Story può essere scritta e modificata durante uno “sprint” – il ciclo di lavorazione delle User Stories. In pratica, il “Product Owner”, l’utente finale o entrambi possono creare una User Story, anche se sarà poi necessario un Business Analyst o un esperto della materia per scrivere i dettagli, rubando tempo alle attività di codifica e test.

Dettagli

• Le Use Case contengono informazioni molto dettagliate comprensibili agli sviluppatori o tecnici membri del team. Se ci sono cambiamenti durante lo sviluppo, un Business Analyst aggiorna i documenti impattati.
• Con le User Stories, le specifiche sono scritte a livello alto in modo che tutti i partecipanti possano comprenderle, a prescindere dalle conoscenze tecniche. L’aspettativa è che gli sviluppatori possano scrivere del codice per creare le funzionalità richieste dall’utente finale, invece di preoccuparsi dei limiti del sistema. Le User Stories consentono alle persone senza esperienza tecnica di comprendere l’evoluzione delle funzionalità in sviluppo, ignorando i dettali tecnici del sistema.

Scopo

• Le Use Case vengono scritte con particolare attenzione al comportamento del prodotto.
• Le User Stories vengono scritte dalla prospettiva delle esigenze dell’utente. Il beneficio è che il team tecnico è connesso direttamente con l’utente. Gli sviluppatori comprendono perché stanno sviluppando una funzionalità correlata direttamente ai principi del Manifesto Agile. La base di una User Story è consentire al team SCRUM e agli stakeholder di dialogare in modo aperto e produttivo, creando un ambiente molto collaborativo, dove i partecipanti sono tutti coinvolti nel fornire chiarimenti.

Management

• Le Use Case vengono gestite attraverso un archivio di documenti, dove ogni funzionalità è rappresentata da uno specifico documento. Poiché i documenti sono tanti, ci possono essere anche molti riferimenti da un documento ad un altro per i dettagli.
• Le User Stories vengono raggruppate insieme per creare il backlog di un prodotto, contenuto in un solo sistema di archiviazione, generalmente un tool di gestione dei requisiti. Le dipendenze vengono mappate facilmente e la definizione delle priorità, il tracciamento e le metriche possono essere effettuate velocemente attraverso tool più o meno sofisticati. Creando e gestendo un backlog di prodotto, il resto della metodologia Agile può essere portata avanti con molto meno complessità. Quando un team non può o non vuole trasformare requisiti documentati come Use Case in User Stories, le fasi successive della prassi Agile possono diventare complicate e difficili da implementare. Così, il backlog di prodotto composto di User Stories è uno dei fondamentali dell’implementazione Agile.

Comunicazione

• Le User stories sono la base della comunicazione tra il team SCRUM e lì’utente finale o gli stakeholder. I dettagli di una User Story generalmente vengono discussi apertamente tra team e stakeholder durante la riunione di “Backlog Grooming” o “Sprint Plannng” (bisogna acquisire questa nuova terminologia per evitare equivoci sulla fase del processo Agile in corso). Queste discussioni consentono all’intero gruppo di fare domande l’un l’altro per comprendere le esigenze di entrambe le parti. La discussione avviene in un linguaggio che consenta a tutti di partecipare attivamente. Invece, le Use Cases vengono create ed aggiornate in modo meno collaborativo e con più formalità.

Generalmente, il Business Analyst raccoglie le informazioni attraverso discussioni con lo sviluppatore software. Successivamente, i vari documenti vengono aggiornati man mano che arrivano richieste di cambiamento o quando si scoprono nuove dipendenze.

Sintesi delle differenze tra User Story e Use Case

USER STORY	USE CASE
Sintesi del lavoro da svolgere In base alle esigenze dell’Utente Concise e facili da leggere Utente, Stakeholder e Team SCRUM Focus sul valore per il cliente Favorire la collaborazione tra stakeholder e team di sviluppo	Elenco di passi In base al comportamento del software Descrizione molto dettagliata del comportamento dell’utente e del sistema e potenziali terze parti Prospettiva delle interazione tra utente e sistema Da rifinire successivamente con maggiori dettagli di analisi e disegno

Conclusione

Avendo chiaro come funzionano le User Stories, la transizione da Use Case può essere molto meno problematica. Bisogna comprendere che le informazioni non vengono perse o tralasciate, anche se le informazioni non sono documentate in dettaglio, inizialmente. Una volta accettati questi pochi principi, la transizione diventa più agevole. Il team può utilizzare qualsiasi metodo di gestione dei requisiti, purché comprenda i pro ed i contro. Per una metodologia Agile, basta creare un backlog di User Stories per essere facilmente più produttivi.

Certificazioni da Business Anayst