Come utilizzare TFS come sistema di tracciamento delle query?

1

Utilizziamo già tfs per la gestione dei difetti nel codice, ecc. Abbiamo anche bisogno di un modo per "capire il dominio e i requisiti dei prodotti". Normalmente, senza tfs, scambiamo email con i consulenti e rispondiamo alle domande / domande. Se si tratta di un'implementazione di funzionalità, a volte "troviamo" conflitti nell'implementazione stessa. E quando ciò accade la UserSory viene modificata e il miglioramento / bug come da ciò che viene generato in TFS.

A volte è fondamentale tornare alle decisioni che abbiamo preso o alle domande alle quali volevamo rispondere. Quindi dobbiamo essere in grado di tenere traccia di come questa "idea del requisito" o quella "query in questione" si sono evolute.

Quindi com'è possibile utilizzare TFS per tenere traccia di tutto questo? Solleviamo un oggetto "problema" per questo? O solleviamo un elemento "bug"?

Le cose principali che cerchiamo idealmente in un sistema di tracciamento delle query sono le seguenti:

  1. Area: può essere un modulo, un sottomodulo, un dominio. A volte questo può essere "Generale" - per indirizzare roba relativa al dominio, o, evento più granulare per indirizzare moduli, sotto-moduli. Prendiamo il caso di quest'ultimo, se stessimo rintracciando questo in fogli Excel, scriveremmo module1,submodule2 ; cioè in una moda separata da virgole. Le cose che vorrei qui sono poter cercare tutte le query relative a submodule2 in futuro.
  2. Risposte: si tratta di una registrazione di conversazioni tra il consulente e qualsiasi altro stakeholder. Per un caso semplice, sarebbe solo paragrafi. Ogni para inizia con un nome e una data racchiusi tra parentesi e la risposta che segue ... ogni para sarebbe come un thread - molto simile a un thread del forum
  3. Azione intrapresa: vorremmo sapere come è stata chiusa la query, quali sono stati gli input forniti, quali sono stati i cambiamenti a causa di ciò, ecc. ecc.

Questi sono campi che penso che mi servirebbero in un sistema del genere a parte alcuni aspetti ovvi come lo stato, l'indirizzo, il risanamento, ecc. Sono aperto a tutti gli altri campi che sono un po 'importanti. Per riassumere la mia domanda: come possiamo gestire le "query" nel sistema? Dove dovremmo idealmente memorizzare i dati relativi a quei tre campi che ho menzionato sopra (per esempio è saggio memorizzare le risposte nel tag history presumendo che stiamo aprendo un bug per la query)?

    
posta deostroll 03.10.2012 - 07:05
fonte

1 risposta

3

Sono quasi arrivato, implementando la soluzione che sto per descrivere. La ragione per cui attualmente non sto usando è ... beh, oltre alla mia preferenza personale per altri sistemi di controllo delle versioni piuttosto che per TFS, è che l'azienda che lo utilizza ha trovato un software più adatto per questo.

In TFS, questo è facile da implementare. Se si desidera utilizzare "bug", "compito" o qualsiasi altro elemento è davvero irrilevante. Suggerirei Task su TFS OOB, ma puoi ridefinire e creare più tipi di elementi di lavoro che desideri. (Che è effettivamente utile per impostare campi predefiniti.)

Aree: Per quanto riguarda le aree, è possibile definirle in TFS e ognuna di queste. Il problema con TFS è che potresti non avere un elemento mappato su diverse aree. Se desideri definire le aree come moduli, sottomoduli, funzioni, ecc. Tutto ciò che funziona per te.

Come per le ricerche, è possibile utilizzare le query TFS per definire ricerche personalizzate che restituiranno tabelle o alberi di elementi di lavoro. Questi sono molto personalizzabili, utili e persino esportabili in diversi formati (Outlook, Excel con tabelle collegate, Progetto, ecc.) Ho fatto così tante volte e gli eventi programmati bruciano i grafici in Excel con query collegate da TFS.

Risposte: Se si desidera definire un tipo di oggetto di lavoro personalizzato, è possibile creare un campo di testo per questo, e forzarlo per essere completato prima che possa essere assegnato uno stato finito. Il problema qui è che non puoi anticipare quale numero di risposte potresti avere. Qui puoi definire il tuo set come una domanda e poi una risposta. O commenti / discussione e una risposta.

Se desideri avere più risposte (cioè una discussione), non so come adattarlo a TFS. Quello che ho fatto finora è di avere tutti gli utenti registrati nelle loro risposte nello stesso modo in cui hai descritto: data, nome e testo. Se qualcuno ha problemi con le risposte precedenti, hai ancora la cronologia dell'elemento di lavoro. A volte, riscrivere l'intero testo è persino desiderabile, per riassumere le cose.

Azione eseguita: In questo caso specifico, consiglierei l'aggiunta di un campo personalizzato, nel caso in cui ognuno di questi articoli ne abbia bisogno. Inoltre, potresti rendere l'ultima risposta, il che ha senso quando l'azione deve essere successivamente verificata da qualcun altro o può anche generare ulteriori commenti e correzioni.

Vista personale:

So che suona abbastanza hacky e sì, lo è. TFS può essere ampiamente personalizzato, ma a volte il flusso di lavoro che hai non si adatta correttamente al modo in cui funziona il sistema. Penso che questo sia uno di questi casi. Come ho descritto, l'abbiamo fatto funzionare, ma come ho detto all'inizio della mia risposta, un altro sistema che si adatta meglio alle tue esigenze è sempre un'opzione migliore.

    
risposta data 09.10.2012 - 05:21
fonte