Domanda

A pochi individui al mio lavoro si sono uniti per formare un gruppo il cui obiettivo è quello di analizzare i benefici derivanti dall'applicazione di alcuni principi di gestione di sviluppo software Agile / progetto.

Come sviluppatore, vedo grande vantaggio in Storie utente. Stiamo cercando di mettere insieme un radiatore informazioni che possono essere utilizzati per monitorare le fasi della versione corrente e la pianificazione release future. Mi piacerebbe utilizzare User Stories per questo processo.

In questo momento, stiamo usando Bugzilla per la gestione dei problemi. La maggior parte di pianificazione di rilascio viene fatto usando i bug da questo sistema. L'uso di Bugzilla non probabilmente cambierà. Esso fornisce la maggior parte di quello che ci serve al giusto costo ($ 0).

Una delle preoccupazioni è la mappatura di User Stories a bug. gestione delle release è fatto attualmente utilizzando i numeri di bug. Il problema è che un'User Story potrebbe includere tre bug o viceversa.

Nello scenario di avere più segnalato bug per un singolo utente Story, una sola idea è quella di avere un Bug User Story che enuncia le dipendenze di storia e dato alle cimici bambino che compongono quella storia. Sono preoccupato questo può finire per essere troppo complesso e di creare confusione tra le parti interessate, sviluppo e QA. Inoltre, sarà ingombrare Bugzilla un bel po '.

Qualcuno ha già su questa strada? Se è così, che cosa hai fatto? Devo spingere ad abbandonare l'idea di User Stories in Bugzilla? C'è una soluzione più semplice?

Ogni pensiero sarebbe apprezzato.

È stato utile?

Soluzione

Ho fatto cose simili prima in Bugzilla, e la soluzione che ho trovato non ero per implementare gerarchici "cimici storia" o simili; abbiamo deciso anche che che potrebbe causare confusione e era semplicemente troppo complicato per quello che volevamo. La soluzione che ho usato prima era semplicemente quello di mettere il numero User Story nella descrizione per il bug; si può buttare un link in là pure, per rendere più facile per risolvere il riferimento. E 'un po' patchworkish, ma funziona abbastanza bene.

Altri suggerimenti

Direi, che se le vostre storie di utenti hanno bisogno di più di un caso di bug - sono troppo grandi. Con buona astrazione delle funzionalità richieste, è possibile dividere le vostre storie utente a un più piccoli, che richiedono solo un caso ogni storia, e quindi pianificare e procedere in questo modo.

Si è cercato di utilizzare la @McWafflestix descrive, con collegamenti da casi al documento ufficiale (wiki) della storia dell'utente, ma dopo qualche tempo abbiamo scoperto, che la creazione di storie degli utenti più piccoli è meglio - porta anche ad una progettazione di applicazioni migliore, perché ogni utente storia è implementato come astratta possibile, fornendo una migliore verificabilità e manutenibilità del codice.

o meno uso di collegamenti di dipendenza in Bugzilla sono utilizzati per il monitoraggio storia, vi raccomando vivamente l'uso di una parola chiave su vostre storie. Usiamo 'storia'. L'uso di una parola chiave permette la flessibilità di facile monitoraggio storie contro insetti in alberi prodotto. Consiglio anche uso del tempo di monitoraggio nell'installazione Bugzilla; anche se il tempo viene monitorato solo su storie.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top