Due tecniche per identificare i requisiti del tuo progetto #agile

Mercoledì Agile è la nuova rubrica del nostro blog: ogni mercoledì troverete delle piccole pillole di project management agile, per percorrere insieme i punti più importanti dell’approccio agile nella gestione dei progetti.
Se da un lato agile può aiutarvi ad affrontare i cambiamenti e l’incertezza, a migliorare la probabilità di successo dei vostri progetti, è anche vero che l’adozione di agile non è sempre facile e veloce: settimana per settimana, cercheremo di supportarvi!

I progetti Agile hanno l’obiettivo di comprendere e facilitare il cambiamento. Per questo in un progetto Agile è fondamentale, partendo da un bisogno corrente di business, identificare e documentare le necessità o requisiti (requirement).

Abbiamo visto che durante la fase speculate si utilizzano i cartoncini per documentare le feature. Ma quali sono gli approcci e tecniche per documentare le feature e i requisiti?

Un’ottima tecnica consiste nell’avere un business analyst che sia in anticipo rispetto all’agile development team di uno o due sprint.
Mentre il core team lavora ad uno sprint, il business analyst dovrebbe guardare avanti per assicurare che la lista di feature per lo sprint successivo sia stata chiaramente stabilita con il business. Inoltre, se i bisogni del business sono cambiati, il business analyst può lavorare alla definizione di nuove feature o identificare feature nel backlog che non sono più necessarie.
Ci sono diverse tecniche per identificare i requisiti, eccone due:

1. Use case
Gli use case (o casi d’uso) catturano in un diagramma o immagine la relazione tra un attore e il sistema o processo utilizzato per raggiungere un determinato obiettivo.
Un attore può essere una persona, un’azienda, un dipartimento, un programma del computer o un sistema, insomma qualsiasi entità che possa prendere una decisione. Gli use case possono essere utilizzati per documentare i requisiti di progetti IT o non-IT.
I componenti chiave di uno use case sono: l’attore che esegue l’evento, il sistema o processo con il quale l’attore interagisce, il quadro totale, il box che rappresenta i limiti per il requisito.
Qualsiasi altra cosa al di fuori di questo box è “out of scope”. Tutto quello che è all’interno del box indica tutti i tipi di azione che l’attore può fare col sistema. Tutto ciò che è all’esterno mostra i vari attori esterni che possono interagire con il sistema.
L’utilizzo di use case può aiutare gli stakeholder a immaginare tutti i modi possibili in cui un requirement potrà soddisfare i bisogni di business attraverso le feature.

2. Performance requirement card
Le performance requirement card sono simili alle feature card, ma descrivono un requisito che è applicabile a più feature. Ogni requisito avrà bisogno di avere un’identificazione unica, nome o titolo insieme a una breve descrizione. Nella card vengono inseriti:
– il fattore complessità (basso, medio, alto) che può aiutare il business nel prioritizzare il requisito rispetto ad altri requisiti o feature
– una sezione accettabilità che descrive come verificare che il requisito sia stato soddisfatto una volta che il prodotto è stato sviluppato.

Documentare i requisiti è essenziale per ogni progetto. Nel tuo progetto Agile le necessità e quindi i requisiti evolveranno continuamente. Avere un business analyst che lavora in anticipo rispetto al core team ti aiuterà ad essere pronto/a ad ogni sprint con feature rilevanti per il tuo business e informazioni sui requisiti.

Continua…

Hai perso gli altri blog post della serie? Mercoledì Agile – INTRO, 5 caratteristiche di un progetto Agile di successo, Il ciclo di vita di un progetto Agile, La prima fase del tuo progetto agile, Documentazione agile: minima ma fondamentale!, 3 consigli per pianificare gli sprint del tuo progetto agile, La seconda fase del tuo progetto agile

Project Management Agile: come scegliere il metodo adatto ai tuoi progetti? Scoprilo scaricando gratuitamente l’articolo del nostro formatore Fabio Savarino!

Cerchi un metodo che coniughi gli standard, il rigore e la visibilità del project management tradizionale con la velocità nel cambiamento fornita da Agile? Scopri la Metodologia AgilePM!