¿Cómo se estima el retorno de la inversión para liquidar la deuda técnica?

Question

Actualmente estoy trabajando con un producto bastante antiguo que ha tenido una gran deuda técnica debido a programadores deficientes y prácticas de desarrollo deficientes en el pasado.Estamos empezando a mejorar y la creación de deuda técnica se ha ralentizado considerablemente.

He identificado las áreas de la aplicación que están en mal estado y puedo estimar el costo de arreglar esas áreas, pero me resulta difícil estimar el retorno de la inversión (ROI).

El código será más fácil de mantener y será más fácil de ampliar en el futuro, pero ¿cómo puedo ponerles una cifra en dólares?

Un buen punto de partida sería volver a nuestro sistema de seguimiento de errores y estimar los costos en función de los errores y las características relacionadas con estas áreas "malas".Pero eso parece llevar mucho tiempo y puede que no sea el mejor predictor del valor.

¿Alguien ha realizado un análisis de este tipo en el pasado y tiene algún consejo para mí?

Answer 1

Los gerentes se preocupan por hacer $ a través del crecimiento (por ejemplo, ante todo, las nuevas características que atraen a nuevos clientes) y (segundo) a través de la optimización del ciclo de vida del proceso.

En cuanto a su problema, su propuesta entra en la segunda categoría: esto, sin duda, va a caer detrás de la portería # 1 (y así conseguir priorizados por incluso si esto podría ahorrar dinero ... porque el ahorro de dinero < strong> implica gastar dinero (la mayor parte del tiempo por lo menos; -)).

ahora , poniendo una cifra de $ en la "mala deuda técnica" podría dar la vuelta en un giro más positivo (suponiendo que el siguiente se aplica en su caso): "si invertimos en la reelaboración de componente X, que podría introducir función y más rápido y así conseguir más clientes Z".

En otras palabras, evaluar el costo de la deuda técnica contra el costo de la pérdida de oportunidades comerciales .

Answer 2

Sonar tiene un gran plugin ( deuda técnica complemento ) para analizar el código fuente para tener en cuenta simplemente como una métrica. Si bien no puede específicamente ser capaz de utilizarlo para su construcción, ya que es una herramienta de experto, se debe proporcionar algunas métricas buenas.

A continuación se muestra un fragmento de su algoritmo:

Debt(in man days) =
    cost_to_fix_duplications +
    cost_to_fix_violations + 
    cost_to_comment_public_API +
    cost_to_fix_uncovered_complexity + 
    cost_to_bring_complexity_below_threshold


 Where :

 Duplications = cost_to_fix_one_block * duplicated_blocks

 Violations   = cost_to fix_one_violation * mandatory_violations

 Comments     = cost_to_comment_one_API * public_undocumented_api

 Coverage     = cost_to_cover_one_of_complexity * 
                         uncovered_complexity_by_tests (80% of
                         coverage is the objective)

 Complexity   = cost_to_split_a_method *
                         (function_complexity_distribution >=
                          8) + cost_to_split_a_class *
                         (class_complexity_distribution >= 60)

Answer 3

Creo que estás en el camino correcto.

No he tenido para calcular esto, pero he tenido un par de conversaciones con un amigo que maneja una gran organización de desarrollo de software con una gran cantidad de código heredado.

Una de las cosas que hemos discutido está generando algunas métricas de esfuerzo en bruto procedentes de analizar compromete VCS y su utilización para dividir una estimación aproximada de horas de programador. Esto fue inspirada por Joel Spolsky basada en la evidencia Programación .

Hacer tales minería de datos le permitirá identificar también la agrupación de cuándo se está manteniendo código y comparamos con la finalización de errores en el sistema de seguimiento (a menos que ya está bendecido con una estrecha integración entre los dos y registros precisos).

ROI adecuado se necesita para calcular el pleno retorno, por lo que algunas cosas a tener en cuenta son: - disminución del costo de mantenimiento (obviamente) - costo de oportunidad para el negocio de tiempo de inactividad o nuevas funciones perdidas que no pudo ser agregado en el tiempo para una liberación - capacidad de generar nuevas líneas de productos, debido a refactorizaciones

Recuerde, una vez que haya una regla para derivar datos, puede tener argumentos sobre exactamente ¿Cómo para calcular las cosas, pero al menos usted tiene algunos cifras con la discusión de semillas!

Answer 4

1 para el enfoque de jldupont sobre oportunidades de negocio perdidas.

Me sugieren pensando en esas oportunidades percibidas por la dirección. ¿Qué creen que afecta el crecimiento de ingresos - nuevas características, el tiempo de comercialización, la calidad del producto? Paydown relativa de la deuda a esos conductores será la gestión de la ayuda entender las ganancias.

Centrándose en las percepciones de gestión le ayudará a evitar falsas numeración. El ROI es una estimación, y no es mejor que las suposiciones hechas en su estimación es. Gestión sospechará argumentos exclusivamente cuantitativos porque saben que hay algún cualitativo en alguna parte. Por ejemplo, en el corto plazo el coste real de su paydown deuda es otro trabajo de los programadores no están haciendo, más que el coste efectivo de esos programadores, porque dudo que va a contratar y capacitar nuevo personal sólo para este . Son las mejoras en el tiempo futuro o la calidad de desarrollo más importante que cuenta con estos programadores de otro modo a añadir?

Además, asegúrese de que entiende el horizonte para la que se administra el producto. Si la administración no está pensando en dos años a partir de ahora, no se preocupan por los beneficios que no aparecerán durante 18 meses.

Por último, reflexionar sobre el hecho de que las percepciones de gestión han permitido que este producto para llegar a este estado en el primer lugar. Lo que ha cambiado que haría que la empresa más atentos a la deuda técnica? Si la diferencia es - usted es un gerente mejor que vuestros predecesores - tener en cuenta que su equipo de gestión no está acostumbrado a pensar en estas cosas. Usted tiene que encontrar su apetito por ella, y se centran en aquellos artículos que entregará resultados que les preocupan. Si lo hace, usted ganará credibilidad, que se puede utilizar para conseguir que el pensamiento más cambios. Pero la apreciación de las ganancias podría ser un tiempo en el cultivo.

Answer 5

Yo sólo puedo hablar de cómo hacer esto empíricamente en un proceso iterativo e incremental.

Usted necesidad de reunir métricas para estimar el mejor costo / historia-punto demostrado. Presumiblemente, esto representa su sistema justo después de la rotación de la arquitectura inicial, cuando la mayor parte del diseño del ensayo y error se ha hecho, pero la entropía ha tenido el menor tiempo a causa caries. Encontrar el punto en la historia del proyecto cuando la velocidad / equipo de tamaño es el más alto. Utilizar esto como su costo / punto de referencia (cero-deuda).

Con el tiempo, ya que se acumula la deuda técnica, la velocidad / equipo de tamaño comienza a disminuir. El porcentaje de disminución de este número con respecto a la línea de base se puede traducir en "interés" se paga en cada nuevo punto de la historia. (Esto es realmente el interés pagado sobre técnica y de la deuda conocimiento)

refactoing disciplinado y hace que el recocido de los intereses de la deuda técnica para estabilizar en algún valor superior a su valor inicial. Piense en esto como el interés de estado estacionario el dueño del producto paga en la deuda técnica en el sistema. (El mismo concepto se aplica a la deuda conocimiento).

Algunos sistemas alcanzan el punto donde el costo + intereses en cada nuevo punto de la historia es superior al valor del punto de función están desarrollando. Esto es cuando el sistema está en quiebra, y es hora de volver a escribir el sistema desde cero.

Creo que es posible utilizar el análisis de regresión de tomadura de pelo de la deuda de la deuda y el conocimiento técnico aparte (pero no he probado). Por ejemplo, si se asume que la deuda técnica se correlaciona estrechamente con algunas métricas de código, por ejemplo, la duplicación de código, que podría determinar el grado de interés que se paga está aumentando debido a la deuda técnica frente a la deuda conocimiento.

Answer 6

Ser un desarrollador sobre todo en solitario o una pequeña equipo esto está fuera de mi campo, pero para mí una gran solución para averiguar dónde se desperdicia el tiempo es muy, cronometraje muy detallado, por ejemplo, con una herramienta práctica barra de tareas como < a href = "http://www.allnetic.com/" rel = "nofollow noreferrer"> esta uno que incluso puede filtrar hacia fuera cuando vas al baño, y todo lo que puede exportar a XML.

Puede ser complicado al principio, y un desafío para introducir a un equipo, pero si su equipo puede iniciar sesión cada quince minutos que pasan debido a un error, equivocación o error en el software, que acumular una base de impresionante, bienes -life datos sobre lo que la deuda técnica es en realidad cuestan en salarios cada mes.

La herramienta he vinculado es mi favorito porque es muy simple (no siempre requiere de una base de datos) y proporciona acceso a todos los proyectos / artículo a través de un icono de la barra de tareas. Además de introducir información adicional sobre el trabajo realizado se puede hacer allí, y la hora normal se activa, literalmente, en cuestión de segundos. (No estoy afiliado con el vendedor.)

Answer 7

Puede ser que sea más fácil estimar la cantidad que ha costado que en el pasado . Una vez que hayas hecho esto, usted debería ser capaz de llegar a una estimación para el futuro de los recorridos y de lógica incluso sus jefes pueden entender.

Una vez dicho esto, no tengo mucha experiencia con este tipo de cosas, simplemente porque todavía no he visto un gerente dispuesto a ir tan lejos en arreglar código. Siempre ha sido sólo algo que arreglar cuando tenemos que modificar el código malo, por lo que la refactorización es efectivamente un costo oculto de todas las modificaciones y correcciones de errores.