Blocco del modello di guida al processo TFS?

Question

Il mio team sta cercando di migrare molti dei nostri strumenti (SCM, tracciamento dei bug, build, test) su TFS. Stiamo valutando di spostare ciascun sistema in più fasi. Ad esempio, sposta prima il controllo del codice sorgente, quindi il rilevamento di bug / funzionalità, ecc ...

Dato che dobbiamo scegliere un modello di processo per utilizzare il controllo del codice sorgente (o qualsiasi altra cosa in TFS) quanto siamo bloccati nella decisione? Sto cercando di evitare di dover creare un altro progetto in un secondo momento ( o non è così male come penso che sarebbe?).

So che in teoria posso personalizzare tutto ciò che il modello di processo configura dopo il fatto (giusto?), ma quanto è fattibile in pratica?

Ecco come vedo accadere le cose:

1. Migriamo il nostro codice sorgente. Scegliamo il modello CMMI di Microsoft.
2. Creiamo un nuovo oggetto di lavoro (o nota di check-in) che è un semplice collegamento al nostro sistema di tracciamento dei bug legacy.
3. Lavoriamo per un po '.
4. Aspettiamo che i poteri che sono (siamo una società di software di dimensioni decenti) per elaborare un nuovo flusso di lavoro di sviluppo TFS. Potrebbe trattarsi di una semplice raccolta di nuovi elementi di lavoro o di un modello completamente nuovo che configura tutti i tipi di cose.
5. Cerchiamo di migrare il nostro progetto TFS su questo nuovo sistema senza perdere la nostra storia.

Ci dispiace non aver semplicemente aspettato che tutte queste decisioni fossero finalizzate prima di utilizzare TFS?

Answer 1

Quindi, hai ragione a pensare al tuo modello di processo in quanto esiste una certa quantità di "blocco" " tuttavia non è troppo grave. È come se fossi bloccato sul tuo modello di processo con miele piuttosto che super colla.

Personalmente, vorrei iniziare con il modello Agile di MSF. È molto più leggero e contiene meno oggetti di lavoro, quindi è più probabile che tu voglia aggiungere delle cose (molto facile in TFS, molto ben supportato) piuttosto che portarle via (più complicate e non del tutto soddisfacenti).

Tuttavia, se i poteri che decidono di abbandonare un processo di definizione del processo superbo e magicamente escogitano un nuovo modello di processo in 12 mesi che vogliono che tu usi, allora non è completamente perso. Se scopri di voler creare un nuovissimo progetto Team, purché sia ??su quel server (o Project Collection in TFS 2010), puoi ramificare il tuo codice sul nuovo progetto team (il che significa che la storia è in qualche modo oscurato nelle versioni correnti dei client TFS) oppure è possibile creare un nuovo progetto team con una cartella vuota per il controllo del codice sorgente e quindi spostare le cartelle secondarie dal vecchio progetto team al nuovo. Ciò conserverà perfettamente la cronologia poiché TFS mantiene la cronologia per gli spostamenti sulla stessa istanza TFS. Tuttavia, i tuoi oggetti di lavoro prima del trasloco rimarranno bloccati nel vecchio modello di processo e dovrai decidere se vuoi copiarli o lasciarli per chiuderli naturalmente.

Ovviamente, usando effettivamente TFS per 12 mesi su progetti reali, quando i poteri che verranno a bussare sarai anche in una posizione molto migliore per sapere come vuoi che il tuo nuovo modello di processo lucido assomigli - e io ho spesso scoperto che questo è un esercizio che non accade mai e la maggior parte delle persone è felice di armeggiare ai bordi di MSF Agile o scegliere qualcosa di più prescrittivo come Scrum For Team System .

Spero che aiuti,

Martin.