È una buona idea scrivere le specifiche dei requisiti in base alle storie?

Al momento stiamo usando metodi agili nel mio progetto attuale e abbiamo un sacco di storie come queste:

• Come assistente, voglio pagare un rimborso a un cliente in modo che possano ottenere dei soldi quando lo richiedono

• Come cliente, desidero pagare un acquisto in modo da poter ricevere il mio articolo.

Il modo in cui l'abbiamo fatto finora è scegliere le storie più importanti ogni sprint ed elaborarle in una serie di specifiche sui requisiti formali (raggruppiamo alcune delle storie che sono simili insieme nella stessa specifica). A seconda della storia, potrebbe essere solo un pulsante su uno schermo o un intero flusso di lavoro.

Il problema ora è che, poiché ci sono così tante storie, non è immediatamente chiaro, per qualsiasi parte del sistema a cui le storie si riferiscono.

Funziona al tempo degli sviluppatori, ogni sprint che gli sviluppatori ricevono solo una specifica che descrive ciò che devono fare e le modifiche che devono apportare. Ma in termini di mantenimento di questo elenco di storie e di test, sta iniziando a ottenere bug di tracciamento davvero difficili e in generale solo a mantenere le specifiche, perché un pezzo di funzionalità nella schermata potrebbe essere stato documentato in un numero di luoghi diversi a causa del fatto che è diviso per storia.

Scrivere specifiche basate su storie è una buona idea? Abbiamo scritto le storie nel modo sbagliato?

Questo potrebbe essere controverso ma eccolo qui!

Abbiamo lavorato su sistemi in tempo reale in cui uno dei miei precedenti capi mi ha suggerito di fare AGILE! È stato facile vincere il management su questo; tuttavia, era più facile a dirsi che a farsi.

Il concetto di storie è buono - ma per essere molto iniziale, è piuttosto vago. Cos'è davvero una storia? Il vero problema è che l'uso delle storie alone(e lo stesso vale per i casi d'uso) ha diversi problemi - come segue:

1. I requisiti non possono essere fuori contesto (a meno che non si facciano ripetizioni grossolane così tante volte). Vi sono ipotesi, conoscenze di base e altri requisiti collegati anche a un determinato requisito; hanno senso solo in un contesto e solo in un ordine specifico. L'implementazione della più importante ha prima senso dal punto di vista aziendale, ma quando le archiviate almeno - mantieni un riferimento completo fin dall'inizio quando le raccogli. La stessa parola dei requisiti è complessa e non si limita davvero a Use-Case / Stories. In effetti le storie sono fruibili, ma poi ci sono requisiti che potrebbero non essere attuabili, come prestazioni, vincoli da rispettare, regole aziendali ecc.

2. I requisiti devono essere di dimensioni adeguate e in modo quantificabile, altrimenti non avrai mai bisogno di più di 1 grande storia! Cosa costituisce esattamente 1 storia?

   • è uno scenario completamente dettagliato? (ad esempio una storia quando ATM rifiuta una transazione)
   • è un insieme di azioni che l'utente esegue? (ad es. storia completa sul ritiro)
   • o è una schermata nell'interfaccia utente? (es. schermata di prelievo come storia completa).
   • In che modo quantificare davvero le regole aziendali molto nitide con le storie? Onestamente, può essere uno dei precedenti. Il punto è quanto limitato e granulare che si vada è uno stile abbastanza personale. Se funziona, va bene;

3. La conoscenza del dominio è davvero richiesta! Un semplice esempio, di un architetto che conosce varie proprietà di vetro, acciaio e legno. questa conoscenza non fa parte del documento di requisiti per l'edificio per dire! Allo stesso modo, se stai scrivendo un software bancario - ci sono molti concetti sull'attività bancaria. Dichiarandoli, in quanto Requisito stesso lo rende non trattabile perché non ti dice cosa dovrebbe fare il software al contrario di come funziona il mondo . La storia include tali complessità di dominio? o lo esclude?

4. Modellare il mondo è un prerequisito non del tutto supportato da.
   C'è stata molta letteratura sulla modellazione che si concentra solo sulla comprensione di come funziona il mondo è una conoscenza di base. La modellazione costituisce una solida base su cui i requisiti acquisiscono un chiaro significato; tuttavia una cosa del genere dovrebbe essere anticipata. Sfortunatamente, la maggior parte delle pratiche agili rifiuta il valore nella modellazione anticipata nell'interesse di consegne più rapide e snelle; ma penso ancora che sia un grande ostacolo per lo spettacolo quando le cose devono ridimensionare. Molti progetti non riescono perché la modellazione è irrilevante, ma gli ingegneri esperti li conoscono nella loro testa e non hanno bisogno di molte indicazioni esplicite.

Quindi venendo alla tua domanda:

Scrivere specifiche basate su storie è una buona idea? Abbiamo scritto le storie nel modo sbagliato?

Penso che le storie degli utenti abbiano valore come verdetto esplicito dato dal cliente. Ma se sono mal organizzati e insufficientemente dettagliati (o vaghi) c'è un problema. A meno che tu non abbia una struttura più ampia per accumulare la comprensione più ampia (conoscenza del dominio) e l'ambito (specifiche totali). User story solo per segmenti o elementi all'interno di tale sistema più grande.

PS: Ho un'opinione esatta sui casi d'uso (come sono rappresentati nei diagrammi ovali) che, a meno che non li inserisca nel contesto appropriato e alla granularità appropriata, non fanno alcun buon lavoro. (Li chiamo casi inutili ). L'unica fonte credibile che trovo per rendere la scrittura di casi d'uso veramente scalabile e significativa è la scrittura di casi d'uso efficaci di Cockburn

> Writing specs by stories? a good idea?

Sì, se riesci a gestire le interdipendenze e le priorità delle tue storie.

Ecco un articolo sulle mappe delle storie che può aiutarti a ordinare e gestire molte storie di utenti.

Appena ho scritto questa risposta, ho capito che non si trattava di test, si tratta di documentazione. Dovresti prima leggere il manifesto agile :

[Apprezziamo] software funzionante su documentazione completa

Pertanto, è necessario rendere eseguibili le specifiche, ovvero scriverle come un set di test completamente automatizzato.

Scrivere specifiche basate su storie è una buona idea?

Sì, lo sono. Si chiama "sviluppo guidato dal comportamento" o "specifica per esempio". Nel rubino c'è un ottimo cetriolo strumento che aiuta in questo.

Il problema ora è che, poiché ci sono così tante storie, non è immediatamente chiaro, per qualsiasi parte del sistema a cui le storie si riferiscono.

Perché vuoi che sia chiaro? Voglio dire, hai davvero bisogno di una matrice di tracciabilità "test / codice"? Il vantaggio di scrivere i test come specifica è che non è necessaria una tracciabilità "requisiti / test" separata, poiché i test diventano requisiti. Ai fini del test di integrazione, è necessario trattare il software nel suo insieme, non come parti separate.

Potrebbe essere necessario uno strumento di copertura per vedere se ci sono moduli "morti", parti del sistema non coperte dai test delle specifiche. Ma non dovresti davvero preoccuparti di quali specifiche corrispondono a questo particolare codice. Dovrebbe essere viceversa: da una specifica specifica dovresti sapere quale parte del sistema corrisponde ad essa. Non dovresti preoccuparti di qualche duplicazione nelle tue specifiche. E se applichi un principio DRY al tuo codice, ci sarebbero dozzine di specifiche che eseguono lo stesso codice.

Funziona al tempo degli sviluppatori, ogni sprint che gli sviluppatori ricevono solo una specifica che descrive ciò che devono fare e le modifiche che devono apportare. Ma in termini di mantenimento di questo elenco di storie e di test, sta iniziando a ottenere bug di tracciamento davvero difficili e in generale solo a mantenere le specifiche, perché un pezzo di funzionalità nella schermata potrebbe essere stato documentato in un numero di luoghi diversi a causa del fatto che è diviso per storia.

Non è raro che centinaia di test di integrazione vengano interrotti da una piccola modifica in un modulo critico. È qui che entra in gioco il test unitario.

Dovresti strutturare i tuoi test in modo tale da poter dire se un particolare test copre un requisito di alto livello, o solo un sottile dettaglio di esso. In quest'ultimo caso, è necessario separare questo test dalla suite di test di integrazione. Lo scopo del test unitario è localizzare i bug. In modo che se si introduce un bug, ci sarà un solo errore di test.

Abbiamo scritto le storie nel modo sbagliato?

Penso che devi solo organizzare le tue storie in epopee per utente, ad esempio "Cliente", "Assistente", o per caratteristiche / schermate / flussi di lavoro ("Acquisto", "Rimborso").

E ancora, i test delle specifiche non sostituiscono i test unitari. Leggi di più

Hai menzionato un problema e il modo in cui lo risolvi, ma ti dimentichi di menzionare alcuni esempi delle tue specifiche e del tuo raggruppamento e di come è correlato al modo in cui sviluppi il tuo prodotto.

Scrivere specifiche per storie? una buona idea?

Agile non lo proibisce. In agile puoi fare tutto ciò di cui hai bisogno per offrire il massimo valore aziendale a un ritmo sostenibile. Quindi, se scrivere le specifiche è qualcosa che devi fornire più valore commerciale, è assolutamente OK farlo.

Il tuo esempio mostra due storie utente. Forse sono in qualche modo correlati nella tua logica aziendale, ma questo è uno scenario molto comune.

Se è necessario associare la funzionalità alle storie utente, è possibile utilizzare nuovamente ciò che si adatta meglio, compresa la documentazione, alcuni diagrammi o le proprie "specifiche", ma è necessario essere preparati a mantenere tali artefatti a un costo maggiore all'aumentare della complessità dell'applicazione sviluppata. Quindi l'unica domanda a cui devi rispondere in questo caso è: se non uso le mie specifiche ci costerà di più? Se la risposta è sì, hai scelto un'opzione migliore.

L'agile funziona al meglio per progetti medio-piccoli con un piccolo team in cui l'intera architettura viene mantenuta come conoscenza tacita condivisa nel team. Durante la pianificazione dell'iterazione esaminerai le storie scelte, discuterai un impatto sull'attuazione corrente e scriverai alcune attività necessarie per completare la storia. La vera documentazione in tal caso sarà la suite di test con accettazione automatica e test di integrazione / unità. Una volta che il tuo SW o il tuo team crescono, la conoscenza tacita dovrà passare parzialmente ad alcuni documenti.

Ora è qui che l'astrazione gioca un ruolo importante. Devi guardare le storie con rispetto della prospettiva rilevante. Raccogli i nomi e i verbi nelle dichiarazioni e confermali. Non è possibile basare i propri modelli su presupposti personali . Prestare anche attenzione ai dettagli.

La scrittura di specifiche basate sulle storie degli utenti non può essere accurata. È necessario scavare ulteriori dettagli e talvolta ignorare i dettagli che non sono rilevanti. Le specifiche devono essere scritte quando il modello è completo e accurato alla conferma dell'analista.