Utilizzo di software di tracciamento dei bug / tracciamento dei problemi per discutere domande di progettazione, nuovi strumenti ecc

Qualcuno ha esperienza con l'uso di un software di tracciamento dei bug / tracking dei problemi come bugzilla, mantis o JIRA non solo per bug o attività, ma per avviare e mantenere discussioni che alla fine portano a una decisione?

Ad esempio, uno sviluppatore ritiene che tutti i campi protetti debbano essere aboliti e modificati in campi privati ​​con metodi protetti che vi accedono. Non è una sua chiamata e vorrebbe discuterne. Normalmente solleva il punto nella prossima riunione degli sviluppatori al termine della quale viene presa una decisione. Invece, la mia idea era che aprisse un problema di un certo tipo "decisione" e descrivesse il suo intento come normalmente si descriverebbe un bug o un'attività.

Altri sviluppatori possono fare commenti se ne hanno voglia e alla fine il problema viene chiuso come "accettato" o "negato".

I vantaggi che vedo in questo:

• Comunicazione asincrona: nessuno è costretto a esprimere la propria opinione in una riunione quando non ha ancora avuto il tempo di supervisionare tutte le ramificazioni di tale decisione.
• Registro scritto delle considerazioni che portano a una decisione. Se uno in seguito solleva di nuovo quella domanda, può farvi riferimento.
• È possibile stabilire relazioni con altre questioni, ad esempio un'attività può essere seguita da una decisione.
• L'integrazione con il software di controllo della versione, ad esempio un commit, può essere ricondotta a una decisione.

svantaggi:

• Forte odore di un martello d'oro: il software di localizzazione dei problemi viene normalmente utilizzato per tracciare oggetti utilizzabili
• Il sovraccarico organizzativo può essere sproporzionato: invece di un piccolo discorso informale si deve comunicare le proprie idee in forma scritta

Il modo in cui lavoriamo, il monitoraggio dei problemi dovrebbe tenere traccia di tutti i problemi. Non sappiamo quali problemi siano risolvibili fino a quando non saranno stati analizzati. Se il sistema di tracciamento contiene solo problemi risolvibili, è probabile che vengano sottoposti a triage troppo presto, il che significa che qualsiasi discussione e decisione viene persa. Adottiamo l'approccio in cui ogni cosa dovrebbe entrare (nel nostro flusso di lavoro comunque), poiché altrimenti i problemi possono essere sollevati ripetutamente senza visibilità.

Abbiamo una categoria nella nostra implementazione di Jira per "Rischio", quindi stiamo usando Jira per tracciare elementi che non sono utilizzabili, ma hanno la possibilità di mettere a repentaglio il software in qualche modo. La discussione sull'oggetto viene tracciata e una volta che il rischio è scomparso (o mitigato) il problema è chiuso. L'esempio che hai fornito potrebbe facilmente andare nella categoria Rischio.

È importante che cose come questa siano discusse e monitorate e la decisione registrata. Quando lo sviluppatore risolve nuovamente il problema in pochi mesi, la risposta "Chiesto e risposto" ha una giustificazione.

Correggimi se sbaglio; ma penso che ciò di cui stai parlando sia: "Posso / come usare i sistemi di tracciamento dei bug / tracciamento dei problemi per fare anche il" tracciamento delle decisioni ". Mi manca o mi manca qualcosa?

All'inizio direi che questa è davvero un'ottima idea. Sebbene non lo utilizziamo esattamente come detto, ha senso che lo utilizziamo ai fini del monitoraggio. Nel nostro caso, un lungo thread di e-mail - più come un forum / mailing list è seguito.

Tuttavia, la tua domanda in senso lato riguarda come prendere (e gestire) le decisioni in modo efficace e collegare le implicazioni del lavoro alle decisioni prese che portano a intuizioni migliori.

Come ho già detto, può essere un'ottima idea se ciò aiuta le persone. Niente di sbagliato. Ma per prendere / gestire le decisioni in modo efficace sono necessarie poche cose concrete.

1. È vero che la maggior parte delle decisioni dovrebbero essere basate su uno sforzo inclusivo di ampia portata in modo tale che tutti gli aspetti importanti siano coperti e ponderati in modo adeguato prima che le decisioni siano basate. Pertanto, qualunque strumento tu abbia utilizzato deve aver consentito l'accesso trasparente alle informazioni a tutti gli interessati. Hai ragione nel dire che la modalità asincrona di trasmettere e raccogliere informazioni aiuta perché le persone possono mettere in tempo prima di dare suggerimenti. Se vengono chieste risposte anticipate , in genere durante le riunioni, il giudizio potrebbe non essere equo rispetto alla stessa persona con compiti sufficienti.

2. Tuttavia, ciò non significa necessariamente "pura democrazia" in cui ogni voto è uguale. In generale, la persona che prende le decisioni dovrebbe essere una o poche - e mentre hanno preso tutte le opinioni, devono essere individualmente responsabili delle decisioni e non di tutte le persone che hanno espresso le loro opinioni.

3. La maggior parte delle decisioni deve essere attuabile. Questo potrebbe trovare difficile evitare contraddizioni; ma il fatto che le decisioni non siano attuabili e solo soggettive implica la possibilità di interpretazioni future (errate).

4. È importante classificare il livello e l'ambito della decisione. Ancora più importante, dobbiamo identificare se stiamo discutendo di problemi di progettazione specifici o aspetti specifici del codice, aspetti dei processi o questi problemi relativi alla pianificazione e al monitoraggio del progetto? Abbastanza spesso quando i problemi colpiscono da un codice di produzione - tutti questi sono applicabili, ma dobbiamo essere in grado di distinguere tutti i diversi aspetti e indipendentemente per essere in grado di gestire efficacemente queste decisioni.

5. A volte le decisioni potrebbero essere se utilizziamo determinati sistemi o ruoli e responsabilità per gli individui; potrebbe essere difficile mettere insieme queste decisioni a codificare decisioni specifiche su un forum di tipo bacheca.

6. Solo aneddoti aggiuntivi; ogni team deve inserire le revisioni del codice e le revisioni del progetto come un processo autonomo, che coprirà in modo esauriente molte questioni come quelle citate. Devono sapere se le decisioni di tracciamento riguardano o meno altre cose.

Una buona pratica decisionale implica molta disciplina su come riunire le informazioni e garantire che le decisioni vengano seguite attraverso le implementazioni con lo spirito giusto.

Uno strumento può solo aiutare a rendere le informazioni più presentabili non oltre; ma potrebbe essere di grande aiuto se funziona per te.

FogBugz è la strada da percorrere. Non è gratuito Le nuove funzionalità rendono ancora più semplice l'implementazione di una metodologia agile.

Un modo più semplice e gratuito per andare sarebbe Asana.

Indipendentemente dallo strumento utilizzato, la comunicazione di gruppo è la più importante per facilitare un progetto di successo.