2009-12-21 5 views
9

Me gustaría encontrar una forma de registrar la deuda técnica en la que incurrimos en TFS.¿Dónde registra deuda técnica en TFS?

Necesito registrar cada elemento fuera de una iteración específica para asegurar que sea visible y fácil de informar todo el tiempo. Consideré crear un área separada para la deuda técnica, pero no estoy seguro de qué tan adecuado sea ese campo en realidad.

¿Cuáles son algunos enfoques comunes que podría considerar? ¿Estoy incluso ladrando al árbol correcto tratando de encontrar el lugar correcto para poner esto?

+0

No estoy seguro de cómo hacer esto, pero es una gran pregunta. Tiene todo el sentido que debe rastrear su deuda técnica al igual que hace un seguimiento de los requisitos. El problema que veo es identificar la deuda. Si puede identificarlo con precisión, puede hacer un elemento de trabajo para devolverlo. –

+0

TFS == Team Foundation Server? Ayuda si define acrónimos. –

+0

Lo sentimos, sí TFS === Team Foundation Server. Traté de marcarlo entre etiquetas, pero no son compatibles con SO. –

Respuesta

4

No he encontrado la necesidad de seguirlo por separado; Solo lo ingreso como tareas adicionales. De esta forma, pueden rastrearse e informarse fácilmente.

+0

¿Pero todavía no necesita asociar una tarea con una iteración particular? ¿Encuentra que este enfoque es limpio y fácil de administrar? ¿Qué haces para las tareas que pueden abarcar un par de iteraciones? –

+2

Lo manejo como cualquier otra tarea, así que sí, me parece limpio y fácil de administrar. No me ha parecido útil separar la "deuda técnica" como un área separada; al final realmente se reduce a más trabajo en áreas existentes. A veces la tarea va en la iteración actual; a veces en otro. Al igual que con todas las tareas, a veces pueden posponerse de la iteración actual a la siguiente a medida que la iteración llega a su fin. Para tareas que pueden abarcar más que la iteración, generalmente las divido en múltiples tareas (incluso algo tan simple como "fase 1" y "fase 2" generalmente funciona bien). – RickNZ

+0

Me gusta su punto sobre cualquier deuda técnica que finalmente tenga su "causa raíz" en una característica o área existente del proyecto. Buen punto. –

4

Encuentro que hay varios tipos de deudas técnicas: deudas que conoces y que puedes rastrear hasta que se resuelvan, y deudas que se vuelven aparentes como resultado de un error inesperado. Me gusta rastrear la deuda técnica conocida conocida en una iteración separada que llamo 'Mantenimiento acumulado', en el área 'Deuda técnica'. Luego puedo vincular errores relevantes de CUALQUIER iteración al área de Deuda técnica, mientras sigo rastreando problemas que aún no puedo resolver. La clave es que todavía necesita errores asociados con la iteración que se encuentran y se han corregido y vinculado a los requisitos de origen para fines de informes, etc.

+0

Gracias. Este es el tipo de enfoque que tenía curiosidad. ¿Pero crees que funciona bien? ¿Hay otras personas/empresas operando de esta manera? ¿Están su área de "Deuda técnica" y la iteración "Mantenimiento pendiente" tanto en el nivel superior de sus respectivas jerarquías? –

+0

Funciona bien porque el equipo puede adoptar un enfoque proactivo, documentando la deuda técnica a medida que avanzan, incluso si no pueden solucionarla en la iteración actual. También puedo informar fácilmente sobre la cantidad de trabajo no automatizado por ciclo debido a la deuda técnica, etc. Hay otra empresa en nuestra área (más de 200 desarrolladores) que utiliza un enfoque similar. No puedo hablar en nombre de la comunidad en general, pero parece aprovechar TFS como estaba previsto. – PortageMonkey