Utilizzare TFS per tenere traccia dei bug dal supporto di produzione

18

Mi sono appena trasferito in una nuova società e stanno usando TFS 2010 (2012 tra un paio di mesi) come sistema di controllo della versione e recentemente hanno iniziato a usarlo come sistema di tracciamento del lavoro per gli sviluppatori.

Tuttavia, non sembra esserci un sistema di tracciamento dei bug per l'utilizzo da parte di persone al di fuori di sviluppo e test. Il supporto alla produzione sta ricevendo segnalazioni di problemi, risolvendoli al volo e riferendo ai propri utenti al momento. Questo deve essere cambiato, ma non voglio davvero avere un sistema sperate per il monitoraggio dei bug e il monitoraggio del lavoro degli sviluppatori.

Esiste un modo per creare un modo molto leggero di inserire i bug in TFS in modo simile a FogBugz? Accedere a TFS per compilare una segnalazione di bug sembra essere molto più pesante e devi associarlo a una particolare applicazione. Il supporto potrebbe essere in grado di fare questo, ma voglio essere in grado di valutare l'elemento e potenzialmente cambiare l'associazione in qualcosa di diverso da un'applicazione.

Ho usato FogBugz in passato e quando aggiungo un bug, puoi aggiungere un po '/ quanto vuoi all'elemento in modo che sia almeno registrato e in seguito puoi rimbalzarlo per ottenere maggiori informazioni quando vieni a triage il biglietto .

issue-tracking team-foundation-server

— Richard Hooper
fonte

Vale la pena notare che se si utilizza TFS e tutti gli utenti dispongono di un account di dominio Windows, non devono mai "accedere a TFS". Accedendo al portale Web TFS del tuo team li accederà automaticamente usando le credenziali di dominio per l'utente corrente di Windows.

— 17 del 26

Come hai finito per risolvere questo? Hanno lo stesso problema oggi, hai bisogno di un sistema di ticketing, hanno TFS2013 on-prem. Quello che voglio è UserVoice, ma dovrei andare da TFS on-prem in VSO per ottenere tale integrazione.

— EJA

1

@EJA - Alla fine abbiamo deciso che dovevamo seguire un processo per far sorgere il problema attraverso una casella di posta elettronica che viene raccolta dai tester in modo che possano documentare completamente il problema, i passaggi per la ri-produzione, l'ambiente, ecc. e quindi il tester può aggiungere il bug a TFS nel formato corretto. Sebbene sarebbe stato bello che gli utenti fossero stati in grado di aggiungerli direttamente, ci siamo resi conto che è improbabile che gli utenti forniscano agli sviluppatori tutti i dettagli di cui avrebbero bisogno e non cercherebbero la duplicazione del problema.

— Richard Hooper,

6

Dipende in gran parte da quali campi si desidera, come indicato da 17 su 26: TFS è altamente personalizzabile. Il motivo per cui vorrei fare questo invece di usare qualcosa come JIRA è che hai una visione unica di ciò su cui stanno lavorando i tuoi sviluppatori, invece di dover aggregare due sistemi.

TFS ha anche una pianificazione della capacità delle risorse e se non stai mostrando difetti di produzione nella tua pianificazione (e occupano una frazione significativa del tuo tempo), non stai davvero pianificando la tua capacità. Direi infatti che questa è una soluzione ideale per i team in cui gli sviluppatori utilizzano TFS e supportano la produzione (ad esempio DevOps).

Ciò non significa che non puoi utilizzare altri strumenti per il principale lavoro di supporto alla produzione / ITIL, devi solo assicurarti che si integrino, manualmente o preferibilmente automaticamente. La maggior parte di questi strumenti ti consente di inserire hook personalizzati, e TFS sicuramente lo fa.

Comunque, alla domanda principale. Uso i modelli TFS CMMI (che funzionano davvero bene con Agile BTW) e ho appena aggiunto un singolo campo a uno dei menu a discesa.

Ecco i passaggi:

Installa utensili elettrici TFS

Aprire il modello di articoli di lavoro dal server

Apri modello oggetto di lavoro dal server

Apri modello di bug

Modifica il campo Disciplina

Il campo della disciplina è il "tipo" di lavoro relativo al difetto. I valori standard sono:

Analisi
L'esperienza utente
Formazione dell'utente
Sviluppo
Test

Quello che stiamo per fare è aggiungere "Produzione" a quell'elenco. Innanzitutto, modifica il campo Disciplina:

Modifica disciplina

Quindi, fai clic sulla scheda Regole e modifica la regola ALLOWEDVALUES:

inserisci qui la descrizione dell'immagine

Quindi, fai clic su "Nuovo" e aggiungi "Produzione" come uno dei valori.

inserisci qui la descrizione dell'immagine

Fai clic su "OK" ripetutamente fino a quando non torni all'elenco dei campi.

Salva il modello oggetto di lavoro

OK, ora hai finito. Puoi creare nuovi bug e indicarne il tipo come Produzione. Creerei anche alcune query sugli oggetti di lavoro che esaminano i difetti di produzione e le aggiungerei ai tuoi articoli aggiunti. Infine, guarda le query esistenti sui bug e forse modifica il loro ordine in modo che i bug "Production" vengano visualizzati per primi (se possibile).

— Sean Hederman
fonte

Fantastico, hai personalizzato TFS per consentire agli sviluppatori di vedere "bug di produzione" ... come possono entrare e gestirli il team di produzione (che non fa parte del team di sviluppo e non ha VS)?

— gbjbaanb,

4

Bene, per cominciare, possono accedere a TFS tramite l'interfaccia web, usando la licenza Stakeholder che è gratuita. Nella nostra organizzazione monitoriamo gli incidenti di produzione tramite un sistema basato su ITIL, ma lo stiamo integrando automaticamente con TFS, come indicato dalla mia risposta nel terzo paragrafo.

— Sean Hederman,

4

No, è vero - il principale ALM di Microsoft non è davvero utile al di fuori di Visual Studio e dei team di sviluppo.

È possibile accedere agli elementi di lavoro utilizzando Team Explorer (che è una versione molto ridotta di VS) o accedervi tramite il sito Web TFS. Né sono opzioni particolarmente buone in quanto i campi di bug ricordano antichi tracker di bug "enterprise" che ho avuto la sfortuna di usare in passato.

Non esiste una vera distinzione tra i bug in TFS: esiste solo il singolo tracker che si filtra utilizzando un campo nell'elemento stesso, quindi utilizzare un campo categoria e quindi creare un report che mostri solo un particolare tipo di categoria. Penso che sia l'unica opzione realistica con TFS.

Se vuoi il rilevamento di problemi esterni, penso che TFS sia una scelta sbagliata, stai meglio usando qualcosa come Jira o Redmine e utilizzandolo per gestire i bug: le loro interfacce sono molto, molto più belle e più facili da usare rispetto a TFS. Mi è particolarmente piaciuto il modo in cui puoi inviare un'e-mail a Redmine e questo crea un nuovo problema per te, che era una funzionalità di usabilità ideale per i lavoratori fuori sede.

— gbjbaanb
fonte

2

I campi in TFS sono completamente personalizzabili e le impostazioni predefinite dipendono dai modelli di processo scelti durante la configurazione di TFS. Per impostazione predefinita, il modello di scrum include articoli, attività e bug relativi all'arretrato del prodotto. Ogni tipo di elemento di lavoro ha diversi campi appropriati per il lavoro.

— 17 del 26

@ 17of26 Lo so - i campi che usi sono completamente personalizzabili, ma lo è anche Excel se lo hai usato come bugtracker. Il problema dei PO era che il modello fornisce solo quei tipi di elementi di lavoro - e non puoi averne di diversi (ad es. Una richiesta di funzionalità o un bug esterno), devi personalizzare (o copiare) uno di quelli esistenti e usarlo - che a sua volta dà origine a una grande quantità di configurazione che devi fare per adattarla ai tuoi flussi di lavoro. Quindi, come hai più bug tracker?

— gbjbaanb,

Pensavo che l'OP non volesse più bug tracker e stavo solo cercando di capire come i non-sviluppatori potevano interagire con il tracciamento degli oggetti di lavoro TFS che gli sviluppatori stavano già usando (che per me è come vorresti fare le cose) .

— 17 del 26

questo è tutto - non puoi davvero, o almeno non così facilmente come puoi usare altri strumenti come Redmine o Fogbugz che hanno migliori funzionalità di localizzazione. TFS ha elementi come il tracciamento dei bug aggiunti ad esso, ma è ancora principalmente uno strumento solo per sviluppatori. Redmine, ad esempio, ha più tracker solo in quanto vi sono più viste di un singolo DB tracker. Penso che sia più ciò che vuole che usare diversi strumenti (ad esempio usando TFS per sviluppatori e Fogbugz per il personale di supporto, per esempio).

— gbjbaanb,

1

Puoi aggiungere tutti i tipi di elementi di lavoro personalizzati che desideri.

— MrHinsh - Martin Hinshelwood,

3

Gli utenti non sviluppatori possono accedere al sistema di tracciamento degli oggetti di lavoro TFS utilizzando un browser Web per accedere al portale del progetto team. Per trovare l'URL, vai su Team-> Mostra il portale del progetto in Visual Studio. Da lì, chiunque abbia le autorizzazioni può sfogliare, creare o modificare elementi di lavoro. Possono anche generare tutti i tipi di rapporti per esaminare lo stato delle cose.

I tipi di elementi di lavoro disponibili e i campi negli elementi di lavoro variano in base alla configurazione di TFS (principalmente in base a quali modelli di processo sono stati scelti).

Le informazioni richieste per inserire un bug dipendono anche dalla configurazione di TFS. Nel nostro caso, abbiamo bisogno di un titolo, passaggi per riprodurre e la build in cui è stato trovato. Il sistema di tracciamento degli oggetti di lavoro TFS è molto potente e flessibile. Può essere complicato o semplice come lo desideri: tutto dipende da come lo hai impostato.

— 17 di 26
fonte

3

Questo post sul blog di Microsoft descrive miglioramenti pianificati in TFS che dovrebbero aiutare a supportare i costi generali inferiori:

Nuovo modulo per elementi di lavoro più semplice per gli occhi e include opzioni di discussione e menzione, simili a Facebook e Twitter.
Campi personalizzati
Supporto Kanban migliorato, ad esempio attività di aggiunta rapida su un elemento di lavoro.
Menziona anche dashboard e metriche.

— Bernard Vander Beken
fonte