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’attoreche 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.
Leggi tutti i nostri blog post di questa serie:
Project Management Agile: come scegliere il metodo adatto ai tuoi progetti? Leggi 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!
