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

Questo mi sembra essere l'elefante inespresso nella stanza con progetti Agile: come impedisci loro di evolvere nel caos?

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

1. Consegna anticipata e continua
2. Abbracciare i mutevoli requisiti
3. Consegna frequente del software di lavoro
4. Gli sviluppatori e gli stakeholder aziendali collaborano quotidianamente
5. Costruire progetti intorno a individui motivati, dando loro l'ambiente e il supporto di cui hanno bisogno, e confidando che facciano il lavoro
6. Conversazione faccia a faccia come principale modalità di comunicazione
7. Software di lavoro come misura principale di progresso
8. Sviluppo sostenibile
9. Attenzione continua all'eccellenza tecnica e al buon design
10. Semplicità - Massimizzazione del lavoro che non devi fare
11. A intervalli regolari, il team riflette su come per diventare più efficace, quindi sintonizzare e regolare il suo comportamento di conseguenza

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

Sviluppo sostenibile significa che (si spera) qualcuno che sovrintende al processo di sviluppo generale, qualcuno che può guidare la nave oltre a far crescere il software un po 'alla volta, qualcuno che ha una visione globale dell'intero progetto, qualcuno con una profonda conoscenza dell'architettura software, della progettazione del sistema, dei principi della logica di business e dell'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 semplicemente confuse e concentrarsi sui requisiti fondamentali". È lui a dare al team il tempo per ridurre il debito tecnico. È quello che porta una struttura e un'organizzazione globali al progetto. È quello che chiama le riunioni in cui il team si riunisce e chiede "Come possiamo fare le cose meglio?"

E lui è quello che mantiene il documento sui requisiti principali.

Nel libro Padroneggiare il processo dei requisiti , gli autori sostengono che ci sono tre tipi di clienti, tre tipi di progetti software: Conigli, Cavalli e 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 un lasso di tempo relativamente breve. Gli elefanti sono quei progetti mastodontici che richiedono molta pianificazione anticipata, un'enorme quantità di documentazione e un orizzonte temporale lungo. Probabilmente non sono agili, anche se puoi suddividerli in progetti più piccoli che possono essere creati usando agile.

Sono i progetti Horse che sono in qualche modo confusi da una prospettiva agile. Possono ancora essere costruiti in modo iterativo, è comunque possibile utilizzare sprint brevi, ma senza una certa disciplina nella raccolta dei requisiti e nei processi di pianificazione, possono facilmente scappare dalle rotaie. Questi sono i progetti che possono trarre beneficio da un disciplinato processo di raccolta dei requisiti, quindi un attento adattamento e modifica di tali requisiti man mano che il progetto cresce, mantenendo comunque una visione globale per l'intero progetto.

Dal punto di vista personale, lavoro con un piccolo gruppo di circa una dozzina di sviluppatori. In qualsiasi momento potremmo lavorare contemporaneamente a tre progetti software, che vanno da poche migliaia di righe di codice a oltre 100.000. I nostri clienti pensano che siano un coniglio, ma sono davvero un cavallo. Il cliente è impegnato, 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 in relazione allo scopo del progetto. Ma ci stiamo lavorando.

La domanda non è completamente chiara ma sembra che tu ti preoccupi della tracciabilità dei requisiti . Un'idea che tende ad perdersi in Agile nella mia esperienza è che requisiti aziendali sono ciò che il cliente vuole che il sistema faccia, mentre storie utente sono in realtà requisiti funzionali che dichiara come il sistema funziona. "Come utente, voglio essere in grado di X." Ma ciò è fatto per soddisfare un requisito, che può essere perso nella storia dell'utente.

Ciò che funziona bene nella mia esperienza è collegare i requisiti aziendali e le storie degli utenti in entrambe le direzioni. BR # 1 può essere realizzato dalle storie A e B. Story C potrebbe riguardare BRs # 2 e # 3. Metti questo nel tuo tracker del progetto, foglio di lavoro, qualunque cosa tu stia usando.

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

Fornisce anche un modo per far sì che i nuovi membri del progetto diventino veloci poiché hanno qualcosa da rivedere per ottenere la storia dietro perché il software fa quello che fa.

In realtà sto lavorando a un progetto di manutenzione kanban di un grande web shop in cui gli sviluppatori originali non sono più disponibili.

ogni user / requisito / bugfix ha un numero di ticket e ogni variazione di codice sorgente è collegata a un numero di ticket nel campo del commento di sourcecontrollo.

sourcecontrol-checkin-s (svn) aggiorna atomicamente il ticket che corrisponde al corisponding in modo tale che nel ticket disponga di un link a tutti i changeset sourceconrtol.

Se una modul / funzione è stata appena implementata, ci sono anche numeri di ticket nel codice sorgente.

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

in modo da poter seguire i ticket e vedere le modifiche dei requisiti nel tempo.

Esempio: devo cercare qualcosa nella "orderConfirmation-Web-page". Nel codice sorgente della pagina vedo un commento: 'creato per "# 4711"' quindi posso collegare il mio nuovo biglietto al vecchio biglietto "4711" o 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 stati presi provvedimenti attivi per creare documentazione (che abbiamo fatto per alcuni dei nostri client più tradizionali), la base di applicazione è davvero la migliore documentazione che ci sia.

Sebbene non sia niente di nuovo.

Se stai utilizzando una versione più scalabile di Agile (come SAFe ), avrai altri backlog che non sono il backlog dell'implementazione. In pratica assomiglia a questo:

1. Portfolio Backlog (pianificazione strategica di poemi epici e budget)
2. Programma / rilascio del registro (caratteristiche ed epopee)
3. Project / Team Backlog (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 all'interno di una Release potrebbero esserci storie che contraddicono storie precedenti nel backlog del Team.

Suggerirei invece di lavorare a livello di backlog di rilascio per fornire la documentazione a livello di rilascio. Queste storie raramente esplodono una volta assegnate a una particolare versione e possono essere un modo stabile e veloce per rivedere ciò su cui si sta lavorando all'interno di una data release.