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

Questo potrebbe essere controverso, ma qui va!

Abbiamo lavorato su un sistema in tempo reale in cui uno dei miei vecchi boss ha suggerito di fare AGILE! E 'stato facile vincere la gestione su quello veramente; tuttavia, è stato più facile a dirsi che a farsi.

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

1. I requisiti non possono essere fuori dal contesto (a meno che tu non stia facendo ripetizioni grossolane tante volte). Ci sono presupposti, conoscenze di base e altri requisiti che sono collegati anche a un determinato requisito; hanno senso solo in un contesto e solo in un ordine specifico. L'implementazione la prima più importante ha senso dal punto di vista economico, ma quando li si archivia almeno - mantenere un riferimento completo fin dall'inizio quando li si raccoglie. La parola di requisito in sé è complessa e non è realmente limitata a Use-Case / Stories. In effetti, le storie sono perseguibili, ma ci sono requisiti che potrebbero non essere perseguibili, come prestazioni, vincoli da rispettare, regole aziendali, ecc.

2. I requisiti devono essere appropriati in termini di dimensioni e in modo quantificabile altrimenti non puoi mai aver bisogno di più di 1 grande articolo! Che forma esattamente 1 storia?

   • è uno scenario dettagliato completo? (ad esempio, una storia in cui ATM respinge una transazione)
   • è un insieme di azioni che l'utente esegue? (ad esempio, la storia completa sul ritiro)
   • o è una schermata nell'interfaccia utente? (ad esempio la schermata di prelievo come una storia completa).
   • In che modo quantificare realmente le regole aziendali con storie molto nitide? Onestamente, può essere uno dei precedenti. Il punto è quanto confinato e granulare si va è uno stile piuttosto personale. Se funziona, va bene;

3. La conoscenza del dominio è davvero un requisito! Un semplice esempio di un architetto che conosce varie proprietà di vetro, acciaio e legno. questa conoscenza non fa parte del documento di requisito per l'edificio per dire! Allo stesso modo, se stai scrivendo un software bancario - ci sono molti concetti sul settore bancario. Dichiarandoli, come Requirement stesso non è rintracciabile perché non ti dice che cosa dovrebbe fare il software al contrario di come funziona il mondo . La storia include tali intrecci di dominio? o esclude questo?

4. La modellazione del mondo è un prerequisito non abbastanza supportato da.
   C'è stata molta letteratura sulla modellazione che si concentra sulla semplice comprensione di come funziona il mondo è una conoscenza di base. La modellizzazione costituisce una base solida su cui i requisiti acquisiscono un significato chiaro; tuttavia una cosa del genere dovrebbe essere anticipata. Sfortunatamente, la maggior parte delle pratiche agili rifiuta il valore della modellistica iniziale nell'interesse di consegne più rapide e più snelle; ma quello che penso ancora è un grande spettacolo quando le cose devono ridimensionarsi. Molti progetti riescono non perché la modellazione è irrilevante, ma i tecnici esperti li conoscono bene e non hanno bisogno di molte indicazioni esplicite.

Quindi venendo alla tua domanda:

Is writing specs based on stories a good idea? Have we written the stories in the wrong way?

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

PS: Ho un'opinione esatta sui casi d'uso (come sono illustrati nei diagrammi ovali) che, a meno che non li mettiate nel contesto appropriato e alla granularità appropriata, non fanno un buon lavoro. (Li chiamo casi inutili ). L'unica fonte credibile che trovo per rendere la scrittura case use veramente scalabile e significativa è Scrivere 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 su mappe di storie che possono aiutarti a ordinare e mange molti userstories.

A partire dal momento in cui ho scritto questa risposta, ho capito che non si tratta di test, ma di documentazione. Per prima cosa, leggi manifesto agile :

[We value] working software over comprehensive documentation

Pertanto, dovresti rendere eseguibili le tue specifiche, scrivendole come un set di test completamente automatizzato.

Is writing specs based on stories a good idea?

Sì, imho, lo è. Si chiama "sviluppo guidato dal comportamento" o "specifica dall'esempio". In ruby c'è un ottimo strumento cetriolo che aiuta molto.

The problem now is that because there's so many stories, it's not immediately clear, for any part of the system which stories relate to it.

Perché vuoi che sia chiaro? Voglio dire, hai davvero bisogno di una matrice di tracciabilità "test / codice"? Il vantaggio di scrivere test come una specifica è che non è necessaria una tracciabilità separata "requisiti / test", perché i test diventano requisiti. Ai fini dei test di integrazione, dovresti trattare il tuo 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 quale specifica questo particolare codice corrisponde. Dovrebbe essere viceversa: da una particolare specifica dovresti sapere quale parte del sistema corrisponde ad essa. Non dovresti preoccuparti di alcune duplicazioni nelle tue specifiche. E se applichi un principio DRY al tuo codice ci saranno dozzine di specifiche che eseguono lo stesso codice.

It works at the time of developers, every sprint the devs just get a spec outlining what they need to do and the changes they need to make. But in terms of maintaining this story list and for testing, its starting to get really hard tracking bugs and in general just maintaining the specs, because one piece of functionality in the screen might have been documented in a number of different places due to it being split by story.

Non è infrequente che centinaia di test di integrazione vengano interrotti da una piccola modifica in un modulo critico. È qui che entra in gioco il test dell'unità.

Dovresti strutturare i tuoi test in modo tale che tu possa capire se un determinato 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à uno e un solo errore di test.

Have we written the stories in the wrong way?

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

E ancora, i test delle specifiche non sostituiscono il collaudo delle unità. Ulteriori informazioni

Hai menzionato un problema e il modo in cui lo risolvi, ma dimentichi di menzionare qualche esempio delle tue specifiche e raggruppamenti e in che modo è correlato al modo in cui sviluppi il tuo prodotto.

Writing specs by stories? a good idea?

Agile non lo proibisce. In agile puoi fare tutto il necessario per offrire il massimo valore aziendale in un ritmo sostenibile. Quindi se scrivere specifiche è qualcosa che devi fornire più valore per il business, è assolutamente OK farlo.

Il tuo esempio mostra due storie di utenti. Sono forse in qualche modo correlati nella tua logica aziendale, ma questo è uno scenario molto comune.

Se hai bisogno di eseguire il bactrack delle funzionalità per le storie degli utenti puoi di nuovo usare quello che ti aggrada meglio, inclusa la documentazione, alcuni diagrammi o le tue "specifiche" ma devi essere preparato che il mantenimento di questi artefatti ti costerà di più come complessità dell'applicazione sviluppata aumentare. Quindi l'unica domanda a cui devi rispondere in questo caso è: Se non utilizzo le mie specifiche ci costerà di più? Se la risposta è sì, hai scelto un'opzione migliore.

L'agile funziona meglio per i progetti di piccole e medie dimensioni con una piccola squadra dove l'intera architettura è considerata una conoscenza tacita condivisa nel team. Durante la pianificazione dell'iterazione, passerai attraverso le storie raccolte, discuterai un impatto sull'implementazione 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 team cresce, la conoscenza tacita dovrà spostarsi parzialmente su alcuni documenti.

Ora è qui che l'astrazione gioca un ruolo importante. Devi guardare le storie con la prospettiva pertinente. Raccogli i nomi e verbi nelle dichiarazioni e confermali. Non puoi basare i tuoi modelli su ipotesi personali . Prestare attenzione anche 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 dovrebbero essere scritte quando il modello è completo e accurato alla conferma del proprio analista.