Come tenere traccia di un documento sui requisiti in un team agile?

Comprendo che le User Story dominano il mondo agile, ma come vengono archiviati questi artefatti, in modo che i nuovi sviluppatori che si uniscono al team possano venire incontro ai requisiti?

Cosa succede se la User Story cambia in seguito, come viene aggiornata e conservata come artefatto? Ho visto molti team aprire semplicemente un nuovo ticket / richiesta funzionalità / report bug invece di tenere traccia della storia originale.

Prima di tutto, quasi nulla nella risposta di @ DXM corrisponde alla mia esperienza con Agile, e soprattutto non con Scrum.

Il Manifesto Agile afferma che mentre la documentazione completa è preziosa, il software di lavoro è PIÙ prezioso. Quindi, la documentazione non è certamente una cosa negativa, ma dovrebbe davvero essere al servizio della creazione di software funzionante.

Individui e interazioni su processi e strumenti

Software funzionante su documentazione completa

Collaborazione con i clienti sulla negoziazione del contratto

Rispondere al cambiamento seguendo un piano

Cioè, mentre c'è valore negli oggetti a destra, valutiamo di più gli oggetti a sinistra.

Individuare ogni dettaglio prima di iniziare a scrivere codice si è rivelato sempre più dispendioso, quindi la documentazione viene generalmente trattata in modo JIT (giusto in tempo). Cioè, documentate ciò che state effettivamente codificando.

Uno dei modi più popolari di fare Scrum è usare le User Story, che sono gestite dal Product Owner e conservate nel Product Backlog. Il Product Backlog è un elenco di livello piuttosto elevato di tutte le cose che una soluzione deve fare e una User Story è generalmente un modo ben dimensionato per descrivere ogni cosa dell'elenco. Le User Story non sono obbligatorie, ma sembrano essere un buon modo per non esagerare con i dettagli e ispirare la collaborazione.

Quindi, comunque, quando una storia è terminata - il team ha creato, testato e distribuito qualcosa che soddisfa i criteri di accettazione, la storia non viene CHUCKED, è semplicemente contrassegnata come eseguita nel backlog - quindi il backlog ha qualche indicazione di ciò che è stato fatto in ogni sprint: storie e punti ad esse associati. Questo è ciò che consente di calcolare la velocità ed è una preziosa documentazione in sé e per sé.

Detto questo, una User Story può essere tutta la documentazione necessaria per comprendere un requisito, ma più probabilmente è qualcosa che genera una conversazione tra il cliente e il team di sviluppo. Pertanto, ci sono molte cose che puoi fare intorno a quella conversazione. Se è una cosa ad hoc faccia a faccia, come spesso accade, l'analista / gli sviluppatori possono (e possibilmente, a seconda dell'organizzazione, dovrebbero) annotare qualsiasi decisione presa e salvarla da qualche parte, come un Wiki o un repository di documentazione. Se si tratta di una conversazione e-mail, è possibile salvare le e-mail. Se è una sessione di lavagna, scatta una foto della lavagna con il tuo cellulare e salvala. Il punto è che queste cose ti stanno aiutando a ottenere il codice fatto e potrebbero essere in grado di aiutarti in seguito se hai bisogno di capire come o perché l'hai fatto nel modo in cui l'hai fatto.

Un altro metodo per acquisire i requisiti è quello di incorporarli immediatamente nei casi di test (che credo sia quello a cui stava lavorando DXM). Questo può essere davvero efficiente, in quanto è necessario testare comunque ogni requisito. In questo caso, puoi archiviare efficacemente le tue esigenze nel tuo strumento di test.

Se una storia è completata (e accettata) e quindi l'utente cambia le sue necessità, allora probabilmente dovrai crearne una nuova. Se usi una wiki per la tua documentazione, puoi collegare la nuova storia indietro all'originale, e allo stesso modo collegare quella storia originale in avanti alle nuove cose in modo che qualcuno che la guardi sappia che le cose sono cambiate. Questa è la cosa bella dei wiki: è facile e abbastanza indolore collegare le cose. Se stai adottando l'approccio test-driven, aggiorneresti il ​​test case per gestire la modifica, oppure creeresti nuovi casi di test per la nuova storia se il nuovo e il vecchio non si escludono a vicenda.

Alla fine, dipende da quale sia il tuo bisogno. Se la cosa principale è far accelerare rapidamente le persone, è probabilmente una buona idea per qualcuno scrivere un documento di bordo per aiutarle. Quindi qualcuno lo faccia. Come ho già detto, i Wiki sono un ottimo strumento per mantenere questo genere di cose, quindi potresti considerare le soluzioni di Atlassian che possono integrare il Wiki di confluenza con Jira e Greenhopper per tenere traccia delle tue storie / attività / difetti e gestire il tuo progetto in generale. Ci sono anche molti altri strumenti tra cui scegliere.

[aggiornamento n. 1] Come sottolineato da @MatthewFlynn, la sua esperienza con Agile e molti altri (incluso il mio) è molto diversa dalla risposta che sto fornendo qui. La risposta qui si basa sulle mie osservazioni su ciò che ha funzionato e non ha funzionato nel mio team in passato, combinato con molti libri e blog che ho letto sull'argomento ...

la maggior parte della spinta verso uno sviluppo agile è specificamente mirata all'eliminazione dei documenti relativi ai requisiti.

Agile cerca di eliminare la maggior parte della documentazione e sono d'accordo con le loro idee, ma di tutti i documenti, i requisiti hanno di gran lunga il più grande occhio di bue su di loro. La ragione di ciò (IMO) è che i documenti dei requisiti sono più lontani dal codice di lavoro effettivo e da tutti i documenti, che li rende

• meno accurato
• più difficile da mantenere
• meno utile

Per guidare il team su ciò che dovrebbe essere sviluppato in seguito, Agile sostituisce i documenti sui requisiti con un arretrato di storie che identificano ciò su cui dovresti lavorare sugli elementi successivi e di massima priorità con il massimo del dollaro (sia il dollaro presente che futuro) sono in genere al primo posto in quell'elenco.

Tuttavia, un backlog non deve essere confuso con un doc requisiti:

• In un backlog, solo N numero di storie dovrebbe contenere dettagli. Più una storia è lontana, meno dettagli dovresti inserirla (cioè non perdere tempo a cercare di definire qualcosa che non accadrà per un anno e mezzo ).
• Al di là di un certo punto, gli elementi "requisiti" non dovrebbero nemmeno essere inseriti in un backlog se sono fuori più di 2 cicli di rilascio (ovvero potenziali incrementi shippable (PSI)). Anche se sai che il requisito è importante e deve essere fatto a un certo punto, resisti alla tentazione di aggiungerlo al backlog. Se è davvero importante, qualcuno lo ricorderà nella prossima versione. Se nessuno lo ricorda, molto probabilmente è perché non era poi così importante.

Una volta completata una storia, quella storia viene rimossa dal backlog e viene CHUCKED ⁽¹⁾ . Ancora una volta, le storie non sono requisiti. Danno SOLO alla squadra su cosa lavorare dopo; non sono per documenti storici.

Tuttavia, nel corretto processo agile, ogni volta che si consegna un lavoro, parte di quella consegna dovrebbe essere test unitario / integrazione / accettazione. Questi test sono molto preziosi perché hanno molti scopi. Non entrerò nell'elenco completo, ma uno di questi scopi è la documentazione per il tuo attuale software di produzione.

Un test documenta come dovrebbe comportarsi il software dato un certo insieme di input e condizioni preliminari. Documenta inoltre come utilizzare le API pubbliche (e interne) del codice. Serve anche come rete di sicurezza in modo tale che quando un nuovo sviluppatore entra in una squadra e inavvertitamente rompe qualcosa, quell'errore verrà colto non appena verrà registrato.

Il processo agile ovviamente promuove il più possibile il vantaggio dei test di unità automatizzati, ma sappiamo tutti che non tutto può essere automatizzato. La tua suite di software avrà sempre una serie di test che devono essere eseguiti manualmente. Tuttavia, a) i tuoi sviluppatori dovrebbero impegnarsi attivamente nell'automazione quanto più possibile eb) una serie di test manuali dovrebbe essere regolarmente eseguita dal team addetto al controllo qualità in modo tale da scoprire il più presto possibile eventuali interruzioni delle funzionalità.

⁽¹⁾ - Da quando ho ricevuto diverse risposte per la parte "ridacchiata". In 5 anni da quando sono passato all'agile, la mia squadra non ha mai buttato via una sola storia, nemmeno il 30% di quelli che erano stati programmati, poi rinviati e poi dimenticati. Il mio capo voleva tenerli "come riferimento" e tuttavia nessuno ha mai visto nessuna di quelle storie.

Le persone sono generalmente attaccate ai loro dati e so che è difficile immaginare di buttare fuori qualcosa quando lo hai già, ma tenere l'inventario (fisico o elettornico) a portata di mano non è gratuito e più ci penso, più sono d'accordo con il "chucking". Questo è tratto da "Requisiti software agili: pratiche di requisiti snelli per team, programmi ed impresa" (p.190) - "Le storie degli utenti possono essere gettate via in modo sicuro dopo l'implementazione. Ciò le mantiene leggere, le rende amichevoli per il team e promuove la negoziazione, ma i test di accettazione persistono per la durata dell'applicazione ... "

Cosa succede se la User Story cambia in seguito, come viene aggiornata e conservata come artefatto? Ho visto molti team aprire semplicemente un nuovo ticket / richiesta funzionalità / report bug invece di tenere traccia della storia originale.

La gestione di qualsiasi documentazione può essere difficile indipendentemente dal fatto che si stiano utilizzando storie agili o un documento di grandi dimensioni e, al fine di ridurre l'onere, la documentazione deve essere minima e aggiornata in modo incrementale per adeguarsi agli sforzi compiuti sui test e sull'implementazione. Tuttavia, come ha accennato l'OP, il semplice aggiornamento della documentazione rischia di perdere la storia di come il software si è evoluto nel tempo.

È davvero importante? A volte può essere. Per la maggior parte desideri semplicemente visualizzare le storie / UML / qualunque cosa insieme ai test e al codice stesso al momento attuale, tuttavia quando vengono sollevate domande sul perché una funzionalità è stata implementata in un modo particolare, spesso può essere utile per guardare alla storia, al fine di vedere come la funzione è cambiata nel corso del tempo, a dipingere un quadro più chiaro il motivo per cui l'opzione realizzazione X è stato scelto al posto di opzione Y .

Ci sono un paio di modi in cui puoi tenere traccia di tali artefatti. Una delle opzioni migliori può essere quella di mantenere le tue storie in uno strumento che ti consenta di avere una versione del testo della tua storia simile a quella del tuo codice sorgente. Wiki tende ad essere molto bravo in questo, e così anche alcuni degli strumenti di gestione di progetti / problemi, come Trac o Redmineche conservano la cronologia delle modifiche ai problemi stessi, nonché le pagine wiki all'interno di questi sistemi. Questo può essere portato un po 'oltre, per migliorare la capacità di tracciare i cambiamenti da un problema all'altro, assicurando che nuove storie o problemi siano collegati in qualche modo a problemi e storie precedenti. Questo potrebbe essere semplice come aggiungere un vecchio problema / ID storia al testo di un nuovo problema / storia, ma può essere notevolmente migliorato includendo qualsiasi problema o ID storia nel commento di check-in ogni volta che commetti una modifica al tuo sistema di controllo della versione . Questo metodo è di grande valore, tuttavia, se i tuoi impegni sono frequenti e limitati a una singola storia o problema.

La più grande difficoltà, naturalmente, è che questo tipo di approccio richiede un'attenta attenzione e un impegno da parte di ogni membro del team per essere coerenti e per mantenere i loro impegni piccoli e frequenti e per coloro che gestiscono le storie e / o i sistemi di tracciamento dei progetti / progetti per mantenere oltre agli artefatti che forniscono collegamenti tra lo stato attuale dell'implementazione e tutte le modifiche che si sono verificate in precedenza.

È stato detto prima, ma penso che l'essenza sia questa:

• i requisiti possono coprire molte sfaccettature e in genere comportano più di una storia.

• una storia organizza il lavoro di una squadra in blocchi abbastanza piccoli da adattarsi ai limiti temporali di uno sprint.

• spesso ci sono molti dettagli che devono essere definiti affinché una particolare funzione funzioni correttamente. Questo è quando inizia a diventare utile conservare queste definizioni in un documento separato sui requisiti - per chiarezza, comprensione comune e riferimento futuro.

Considera il leggendario esempio di negozio di animali online:

• La storia potrebbe dire "Come utente, voglio vedere l'IVA stampata sulla mia ricevuta, ...". Ora, il calcolo dell'IVA (imposta sul valore aggiunto) può essere una questione complicata e probabilmente ha bisogno di più lavoro di quanto suggerisce questa storia.
• Potrebbe esserci una storia aggiuntiva che richiede il calcolo dell'IVA (ad esempio moltiplicare l'importo totale delle vendite per l'aliquota IVA ), ma è probabile che non includa tutte le variazioni di tale calcolo.
• Inizialmente, il team si sarebbe concentrato sulla fornitura del modulo di base, dicendo prendendo un elenco di prodotti e il loro prezzo di vendita e restituendo l'importo dell'IVA. Questo è qualcosa che una squadra può realizzare entro un lasso di tempo.
• È probabile che ci saranno molte altre storie per coprire tutti i possibili casi per il calcolo dell'IVA.
• Per mantenere visibili le diverse regole di calcolo dell'IVA attraverso e oltre i singoli sprint, ha senso conservare un documento di requisiti separato che elenca tutti i vari modi per calcolare l'IVA. Questo documento potrebbe evolversi nel tempo. In effetti, l'aggiunta di una nuova sezione potrebbe far parte del compito di una storia da completare.

Puoi usare Freemind per raccogliere l'elenco delle funzionalità. Come è fatto, dai un'occhiata a questo tutorial (da qualche parte nel mezzo).

Quando hai un elenco di funzionalità, vai con la scrittura di storie utente. Questo può essere fatto utilizzando un semplice file di testo, un documento di Word o qualcosa di così complesso come uno strumento di gestione agile .

Quando finisci con le storie degli utenti, queste hanno la priorità. Più tardi, dalle storie degli utenti, le persone producono attività, le persone prendono le attività e le implementano nel codice.

Tutto questo può essere visto come il progetto ac # è gestito dall'inizio nell'autunno di agili serie di cast di video .