In Scrum, i requisiti vanno nelle storie degli utenti. Il proprietario del prodotto è responsabile della comunicazione con tutte le parti interessate e dei requisiti di raccolta. Generalmente non esiste alcun documento sui requisiti, né alcun rapporto generale sul progetto simile a quello che descrivi.
Una User story descriverà il requisito al più alto livello con una singola funzione con un formato regolare. "Come $ X voglio $ Y così posso $ Z". Ad esempio:
"As a legally-blind user I can magnify my screen so I can see small
screen elements"
Questa è la descrizione di alto livello che segue le tue note appiccicose (fisiche o metaforiche in uno strumento come Rally). Dopo di ciò, in genere dovresti inserire descrizioni più dettagliate e infine i "Criteri di accettazione". I criteri di accettazione sono i reali requisiti concreti. Di solito scrivo questo come un elenco puntato e queste sono le cose che devono essere vere perché il negozio sia considerato completo.
In teoria con agile, non si creano report con "cosa deve fare il sistema". Invece, tu, come Product Owner, prendi tutte le storie e mettile in primo piano. Poi, quando inizia lo sprint, la squadra punterà quelle storie e porterà quelle nello sprint che si adatterà e lavorerà a loro.
Alla fine dello sprint, mostri agli stakeholder cosa è stato fatto, scrivi nuove storie che devono essere scritte e ripetute. Rilasci al pubblico ogni volta che gli stakeholder pensano che il software sia pronto per il rilascio.
Va perfettamente bene per le parti interessate dire che hanno bisogno di un certo insieme di cose da rilasciare, ma ciò significa solo che quelle cose sono in gioco. L'intero punto di Agile è che queste cose possono essere cambiate durante il processo, tra gli sprint. Ciò significa che parlare troppo del progetto finale va contro il punto di vista di Agile. In quanto tale, un report che stai descrivendo non è qualcosa che sarebbe mai stato fatto su un progetto Agile.
Sono proprietario di un prodotto un team che utilizza Scrum e ciò che i nostri documenti a lungo termine sembrano sono generalmente elenchi di storie che descrivo. Non c'è mai stato un singolo documento che descrivesse il design. Al contrario, abbiamo diversi luoghi in cui le parti interessate elencano le funzionalità che desiderano vedere nella prossima versione sia nel nostro software PM che in un sistema simile a un wiki. Questi sono documenti viventi, che spesso cambiano fino a uno sprint prima del rilascio.
Come proprietario del prodotto, raccolgo sempre i requisiti. Il punto di Agile e Scrum è che i requisiti cambiano. Se raccogli i requisiti in una particolare "fase", i tuoi requisiti saranno obsoleti al momento del rilascio e quindi non soddisferanno le esigenze degli stakeholder.
Per riassumere, in Scrum:
- Non esiste un singolo documento che descriva il progetto scritto all'inizio.
- Ci sono molti documenti viventi che racchiudono i requisiti attuali
- Non esiste una fase particolare in cui vengono raccolti i requisiti
- I requisiti vengono sempre raccolti per la pianificazione dello sprint successivo
- Non saprai con certezza quali sono i requisiti effettivi da rilasciare fino al punto in cui i portatori di interesse dicono che il software è buono da rilasciare