Pregunta

Estamos migrando hacia TFS y hemos decidido en base a los comentarios en línea para estructurar TFS como un proyecto por equipo, siendo cada "proyecto real" un área (y cada lanzamiento de una iteración).

Esto significa que nuestra estructura TFS es algo así:

Apps Team
  - WinForms Project
  - WPF Project
  - Embedded Project
  - WPF Project 2

Web Team
  - Admin Site
  - Client Site
  - Client Site 2

DB Team
  - General Scripts
  - DB 1
  - DB 2

Sin embargo, desde una perspectiva de gestión, es tedioso revisar los informes de cada equipo individualmente.

Me pregunto a aquellos con experiencia en el uso de esta estructura, ¿Cuál de estas opciones (u otras opciones) ha utilizado con éxito?

1) Mueva a todos los equipos al mismo proyecto

  • Pro: ningún informe cambia
  • Pro: conciencia de equipo cruzado
  • Con: desorden
  • Con: quizás seguridad

2) Cambie todos los informes para ser de equipo cruzado

  • Pro: los equipos aún pueden tener proyectos propios
  • Con: tener que cambiar y sincronizar todos los informes en todos los proyectos
  • Con: los informes se vuelven menos útiles para los equipos individuales (aún pueden personalizar copias)
  • Con: los equipos deben compartir la misma plantilla de proceso (un problema no para mí)

3) Configurar un proyecto TFS solo para la administración que contiene informes de equipo cruzado

  • Pro: Solo tiene que cambiar un proyecto TFS
  • Pro: Mantener informes actuales centrados en el equipo
  • Pro: Reducido riesgo de que rompan los elementos de trabajo en proyectos de equipo.
  • Con: todos los equipos deben usar la misma plantilla de proceso (un problema no para mí).
¿Fue útil?

Solución

He configurado proyectos como has definido anteriormente. Y he configurado informes de TFS para #2 y #3. La idea de obligar a los equipos a reorganizar para que los informes funcionen hace que la opción #1 sea demasiado severa para mí. #3 es atractivo, pero de manera similar al número 1, limita a los equipos individuales a compartir los mismos tipos de elementos de trabajo y plantillas de proceso. Invariablemente termino en el estado 2. Particularmente si los equipos evolucionan sus procesos de forma independiente. He podido mitigar el problema "los informes se vuelven menos útiles" invirtiendo en la personalización de informes (no trivial, lo sé).

Otros consejos

Este sería un buen candidato para utilizar los servicios de Excel en los servicios de SharePoint. Puede armarlos mucho más rápido que los informes SQL personalizados. Puede llegar al almacén y crear informes de equipo cruzado de manera muy rápida y fácil.

En ese momento, debe sentirse libre de organizar los proyectos de su equipo y ajustarlos en el futuro. De hecho, puede encontrar que desea un TPC por equipo en lugar de simplemente un TPC.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top