¿Bloqueo de plantilla de guía de proceso TFS?

Question

Mi equipo está buscando migrar muchas de nuestras herramientas (SCM, seguimiento de errores, compilaciones, pruebas) a TFS. Estamos considerando mover cada sistema en etapas. Por ejemplo, mueva primero el control de origen, seguimiento de fallos/características, etc.

Como tenemos que elegir una plantilla de proceso para usar el control de código fuente (o cualquier cosa en TFS) ¿Qué tan encerrados estamos con la decisión? Estoy buscando evitar tener que crear otro proyecto más tarde (¿o no es tan malo como creo que sería?).

Sé que puedo, en teoría, personalizar todo lo que la plantilla de proceso configura después del hecho (¿verdad?), Pero ¿qué tan factible es esto en la práctica?

Así es como veo las cosas que suceden:

1. migramos nuestro código fuente. Elegimos la plantilla CMMI de Microsoft.
2. Creamos un nuevo elemento de trabajo (o nota de check-in) que es un enlace simple a nuestro sistema de seguimiento de errores heredado.
3. Trabajamos por un tiempo.
4. Esperamos hasta los poderes que sean (somos una compañía de software de tamaño decente) para resolver un nuevo flujo de trabajo de desarrollo de TFS. Esta puede ser una simple colección de nuevos elementos de trabajo o una plantilla completamente nueva que configura todo tipo de cosas.
5. Intentamos migrar nuestro proyecto TFS a este nuevo sistema sin perder nuestro historial.

¿Sentimos no haber esperado hasta que todas estas decisiones se hayan finalizado antes de usar TFS?

Answer 1

Por lo tanto, tiene razón al pensar en su plantilla de proceso, ya que hay una cierta cantidad de "bloqueo", sin embargo, no es demasiado grave. Es como si estuvieras atrapado en tu plantilla de proceso con miel en lugar de súper pegamento.

Personalmente, comenzaría con la plantilla MSF Agile. Es mucho más liviano y contiene menos elementos de trabajo, por lo que es más probable que quiera agregarle cosas (muy fácil en TFS, muy bien respaldado) en lugar de quitárselos (más complicado y no del todo satisfactorio).

Sin embargo, si los poderes deciden bajar un proceso de definición de proceso superior y mágicamente presentar una nueva plantilla de proceso dentro de 12 meses que desean que use, entonces no se pierde por completo. Si encuentra que desea crear un nuevo proyecto de equipo, siempre y cuando esté en ese servidor (o Project Collection en TFS 2010), puede transferir su código al nuevo proyecto de equipo (lo que significa que la historia es un tanto oscurecido en las versiones actuales de los clientes TFS) o puede crear un nuevo proyecto de equipo con una carpeta vacía para el control de código fuente y luego mover las carpetas secundarias del proyecto antiguo del equipo al nuevo. Esto preservará la historia perfectamente ya que TFS mantiene el historial de movimientos en la misma instancia de TFS. Sin embargo, sus elementos de trabajo antes del traslado quedarán atrapados en la plantilla de proceso anterior y deberá decidir si desea copiarlos o simplemente dejarlos para que se cierren de forma natural.

Obviamente, al utilizar TFS durante 12 meses en proyectos reales, cuando los poderes que se ciernen también estarán en una posición mucho mejor para saber cómo se verá su nueva plantilla de proceso brillante, y A menudo he descubierto que este es un ejercicio que nunca sucede y la mayoría de las personas están contentas jugando con los bordes de MSF Agile o eligiendo algo más preceptivo como Scrum For Team System.

Espero que ayude,

Martin.