Entre desarrolladores, una medida bastante confiable de deuda técnica parece ser WTFs / minute .
El problema con esta "métrica" es que normalmente es bastante difícil comunicarse "fuera".
La métrica que funcionó para mí en la comunicación de la deuda técnica a los "forasteros" fue la cantidad de pruebas y el esfuerzo de corrección de errores (especialmente para corregir errores de regresión ) necesarios para una entrega exitosa.
Una palabra de advertencia: aunque este enfoque es bastante poderoso, sería mejor verificar dos veces con WTFs / minute antiguos antes de recurrir a él. La cosa es que es bastante engorroso: para obtener los datos, uno tiene que hacer un seguimiento cuidadoso del tiempo y registrarlo con precisión según las categorías apropiadas.
- es mucho más fácil indicar el total de 3 semanas invertidas en implementar la función A que
Pasé 14 horas en el borrador de la implementación de la característica A, luego 29 horas en la prueba de humo, luego 11 horas en la implementación de correcciones para las regresiones que descubrí, y luego 18 horas en la prueba de la implementación de la característica QA-ready. Después de eso, los muchachos de control de calidad pasaron 17 horas probando el lanzamiento inicial del candidato. Después de eso, pasé 13 horas analizando los errores enviados por QA para la versión candidata inicial y 3 horas implementando las correcciones. Después de eso, pasé 11 horas en pruebas de humo de los cambios que hice al lanzamiento inicial del candidato. Después de eso ...
De todos modos, los datos sobre las pruebas y el esfuerzo de corrección de errores han sido bastante fáciles de comunicar en mi experiencia.
Para la versión reciente, dedicamos aproximadamente un 90% de tiempo a probar y corregir errores de regresión. Para la próxima versión, sugiera que se dedique un poco de esfuerzo para reducir este valor al 60-70%.
Otra palabra de precaución. Los datos como el 90% anterior podrían interpretarse no solo como un indicio de deuda técnica, sino también (sorpresa) como un indicio de que uno no es bastante competente en programación / tecnología particular. "Solo haces demasiados errores en tu código".
Si existe el riesgo de que los datos se malinterpreten de esa manera, es útil contar con datos de referencia adicionales sobre algo menos propenso a WTF con el que comparar.
- Diga si hay dos componentes / aplicaciones similares mantenidos por el mismo desarrollador (s), primero liberando a "tasa de desperdicio" alrededor del 50% y segundo a 80-90, esto constituye un caso bastante sólido a favor de segundo ser sujeto de deuda técnica.
Si hay probadores dedicados en el proyecto, también podrían contribuir a una evaluación más objetiva de los datos. Como mencioné en otra respuesta ,
Con los evaluadores, consigue que alguien respalde su comprensión de los problemas de diseño. Cuando solo hay desarrolladores que se quejan de la calidad del código , esto a menudo suena como WTF subjetivos detrás de la puerta cerrada .
Pero cuando esto se repite cuando el tipo de control de calidad dice algo como component A tenía 100 errores de regresión para 10 nuevas características, en lugar de component B que tenía 10 errores de regresión por 20 nuevas características , la comunicación de repente se convierte en Todo otro juego.
