Calcular los costos del código incorrecto

13

Estoy buscando argumentos para convencer a la gerencia de invertir esfuerzos en refactorización.

Registramos el trabajo utilizando Jira y relacionamos cada svn-commit con una llamada jira.

Mi idea es hacer lo siguiente:

  • localice manualmente un área de código que está extremadamente mal implementada, pero a menudo se usa: tanto desde User-POV como desde Developer-POV (corrección de errores)
  • obtenga los svn-commit que contienen los problemas de JIRA
  • filtre los problemas de acuerdo con algunos criterios (tipo de problema, versión, prio, etc.)
  • calcular el tiempo / esfuerzo empleado en estos errores
  • estimar esfuerzos y riesgos de refactorización
  • presente los números y pida un esfuerzo para corregirlos.

¿Qué piensas de esto? ¿Sería esta medida útil y / o convincente? ¿Cuáles son los pros y los contras?

    
pregunta Bastl 26.08.2011 - 14:42

3 respuestas

5

Descubrí que si puedes proporcionar números válidos, es más probable que los gerentes actúen. (Si pueden entender la lógica y el costo / beneficio).

En mi humilde opinión, para hacer un caso convincente, necesitarías lo siguiente para mostrar lo malo que es:

  • número de incidencias de soporte registradas para los problemas
  • tiempo empleado en horas manteniendo / ayudando de banda el código incorrecto / haciendo soporte arreglos
  • costo de tiempo basado en la tarifa por hora de las personas que realizan el mantenimiento / banda ayudas / soporte
  • alguna manera de demostrar cuán críticos son estos elementos para la misión negocio

Y para justificar la refactorización, necesitarás:

  • tiempo estimado para refactorizar e implementar cada uno de los 3 principales cosas malas
  • costo estimado para la implementación (las mismas tarifas por hora que se usaron anteriormente)

Con estos, puede justificar el ahorro de tiempo si la refactorización toma mucho menos que el tiempo de soporte para 3 incidentes para cada uno de los 3 elementos principales. Puede argumentar que esta menor cantidad de tiempo invertido se

  • ser menos que n más incidentes de soporte
  • no habrá más de estos incidentes por estas cosas (¡YA MEJOR!)

Sin embargo, la parte más difícil de esta venta será responder a la siguiente pregunta, ya que muchas personas no asignan tiempo en el presupuesto para todo el apoyo que estás haciendo:

¿Cuánto tiempo más tendré que esperar a que termine el proyecto actual Y mientras está gastando tiempo trabajando en estos problemas con X ????? (a pesar de los tiempos de soporte actuales, que no se puede predecir y programar en los diagramas de Gantt)

Esto depende mucho de lo bien que se comunique con los tomadores de decisiones y de cómo entienden la situación.

DEFINITIVAMENTE, creo que vale la pena hacerlo, por lo que tiene la práctica de construir el caso con las métricas y ahorrarse tiempo, incluso si no lo hacen. Desafortunadamente, no todos son fáciles de convencer, a pesar de los datos. ¡BUENA SUERTE!

    
respondido por el Jennifer S 26.08.2011 - 20:02
2

Tenga en cuenta que la refactorización también introduce errores (que se detectarán en sus pruebas, pero que, sin embargo, son errores y deben solucionarse). No tire de un Netscape por accidente. Depende de tu definición personal de "refactorización". Para algunos, esto significa "reescribir todo el código" para otros significa "cambiar algunos elementos internos". ¿Cómo sabes qué tipo de persona eres? Hágase la siguiente pregunta:

¿Estoy cambiando la interfaz pública?

Si la respuesta es sí, estás rediseñando. Si la respuesta es no, está haciendo refactorización y probablemente solo puede hacerlo a lo largo de sus actividades diarias sin una aprobación especial. Esto es relevante para su pregunta porque un rediseño generará muchos más errores, mientras que una refactorización suele ser más fácil de realizar (ya que sus pruebas ya ejercerán la interfaz pública y no deberán modificarse).

Es un caso difícil de hacer, porque nadie sabe cuánto costaría X con o sin el refactor que se hizo hace un año. En mi experiencia, los gerentes pragmáticos siempre rechazan este tipo de cosas porque:

  1. El flujo de ingresos directos no proviene del esfuerzo (costo financiero, no facturable)
  2. El código de trabajo feo sigue funcionando, corres el riesgo de crear problemas en lugar de solucionarlos (costo potencial de calidad)
  3. Otros proyectos se retrasarán mientras usted refactoriza (costo de tiempo)
respondido por el anon 27.08.2011 - 17:30
0

Todos estos números se basan, en última instancia, en suposiciones, en su caso comparando la cantidad que cree que costaría no a refactorizar, en comparación con lo que cree que costaría a refactor . Lo mejor que puedes hacer es demostrar que tienes algún tipo de base numérica y objetiva para las conjeturas y que tienes una muy buena.

Las ventajas son que probablemente será eficaz para convencerlos de que te dejen refactorizar, y podría ir bien y reducir la cantidad de errores.

Las desventajas son que si la cantidad de tiempo dedicado a corregir errores no se reduce al menos tanto como el tiempo empleado en refactorizar, probablemente no se le permitirá refactorizar más, y probablemente se lo culpe por " tiempo perdido.

Los ahorros en el tiempo de depuración que se obtienen al reducir la complejidad del proyecto en general, o al facilitar la adición de funciones, pueden ser muy difíciles de medir para ayudarlo mucho, pero podría mencionar que existen.

    
respondido por el psr 26.08.2011 - 20:03

Lea otras preguntas en las etiquetas