Come gestisci il bug tracking in modo amichevole con i programmatori e il personale non tecnico? [chiuso]

Siamo passati da Mantis a FogBugz (e Kiln) all'inizio di quest'anno, ma l'unica cosa che non è stata modificata è che non permettiamo affatto agli "utenti" di accedere al bug tracker. Alcuni degli altri capi dipartimento hanno accesso di sola lettura, ma onestamente sono manager e di solito se ne dimenticano entro un paio di settimane. Gli utenti del nostro software si occupano di un singolo responsabile della risoluzione dei problemi che determina se si tratta di un problema di configurazione, errore dell'utente o bug del software. Questa persona funge quindi da gatekeeper per l'inserimento dei problemi reali in FogBugz. Ciò impedisce al nostro sistema di essere ingombro di problemi che non sono realmente rilevanti.

Quindi per rispondere alla tua vera domanda ... non è davvero un problema per noi che il software di tracciamento dei bug sia "programmato", "per programmatori" perché solo i "programmatori" lo utilizzano. Tutti gli altri si occupano direttamente di un umano.

(Nota, il nostro prodotto non è un ritiro e tutti i nostri utenti sono dipendenti diretti o lavorano con un dipendente nel reparto assistenza.)

Usiamo redmine per questo genere di cose. Il trucco chiave è la maggior parte degli utenti mai vedere redmine: inviano semplicemente e-mail a [email protected]. Usando alcuni trucchi più avanzati - principalmente BCCing sul nostro account redmine e includendo il numero # - possiamo mantenere gli aggiornamenti in redmine. Per persone più avanzate, li lasciamo usare direttamente redmine dato che è un po 'più moderno e user-friendly di MANTIS.

Attualmente stiamo usando MKS. Per i non programmatori, ho impostato alcuni rapporti e una dashboard con i riepiloghi a cui sono interessati. Significa che devo eseguire la configurazione iniziale, ma sono in grado di monitorare l'andamento dei difetti e il riepilogo generale dati da soli, una volta mostrati loro come accedere ai report e ai dashboard. Avevano anche bisogno di un po 'di formazione per modificare i loro ticket, ma ci sarà sempre qualche sovraccarico di formazione. Fortunatamente, era proporzionato alle funzionalità coinvolte.

I second Redmine, e uso personalmente The Bug Genie (sì, nome di formaggio, ma ben progettato; se sei in un ambiente PHP e / o non può eseguire Ruby per qualsiasi motivo) per il monitoraggio dei problemi che è amichevole per gli utenti non tecnologici.

Oltre a ciò, una delle chiavi è che gli utenti finali non hanno mai bisogno di vedere più problemi di quelli che inseriscono, di default (opzionalmente, si potrebbe avere la possibilità di cercare di evitare duplicati dei biglietti, ma ciò dipende dalle esigenze e dalla configurazione ). Vedere tutti i problemi limiterà l'interfaccia e confonderà l'utente finale. Gli utenti in generale dovrebbero vedere solo ciò che devono vedere, quindi i project manager vedrebbero solo i problemi per i progetti che controllano, per esempio. Come altri hanno già detto, per gli utenti finali, più semplice è la possibilità di presentare l'invio dei biglietti, meglio è. Punti bonus se puoi avere l'invio del biglietto che non richiede nemmeno l'interfaccia utente del tracker (sia via email, sia attraverso un semplice modulo che ha solo i campi necessari per inviare il ticket).

Utilizziamo "le funzionalità di Application Lifecycle Management di Visual Studio", precedentemente noto come Team Systems. Un grande vantaggio per noi è che puoi esportare un risultato di una query (come "tutti i requisiti" o "tutti i bug con un pri 2 o inferiore che non saranno nella prossima versione") in un foglio di calcolo o in un documento di progetto. I project manager, i rappresentanti degli utenti finali, le parti interessate ecc. Possono modificare questi file - cambiando la priorità, aggiornando le descrizioni, assegnando a qualcun altro, qualunque cosa - e quando il file ritorna su una macchina collegata a TFS, puoi premere Pubblica e le modifiche tornano nel repository. I programmatori lavorano con gli oggetti di lavoro direttamente da Visual Studio, ma i non programmatori non si avvicinano mai a VS. Inoltre c'è un sito sharepoint per ogni progetto TFS in modo da non dover spedire i documenti in giro se le persone si trovano tutti sulla stessa rete.

Forse non è un'opzione se non sei un negozio VS, ma vale la pena di pensarci se lo sei.

Se si parla di personale QA / PM, è necessario valutare vari strumenti di tracciamento dell'origine aperta e chiusa. Quelli che hanno la capacità di impostare build, ecc. Sono buoni, in modo che le persone del QA / PM possano mettere i ticket contro una build specifica e quando si risolve un problema possono sapere quale build per testarlo.

La maggior parte degli strumenti di proprietà che ho usato sono in realtà più sintonizzati per i non programmatori che per i programmatori. StarTeam era uno che funzionava abbastanza bene per me, ma non so se è ancora in circolazione. Puoi personalizzare i campi e così se vuoi. Assicurati solo che non esagerare con quello.

Se si parla di utenti finali, è necessario consultare il software dell'help desk e chiedere al personale dell'help desk di passare allo strumento di bug in base alle esigenze.