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

12

Qualcuno ha esperienza nell'usare un software di tracciamento di bug / bug-bug, 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 pensa che tutti i campi protetti dovrebbero essere aboliti e modificati in campi privati con metodi protetti che li accedano. Non è la sua chiamata, e vorrebbe discuterne. Normalmente egli porta il punto nel prossimo incontro degli sviluppatori al termine del quale viene presa una decisione. Invece, la mia idea era che lui aprisse un problema di un certo tipo di "decisione" e descriveva il suo intento come se normalmente uno descrivesse un bug o un compito.

Altri sviluppatori possono fare i loro 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 sua opinione in una riunione quando non hanno ancora il tempo di controllare tutte le implicazioni di detta decisione.
  • Registro scritto di considerazioni che portano a una decisione. Se in un secondo momento si pone nuovamente questa domanda, può esserne indirizzata.
  • È possibile stabilire relazioni con altri problemi, ad es. un compito può essere ricondotto a una decisione.
  • Integrazione con il software di controllo della versione, ad es. un commit può essere ricondotto a una decisione.

Svantaggi:

  • Odore pesante di un martello d'oro: il software di tracciamento delle domande normalmente viene utilizzato per tracciare gli oggetti utilizzabili
  • Il sovraccarico organizzativo potrebbe essere sproporzionato: invece di un piccolo discorso informale, è necessario comunicare le sue idee in forma scritta
posta Ozan 04.12.2011 - 22:59
fonte

3 risposte

8

Il modo in cui lavoriamo, emettere il monitoraggio dovrebbe tenere traccia di tutti i problemi. Non sappiamo quali problemi siano perseguibili finché non sono stati analizzati. Se il sistema di tracciamento presenta solo problemi utilizzabili, è probabile che vengano triaging troppo presto, il che significa che qualsiasi discussione e decisione vengono perse. Prendiamo l'approccio in cui ogni cosa dovrebbe entrare (nel nostro flusso di lavoro comunque), poiché altrimenti le questioni possono essere ripetutamente sollevate senza visibilità.

Abbiamo una categoria nella nostra implementazione di Jira per "Rischio", quindi usiamo Jira per tenere traccia di elementi che non sono utilizzabili, ma che hanno la capacità di mettere a repentaglio il software in qualche modo. La discussione sull'elemento viene tracciata e una volta che il rischio è sparito (o mitigato) il problema è chiuso. L'esempio che hai fornito potrebbe facilmente entrare nella categoria di rischio.

È importante che cose come questa siano discusse e tracciate e che la decisione sia registrata. Quando lo sviluppatore ribatte il problema tra qualche mese, la risposta "Chiede e risponde" ha una giustificazione.

    
risposta data 04.12.2011 - 23:38
fonte
3

Correggimi se sbaglio; ma penso che quello di cui stai parlando sia: "Posso / Come usare i sistemi di tracciamento dei bug e di tracciamento dei problemi per fare anche il" Tracciamento delle decisioni ". È o mi manca qualcosa?

All'inizio direi che è davvero una grande idea. Anche se non lo usiamo nel modo esatto detto, ha senso che lo usiamo allo scopo di tracciare. Nel nostro caso, una lunga discussione di email - più come un forum / mailing list è seguita.

Tuttavia, la tua domanda in un senso più ampio riguarda il modo in cui prendere (e gestire) le decisioni in modo efficace e collegare le implicazioni del lavoro alle decisioni prese che portano a intuizioni migliori.

Come ho detto, può essere una bella idea se questo aiuti le persone. Niente di sbagliato in proposito. Ma per prendere decisioni in modo efficace / maneggevole servono poche cose concrete.

  1. È vero che la maggior parte delle decisioni dovrebbe essere uno sforzo inclusivo basato su un'ampia scala, in modo che tutti gli aspetti importanti siano trattati e valutati adeguatamente prima di prendere le decisioni. Quindi qualunque strumento tu usi deve aver permesso un accesso trasparente alle informazioni a tutti gli interessati. Hai ragione che la modalità asincrona di trasmissione e raccolta delle informazioni aiuta perché le persone possono dedicare tempo prima di inserire suggerimenti. Se ti viene chiesto di rispondere in anticipo - in genere durante le riunioni, il giudizio potrebbe non essere altrettanto valido rispetto alla stessa persona con abbastanza compiti a casa.

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

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

  4. È importante classificare il livello e l'ambito della decisione. La cosa più importante è che dobbiamo identificare se stiamo discutendo problemi di progettazione specifici o aspetti specifici del codice, aspetto dei processi o sono questi problemi di pianificazione e monitoraggio dei progetti? 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 in modo indipendente per essere in grado di gestire queste decisioni in modo efficace.

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

  6. Solo un aneddoto aggiuntivo; ogni team deve mettere le revisioni del codice e le revisioni del design come un processo da solo - che coprirà in modo esauriente molti problemi come quelli che hai citato. Devono o meno decidere se il tracciamento delle decisioni riguarda o meno altre cose.

Un buon processo decisionale implica molta disciplina sul modo in cui raccogliamo le informazioni e assicuriamo che le decisioni siano seguite con le implementazioni con lo spirito giusto.

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

    
risposta data 05.12.2011 - 08:01
fonte
1

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

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

Indipendentemente dallo strumento che utilizzi, la comunicazione di squadra è la più importante per facilitare un progetto di successo.

    
risposta data 05.12.2011 - 19:55
fonte

Leggi altre domande sui tag