Come funziona la gestione dei requisiti a lungo termine con i progetti Agile?

La gestione dei requisiti a breve termine per i progetti Agile mi sembra un problema risolto.

Dal punto di vista Scrum, i nuovi requisiti o le modifiche ai requisiti esistenti vengono forniti tramite User Story. E le User Story raggruppate in Epic o Feature facilitano la consegna di requisiti più grandi e complessi.

Naturalmente, una User Story non è tecnicamente un documento di requisiti. È un raggruppamento gestibile di lavoro che si associa a quella che viene spesso definita una fetta verticale di funzionalità. E la portata di queste storie può essere definita in modo inequivocabile attraverso l'uso di Acceptance Criteria (AC).

Quindi, sebbene le User Story non siano requisiti formali, la navigazione attraverso di esse può darti un'idea abbastanza chiara dei requisiti sottostanti. A breve termine.

Dico a breve termine perché, man mano che il progetto avanza, aumenta il numero di User Story. Pertanto, sfogliare un elenco sempre crescente di storie per trovare un requisito diventa sempre meno efficiente nel tempo.

Questo problema si aggrava quando si considerano le storie utente che si espandono, si sostituiscono o addirittura si annullano le storie precedenti.

Ora, immagina un divario di 2 anni tra iterazioni di sviluppo su un progetto (stabile nella produzione). La squadra originale è sparita e così è tutta la loro conoscenza.

Se il team originale sapeva che sarebbe successo (ad esempio, è la natura del business), quali misure potrebbero adottare per aiutare i team successivi?

Certo, il backlog fornirà alcune informazioni, ma difficilmente è in una forma facilmente navigabile.

Quindi, cosa si può fare per aiutare i team successivi a capire lo stato del progetto, incluso perché e come è arrivato?

Nella mia esperienza, le seguenti cose non funzionano:

• Pulizia del backlog per eliminare o aggiornare le User Story precedenti in modo che il Backlog possa essere letto come un documento di requisiti.
• Documentazione Sprint in cui i membri del team hanno il compito di documentare lo stato corrente del sistema.
• Documentazione tramite test comportamentali . Questo approccio è l'unico che ho visto avvicinarsi al lavoro. Sfortunatamente, i test di comportamento in codice sono vittime del problema dei nomi. Sebbene i test possano documentare correttamente il sistema, è quasi impossibile convincere un team fluttuante di sviluppatori a scrivere i loro test seguendo la stessa terminologia, formulazione e stile del dominio.

Quindi, per ribadire:

Come si gestiscono i requisiti del progetto Agile a lungo termine?

Questo mi sembra essere l'elefante non detto nella stanza con i progetti Agile: come si fa a impedire loro di evolversi nel caos?

Diamo un'occhiata al Manifesto Agile per un momento. Desideri agili:

1. Consegna anticipata e continua
2. Accogliere le mutevoli esigenze
3. Fornire frequentemente software funzionante
4. Sviluppatori e stakeholder aziendali che lavorano insieme quotidianamente
5. Costruire progetti intorno a individui motivati, dare loro l'ambiente e il supporto di cui hanno bisogno e fidarsi di loro per ottenere il lavoro fatto
6. Conversazione faccia a faccia come principale modalità di comunicazione
7. Software funzionante come principale misura del progresso
8. Sviluppo sostenibile
9. Attenzione costante all'eccellenza tecnica e al buon design
10. Semplicità - Massimizzare il lavoro che non devi fare
11. A intervalli regolari, il team riflette su come diventare più efficace, quindi sintonizza e regola di conseguenza il suo comportamento

Ho evidenziato gli ultimi quattro. Perché? Perché sono quelli che impediranno al progetto di collassare sotto il suo stesso peso.

Sviluppo sostenibile significa che hai (si spera) qualcuno che sovrintenda al processo di sviluppo complessivo, qualcuno che può guidare un po 'alla volta la nave oltre a far crescere il software, qualcuno che ha una visione generale dell'intero progetto, qualcuno con una profonda conoscenza di architettura software, progettazione di sistemi, principi di logica aziendale ed ergonomia dell'interfaccia utente. Un architetto, in altre parole.

L'architetto è quello che dice "So che hai chiesto questo, ma se costruiamo quest'altra cosa, possiamo evitare queste altre tre caratteristiche che sono solo confuse e concentrarsi sul requisito fondamentale". È quello che dà alla squadra il tempo di ridurre il debito tecnico. È quello che porta una struttura e un'organizzazione globali al progetto. È lui che chiama le riunioni in cui la squadra si riunisce e chiede "Come possiamo fare le cose meglio?"

Ed è quello che mantiene il documento sui requisiti principali.

Nel libro Mastering the Requirements Process , gli autori sostengono che ci sono tre tipi di clienti, tre tipi di progetti software: conigli, cavalli ed elefanti. I conigli sono i piccoli progetti software che richiedono solo requisiti informali; lavori direttamente con il cliente in piccoli sprint, l'ambito del progetto è ragionevolmente limitato e il software viene eseguito in tempi relativamente brevi. Gli elefanti sono quei progetti giganteschi che richiedono molta pianificazione iniziale, un'enorme quantità di documentazione e un orizzonte temporale lungo. Probabilmente non sono agili, anche se è possibile suddividerli in progetti più piccoli che possono essere creati utilizzando agile.

Sono i progetti Horse che sono alquanto confusi da una prospettiva agile. Possono ancora essere costruiti in modo iterativo, è comunque possibile utilizzare brevi sprint, ma senza una certa disciplina nei processi di raccolta e pianificazione dei requisiti, possono facilmente correre fuori dai binari. Questi sono i progetti che possono beneficiare di un processo disciplinato di raccolta dei requisiti, quindi di adattamento e modifica accurati di tali requisiti man mano che il progetto cresce, pur mantenendo una visione globale per l'intero progetto.

Da un punto di vista personale, lavoro con un piccolo team di circa una dozzina di sviluppatori. In qualsiasi momento, potremmo lavorare su tre progetti software contemporaneamente, spaziando da qualche migliaio di righe di codice a oltre 100.000. Il nostro cliente pensa di essere un coniglio, ma sono davvero un cavallo. Il cliente è coinvolto, ma non su base giornaliera.

Di gran lunga la nostra area più debole sta raccogliendo requisiti specifici, verificabili e misurabili e gestendo le aspettative del cliente relativamente all'ambito del progetto. Ma ci stiamo lavorando.

La domanda non è completamente chiara ma sembra che tu sia interessato alla tracciabilità dei requisiti . Un'idea che tende a perdersi in Agile nella mia esperienza è che i requisiti aziendali sono ciò che il cliente desidera che il sistema faccia, mentre le storie degli utenti sono requisiti funzionali che affermano come funziona il sistema. "Come utente, voglio essere in grado di X." Ma ciò viene fatto per soddisfare un requisito, che potrebbe andare perso nella user story.

Ciò che funziona bene nella mia esperienza è collegare i requisiti aziendali e le storie degli utenti in entrambe le direzioni. BR # 1 potrebbe essere realizzato dalle storie A e B. La storia C potrebbe riguardare i BR n. 2 e n. 3. Inseriscilo nel tracker del progetto, nel foglio di calcolo, qualunque cosa tu stia utilizzando.

A lungo termine, questo aiuta a collegare ciò che il cliente richiede (BR) con ciò che il sistema fa (storie) per raggiungere tali requisiti. Questa dovrebbe essere una documentazione abbastanza minima che non è onerosa da mantenere, in linea con la mentalità Agile di non produrre documentazione di cui nessuno ha bisogno ed è un compito ingrato da tenere aggiornato.

Fornisce anche un modo per i nuovi membri del progetto di accelerare poiché hanno qualcosa da rivedere per avere la storia dietro perché il software fa quello che fa.

Attualmente sto lavorando a un progetto di manutenzione kanban di un grande negozio web in cui gli sviluppatori originali non sono più disponibili.

ogni usertory / requisito / bugfix ha un ticketnumber e ogni cambio del codice sorgente è collegato a un ticketnumber nel campo commento-sourcecontrol.

sourcecontrol-checkin-s (svn) aggiorna automaticamente il ticket di risposta in modo che nel ticket abbia un collegamento a tutti i changeset di sourceconrtol.

Se un modulo / funzione è appena implementato, ci sono anche ticketnumber nel codice sorgente.

Nel sistema di ticket (redmine) i ticket sono collegati tra loro come (è duplicato, è bug, è perfezionamento di, ....)

così puoi seguire i biglietti e vedere i cambiamenti dei requisiti nel tempo.

Esempio: devo inserire qualcosa nella "pagina Web OrderConfirmation". Nel codice sorgente della pagina vedo un commento: 'creato per "# 4711"' in modo da poter collegare il mio nuovo biglietto al vecchio biglietto "4711" o ad uno dei suoi successori.

Personalmente, scarto le storie degli utenti come fonte di documentazione su ciò che il sistema può fare. A meno che non siano state prese misure attive per creare documentazione (cosa che abbiamo fatto per alcuni dei nostri clienti più tradizionali), la base di applicazione è davvero la migliore documentazione che ci sia.

Anche se non è una novità.

Se si utilizza una versione più scalata di Agile (come SAFe ), si avranno altri backlog che non sono il backlog di implementazione. In pratica sembra così:

1. Portfolio Backlog (Pianificazione strategica di epopee e budget)
2. Backlog programma / versione (funzionalità ed epiche)
3. Backlog di progetto / team (storie, picchi, bug)

Non consiglierei di documentare a livello di Team Backlog. È troppo granulare e raramente qualcuno vuole andare a quel livello di dettaglio. Per non parlare del fatto che potrebbero esserci delle storie in una Release che contraddicono le storie precedenti nel backlog del Team.

Invece, consiglierei di lavorare a livello di Release Backlog per fornire la documentazione a livello di Release. Queste storie raramente esplodono una volta assegnate a una determinata versione e possono essere un modo stabile e rapido per rivedere ciò su cui si sta lavorando all'interno di una determinata versione.