¿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, luego el seguimiento de errores / características, etc ...

Ya que tenemos que elegir una plantilla de proceso para usar el control de código fuente (o cualquier cosa en TFS) , ¿qué tan bloqueados estamos con la decisión? Estoy buscando evitar tener que crear otro proyecto más adelante ( 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 que suceden las cosas:

1. Migramos nuestro código fuente. Elegimos la plantilla CMMI de Microsoft.
2. Creamos un nuevo elemento de trabajo (o nota de registro) que es un enlace simple a nuestro sistema de seguimiento de errores heredado.
3. Trabajamos por un tiempo.
4. Esperamos hasta que los poderes que sean (somos una empresa de software de tamaño decente) para elaborar un nuevo flujo de trabajo de desarrollo de TFS. Esto 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.

Lamentamos no haber esperado hasta que todas estas decisiones se hayan finalizado antes de utilizar TFS?

Answer 1

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

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

Sin embargo, si los poderes son los que deciden ir por un proceso de definición de procesos súper y crear mágicamente una nueva plantilla de proceso en 12 meses que quieren que uses, no se pierde por completo. Si descubre que desea crear un nuevo proyecto de equipo, siempre que esté en ese servidor (o en Project Collection en TFS 2010), puede derivar su código al nuevo proyecto de equipo (lo que significa que el historial es algo oculto 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 origen y luego mover las carpetas secundarias desde el proyecto del equipo anterior al nuevo. Esto preservará el historial perfectamente, ya que TFS mantiene el historial de movimientos en la misma instancia de TFS. Sin embargo, sus elementos de trabajo anteriores a la mudanza quedarán bloqueados en la plantilla de proceso anterior y deberá decidir si desea copiarlos o simplemente dejarlos para que se cierren naturalmente.

Obviamente, al usar TFS durante 12 meses en proyectos reales, cuando los poderes que te lleguen también estarán en una posición mucho mejor para saber cómo quieres que se vea tu nueva y brillante plantilla de proceso, y yo He encontrado a menudo que este es un ejercicio que nunca ocurre y la mayoría de las personas están felices de hacer retoques en los bordes de MSF Agile o elegir algo más prescriptivo como Scrum For Team System .

Espero que ayude,

Martin.