¿Cuáles son los elementos clave cruciales en el registro de la deuda técnica?

Question

Estoy configurando un registro de deuda técnica en The Office y quiero que sea una herramienta bastante completa.

¿Cuáles son las piezas clave de información que deberíamos grabar?

Answer 1

En primer lugar, desea mantener su registro muy simple, de lo contrario, la sobrecarga de mantener el registro impedirá que la gente lo use y pierda más tiempo que en realidad solucionar la deuda técnica que debía resolver ... ..

Si aún así decide seguir adelante, me gustaría sugerir mantener un registro simple, que es un/base de datos simple/hoja de cálculo de Google archivo plano con los siguientes campos:

• nombre del módulo/componente
• Descripción de lo que n necesidades para ser reparadas (puede tener una lista de categorías, pero creo que esto también necesita un texto de una línea)
• Tiempo estimado de reparación en días (me inclinaría a insistir en números enteros de días, de lo contrario la gente tendrá una tendencia a empezar a registrar cosas trivialmente pequeños)
• Qué desarrollador nacimiento de la deuda (y siempre que la estimación de tiempo fijo)
• que proyectan la deuda se contrajo en (cualquier implícitamente, que el director del proyecto es responsable)

Las reglas son las siguientes:

• Se espera que los desarrolladores sean transparentes con respecto a la deuda técnica. Si un desarrollador necesita incurrir en deuda técnica debido a las presiones del proyecto, el desarrollador debe agregar esto al registro con su tiempo estimado de reparación.
• Los gerentes de proyecto son responsables de la deuda técnica que acumulan (es decir, ¿presionaron a los desarrolladores para que tomen atajos?). Deberían poder justificar una sólida justificación comercial para el endeudamiento total y proponer qué se debería hacer para solucionarlo.
• Si no se detecta una deuda técnica, se espera que el código sea de la mejor calidad y pase cualquier revisión de código relevante. Si se detecta una deuda técnica, el desarrollador obtiene un "pase" por lo que se anota (la revisión podría considerar la precisión del registro de la deuda y las ideas sobre lo que se debe hacer para solucionarlo).
• Se espera que los desarrolladores proporcionen estimaciones justas para el tiempo de reparación. Si dicen que demorará dos días en refactorizar la arquitectura, entonces no deberían sorprenderse si les dan dos días para arreglarlo en algún momento posterior ...

Creo que este enfoque creará una buena dinámica en general: los desarrolladores tienen la responsabilidad de ser transparentes y pensar cómo resolver la deuda técnica; los gerentes de proyecto/líderes empresariales tienen que hacer concesiones, pero está claro que los costos de la deuda son su responsabilidad, los mejores desarrolladores y arquitectos recibirá elogios por completar los proyectos difíciles al tiempo que mantiene la deuda técnica bajo control.