Capisco che le User Story dominino il mondo agile, ma come vengono memorizzati questi artefatti, in modo che i nuovi sviluppatori che si uniscono al team possano raggiungere i requisiti?
Che cosa succede se la User Story cambia in seguito, come viene aggiornata e conservata come artefatto? Ho visto molti team aprire una nuova richiesta di ticket / funzionalità / segnalazione di bug invece di tenere traccia della storia originale.
Prima di tutto, quasi nulla nella risposta @ DXM corrisponde alla mia esperienza con Agile, e soprattutto non con Scrum.
Il Agile Manifesto afferma che mentre la documentazione completa è preziosa, il software di lavoro è PIÙ prezioso. Quindi, la documentazione non è certamente una brutta cosa, ma dovrebbe veramente essere in servizio alla creazione di software funzionante.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Annotare ogni dettaglio prima di iniziare a scrivere sul codice si è dimostrato sempre più inutile, quindi la documentazione viene generalmente trattata in modo JIT (just in time). Cioè, si documenta ciò che si sta effettivamente andando a codice.
Uno dei modi più comuni di fare Scrum è usare le User Story, che sono gestite dal Product Owner e conservate nel Product Backlog. Il Product Backlog è un elenco abbastanza alto di tutte le cose che una soluzione deve fare, e una User Story è generalmente un modo abbastanza grande per descrivere ogni cosa sulla lista. Le User Story non sono obbligatorie, ma sembrano essere un buon modo per non esagerare con i dettagli e ispirare invece la collaborazione.
Quindi, comunque, quando una storia è finita - il team ha creato, testato e distribuito qualcosa che soddisfa i criteri di accettazione, la storia non è CHUCKED, è semplicemente contrassegnata come fatta nel backlog - quindi il backlog fa avere qualche indicazione su cosa è stato fatto in ogni sprint - storie e punti associati a loro. Questo è ciò che ti permette di calcolare la velocità, ed è una documentazione valida di per sé.
Tutto ciò che è stato detto, una User Story può essere tutta la documentazione necessaria per comprendere un requisito, ma più probabilmente è qualcosa per generare una conversazione tra il cliente e il team di sviluppo. In quanto tale, ci sono un certo numero di cose che puoi fare in quella conversazione. Se si tratta di una cosa ad-hoc faccia a faccia, come spesso accade, l'analista / sviluppatore può (e possibilmente, a seconda della propria organizzazione, dovrebbe) 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 si tratta di una sessione di lavagna, scattare una foto della lavagna con il cellulare e salvarla. Il punto è che queste cose sono ciò che ti aiuta a ottenere il codice e potrebbero aiutarti in seguito se hai bisogno di capire come o perché l'hai fatto come hai fatto.
Un altro metodo per catturare i requisiti è quello di incorporarli immediatamente in casi di test (che credo sia ciò che DXM stava ottenendo). Questo può essere davvero efficiente, in quanto è necessario testare per ogni requisito comunque. In questo caso, puoi conservare in modo efficace i tuoi requisiti nel tuo strumento di test.
Se una storia è completata (e accettata) e l'utente cambia le sue esigenze, beh, allora probabilmente hai bisogno di creare una nuova storia. Se usi una wiki per la tua documentazione, puoi collegare la nuova storia all'originale e collegare la storia originale con quella nuova in modo che qualcuno che la guarda sappia che le cose sono cambiate. Questa è la cosa bella dei wiki: è facile e abbastanza indolore collegare le cose. Se stai adottando un approccio basato sui test, aggiorni il caso di test per gestire il cambiamento o crea nuovi casi di test per la nuova storia se il nuovo e il vecchio non si escludono a vicenda.
Alla fine, dipende da cosa è necessario. Se la cosa principale è fare in modo che la gente diventi veloce, è probabilmente una buona idea per qualcuno scrivere un documento di bordo per aiutarli. Quindi qualcuno lo faccia. Come ho detto, i Wiki sono un ottimo strumento per mantenere questo genere di cose, quindi potresti prendere in considerazione le soluzioni di Atlassian che possono integrare Confluence Wiki con Jira e Greenhopper per tracciare le tue storie / attività / difetti e gestire il tuo progetto in generale. Ci sono molti altri strumenti tra cui scegliere.
[update # 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 è basata sulle mie osservazioni su ciò che ha fatto e non ha funzionato sul mio team in passato, combinato con molti libri e blog che ho letto sull'argomento ...
la maggior parte della spinta verso uno sviluppo agile è specificatamente mirata all'eliminazione dei documenti sui 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 dipinto su di loro. La ragione di ciò (IMO) è che i documenti dei requisiti sono più distanti dal codice di lavoro effettivo e di tutti i documenti, che li rende
Per guidare il team su ciò che dovrebbe essere sviluppato successivamente, Agile sostituisce i documenti dei requisiti con un backlog di storie che identificano ciò che si dovrebbe lavorare su articoli successivi e con priorità più alta con il più grande successo (buck presente e futuro) in genere viene inserito per primo in tale elenco.
Tuttavia, un backlog non deve essere confuso con un documento dei requisiti:
Una volta completata la storia, quella storia viene rimossa dall'arretrato ed è CHUCKED (1) . Ancora una volta, le storie non sono requisiti. SOLO dicono al team su cosa lavorare dopo; non sono per record storici.
Tuttavia, in un processo corretto e agile, ogni volta che consegni lavoro, parte di quella consegna dovrebbe essere test di unità / integrazione / accettazione. Questi test sono molto preziosi perché hanno molti scopi. Non entrerò nella lista completa, ma uno di questi è la documentazione per il tuo attuale software di produzione.
Un test documenta come dovrebbe comportarsi il software dato un certo insieme di input e precondizioni. Documenta anche come utilizzare le API pubbliche (e interne) del tuo codice. Serve anche come rete di sicurezza in modo che quando un nuovo sviluppatore entra in una squadra e inavvertitamente rompe qualcosa, quell'errore verrà catturato non appena viene archiviato.
Il processo Agile promuove ovviamente il più possibile il vantaggio dei test di unità automatizzati, ma sappiamo tutti che non tutte le cose possono essere automatizzate. La tua suite software avrà sempre una serie di test che devono essere eseguiti manualmente. Tuttavia, a) i tuoi sviluppatori dovrebbero lavorare attivamente sull'automazione quanto più possibile e b) la serie di test manuali deve essere eseguita regolarmente dal tuo team addetto al QA in modo che ogni interruzione di funzionalità venga scoperta il prima possibile.
(1) - Dal momento che ho ricevuto diverse risposte per la parte "chucked". In 5 anni dal passaggio all'agile, la mia squadra non ha mai buttato via una sola storia, anche il 30% di quelli che sono stati programmati, poi rimandati e poi dimenticati. Il mio capo voleva tenerli "per riferimento" eppure nessuno ha mai guardato nessuna di quelle storie.
Le persone sono generalmente attaccate ai loro dati e so che è difficile immaginare di buttare fuori qualcosa una volta che l'hai già fatto, ma mantenere l'inventario (sia fisico che elettronico) non è gratuito e più ci penso, il più sono d'accordo con il "chucking". Si tratta di " Requisiti software agili: pratiche di requisiti snelli per team, programmi e aziende "(p.190) -" Le storie degli utenti possono essere tranquillamente buttati via dopo l'implementazione, il che li rende leggeri, li mantiene amichevoli e favorisce la negoziazione, ma i test di accettazione persistono per tutta la vita dell'applicazione ... "
What if the User Story changes later, how is it updated and kept as an artifact? I've seen many teams just open a new ticket/feature request/bug report instead of keeping track of the original story.
Gestire la documentazione qualsiasi può essere difficile indipendentemente dal fatto che si stiano utilizzando storie agili o un grande documento e, per ridurre il carico, la documentazione dovrebbe essere minimo e aggiornato in modo incrementale per abbinare gli sforzi fatti sui test e l'implementazione. Come l'OP ha fatto allusione, tuttavia, l'aggiornamento della documentazione rischia di perdere la cronologia di come il software si è evoluto nel tempo.
È davvero importante? A volte può essere. Per la maggior parte si desidera semplicemente visualizzare le storie / UML / qualsiasi cosa insieme ai test e al codice stesso al momento attuale, tuttavia quando vengono poste domande sul motivo per cui una funzionalità è stata implementata in un modo particolare, può spesso essere utile per guardare la cronologia per vedere come la funzione è cambiata nel tempo, per dipingere un'immagine più chiara del motivo per cui è stata scelta l'opzione di implementazione X invece dell'opzione Y .
Ci sono un paio di modi in cui puoi tenere traccia di tali artefatti. Una delle migliori opzioni può essere quella di mantenere le tue storie in uno strumento che ti permetta di avere la versione del tuo testo in un modo simile alla versione del tuo codice sorgente. I Wiki tendono ad essere molto bravi in questo, e lo sono anche alcuni degli strumenti di gestione del progetto / problema, come Trac o Redmine che mantiene la cronologia delle modifiche agli stessi problemi, nonché le pagine wiki all'interno questi sistemi. Tuttavia, ciò può richiedere ancora un po 'di tempo, per migliorare la capacità di tracciare le modifiche da un problema all'altro, garantendo che le nuove storie o problemi siano in qualche modo collegati a storie e problemi correlati più vecchi. Questo potrebbe essere semplice come aggiungere un vecchio problema / story id al testo di un nuovo numero / storia, ma può essere migliorato notevolmente includendo qualsiasi problema o ID di story del commento di check in ogni volta che si commette una modifica al proprio sistema di controllo della versione . Questo metodo è di massimo valore tuttavia se i tuoi commit sono frequenti e limitati a una singola storia o problema.
La più grande difficoltà, naturalmente, è che questo tipo di approccio richiede attenzione e impegno da parte di ogni membro del team per essere coerenti e mantenere i propri impegni piccoli e frequenti, e per coloro che gestiscono le storie e / o il rilascio / tracciamento del progetto sistemi per mantenere in primo piano gli artefatti che forniscono collegamenti tra lo stato attuale della tua implementazione e tutte le modifiche che si sono verificate in precedenza.
È stato detto prima, ma penso che il succo sia questo:
possono coprire molte sfaccettature e in genere generare 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 per far funzionare correttamente alcune funzioni particolari. Questo è quando inizia a diventare utile per mantenere queste definizioni in un documento con requisiti separati - per chiarezza, comprensione comune e riferimento futuro.
Considera il leggendario esempio di negozio di animali online:
Puoi utilizzare Freemind per raccogliere l'elenco delle funzionalità. Come è fatto, date 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 usando un semplice file di testo, un documento word o qualcosa di così complesso come uno strumento di gestione agile .
Quando finisci con le storie degli utenti, hanno la priorità. Più tardi, dalle storie degli utenti, le persone producono attività, le persone prendono compiti e li implementano in codice.
Tutto questo può essere visto come il progetto ac # viene gestito dall'inizio nella serie di cast video autunnali di agile .
Leggi altre domande sui tag agile scrum user-story