¿Deberíamos usar diferentes rastreadores de proyectos para diferentes equipos que trabajan en el mismo producto?

Hemos estado usando una herramienta de proyecto popular, Pivotal Tracker. Hemos decidido dividir nuestro equipo de productos en 3 equipos separados, cada uno de los cuales se enfoca en características con un tema en particular. Existe cierto debate sobre si cada equipo debe tener su propio rastreador o si debemos usar un rastreador integrado.

Los equipos permanecerán juntos durante al menos una cuarta parte del año. Todo va a una base de código y a un repositorio fuente. También compartimos entornos de demostración y puesta en escena. También estamos todos en la misma habitación.

¿Algún consejo en cualquier dirección? Mi inclinación es mantenerlo todo en un rastreador y usar etiquetas para diferenciar, pero me pregunto si es útil tener cálculos de velocidad separados para cada momento. Cualquier pensamiento sería bienvenido.

Respuestas (5)

Mi inclinación coincide con la tuya; No puedo pensar en una situación de mi propia experiencia en la que crearía rastreadores separados para el mismo proyecto pero para diferentes equipos, excepto una situación en la que los cálculos o informes que está tratando de producir no se pueden realizar a nivel de etiqueta o componente. , o de cualquier otra forma fácil de determinar por equipo. Me parece que centrar tus herramientas en la construcción del equipo se trataría más de gestionar los diferentes equipos que de gestionar el proyecto en sí.

Si los equipos están trabajando en diferentes partes del proyecto que pueden considerarse como subproyectos autónomos que juntos forman un proyecto más grande, entonces considere la división.

Según su descripción, suena más como un gran equipo que trabaja en el mismo proyecto dividido por áreas de experiencia en aras de la conformidad y la intercambiabilidad entre los desarrolladores dentro de cada subequipo.

La integración lleva tiempo y cuesta dinero. Requerirá esfuerzo y dinero mantener cada proyecto sincronizado en una sola herramienta. Si estos equipos van a tener muchas idas y venidas, dependencias y coordinación, sería un dinero bien gastado. Si el equipo simplemente se va por su cuenta y entrega su parte del pastel cuando haya terminado, entonces cuestionaría el costo de la integración. Intuitivamente, me parece más lógico y sencillo utilizar una herramienta de seguimiento. Pero no mejoramos si no desafiamos el statu quo. Si hay debate en el equipo, entonces algunos miembros ven un beneficio que debe ser examinado.

Entonces, lo primero que miraría es el costo. En segundo lugar, la integración y lo fácil que sería para mí conocer realmente el estado y la salud de los equipos y el proyecto en general. ¿Sería mejor para mí desconfiar de una herramienta o de tres?

+1 Gran resumen de cómo priorizar los diferentes criterios que intervienen en el proceso de toma de decisiones.

Si los 3 equipos estuvieran trabajando en proyectos completamente separados, estaría tentado a tratarlos como 3 entidades separadas y 3 experimentos separados. Cuando le da a los equipos pequeños la libertad de operar de manera independiente, los libera para experimentar y encontrar metodologías que los ayuden a ser más exitosos.

Si un equipo hace un descubrimiento que dispara su productividad a la estratosfera, los otros equipos pueden decidir adoptarlo y viceversa.

Sin embargo, en esta situación, existe una gran probabilidad de que los 3 equipos deban trabajar en estrecha colaboración. Después de todo, todos están construyendo el mismo producto. Si establece el precedente de que está bien separarse del grupo y usar diferentes herramientas, entonces puede ser difícil fusionar los equipos más adelante y puede ser difícil crear equipos multifuncionales durante los períodos de integración.

En esta situación, si es posible, mi sugerencia sería elegir un solo sistema y apegarse a él.

Además de lo anterior, si lo divide en varios sistemas, existe el riesgo de perder una buena visibilidad del estado y el progreso de su producto.