Come gestite il tracciamento dei bug in modo amichevole per programmatori e personale non tecnico? [chiuso]

In realtà stiamo usando Mantis per i nostri progetti. O dovrei dire "proviamo a usare". Il problema con tutti i bug tracker che conosco è che sono creati dai programmatori, per i programmatori. Quindi il design è inesistente o totalmente assurdo.

Naturalmente, come programmatore, posso usare mantis senza problemi, ma quanto è utile un tracker di bug quando tutte le persone coinvolte in un progetto le trovano così mal progettate e così difficili da usare che preferiscono creare documenti di Google con elenco puntato dei bug che hanno trovato o dei suggerimenti che potrebbero avere.

Sto per installare un forum, mi sembra una soluzione "nel mezzo" tra un tracker di bug e un semplice elenco puntato. Almeno un forum consente di monitorare e centralizzare una discussione su un suggerimento.

Nel caso in cui la mia preoccupazione non sia chiara, la mia domanda può essere riassunta in:

Come gestite la segnalazione di bug e suggerimenti verso l'utente non tecnico?

** Per coinvolgimento, NON intendo il cliente effettivo o l'utente finale. Sto pensando al nostro integratore, ai project manager e a coloro che sono coinvolti nel QA.

Siamo passati da Mantis a FogBugz (e Kiln) all'inizio di quest'anno, ma l'unica cosa che non abbiamo cambiato è stata quella di non consentire agli "utenti" di accedere al tracker dei bug. Alcuni degli altri capi dipartimento hanno accesso in sola lettura, ma onestamente sono manager e di solito se ne dimenticano entro un paio di settimane. Tutti gli utenti del nostro software hanno a che fare con 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. Questo impedisce al nostro sistema di essere ingombra 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 "dai programmatori", "per i programmatori" perché solo i "programmatori" lo utilizzano. Tutti gli altri si occupano direttamente di un essere umano.

(Nota, il nostro prodotto non è un prodotto restringente e tutti i nostri utenti sono impiegati diretti o lavorano con un impiegato del dipartimento di assistenza.)

Usiamo redmine per questo genere di cose. Il trucco chiave è che la maggior parte degli utenti non vede mai redmine: inviano semplicemente e-mail a support@example.com. Usando alcuni trucchi più avanzati - principalmente BCCcando il nostro account Redmine e includendo il numero # - possiamo mantenere gli aggiornamenti andando in Redmine. Per le persone più avanzate, abbiamo appena lasciato che usassero direttamente Redmine dato che è un po 'più moderno e facile da usare di quanto MANTIS non sia mai stato.

Attualmente stiamo usando MKS. Per i non programmatori, ho creato alcuni report e una dashboard con i riepiloghi a cui sono interessati. Significa che devo fare la configurazione iniziale, ma sono in grado di monitorare l'avanzamento dei difetti e il riepilogo generale dati per conto proprio, una volta che mostrerò loro come accedere ai report e alle dashboard. Avevano anche bisogno di un po 'di addestramento per modificare i loro biglietti, ma ci sarà sempre un po' di addestramento in testa. Fortunatamente, era proporzionato alle funzionalità coinvolte.

In secondo luogo Redmine, e uso personalmente The Bug Genie (sì, nome di cattivo gusto, ma ben progettato; se ti trovi in ​​un ambiente PHP e / o non riesci a eseguire Ruby per qualsiasi motivo) per il monitoraggio dei problemi che è amichevole a non- utenti tecnologici.

Oltre a ciò, una delle chiavi è che gli utenti finali non devono mai vedere più problemi di quelli che hanno inserito, per impostazione predefinita (facoltativamente, potresti avere la capacità di ricerca per evitare ticket duplicati, ma ciò dipende dalle tue esigenze e impostazioni). Vedere tutti i problemi ingombrerà semplicemente l'interfaccia e confonderà l'utente finale. Gli utenti in generale dovrebbero vedere solo ciò che devono vedere, quindi i project manager vedrebbero problemi solo per i progetti che controllano, per esempio. Come altri hanno già detto, per gli utenti finali, più è semplice effettuare l'invio dei biglietti, meglio è. Punti bonus se puoi avere l'invio del biglietto che non richiede nemmeno l'interfaccia utente del tracker (tramite e-mail o tramite un semplice modulo che ha solo i campi richiesti per inviare il biglietto).

Utilizziamo "le funzionalità di gestione del ciclo di vita delle applicazioni di Visual Studio", precedentemente note 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 sarà 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 - modificando la priorità, aggiornando le descrizioni, assegnando a qualcun altro, qualunque cosa - e quindi quando il file torna a un computer collegato a TFS, puoi premere Pubblica e le modifiche tornano nel repository. I programmatori lavorano con 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

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

Se si parla di personale addetto al controllo qualità / PM, è necessario valutare vari strumenti di tracciamento aperti e chiusi. Quelli che hanno la capacità di impostare build, ecc. Sono buoni, in modo che le persone di QA / PM possano mettere i biglietti contro una build specifica e quando risolvi un problema possono sapere in quale build testarla.

La maggior parte degli strumenti di proprietà che ho usato sono in realtà più sintonizzati per i non programmatori che per i programmatori. StarTeam è stato uno che ha funzionato abbastanza bene per me, ma non so se sia ancora in circolazione. Se lo desideri, puoi personalizzare i campi e simili. Assicurati solo che non esagerino con quello.

Se si parla di utenti finali, è necessario esaminare il software dell'help desk e fare in modo che il personale dell'helpdesk si intensifichi allo strumento di bug secondo necessità.