¿Qué cantidad de tiempo se debe gastar en errores versus desarrollo original? [cerrado]

Esta pregunta es un poco abstracta, pero espero que alguien pueda señalarme en la dirección correcta.

Mi pregunta es qué cantidad de tiempo se puede esperar dedicar a los errores de un proyecto de software en relación con el tiempo de desarrollo original. Me doy cuenta de que hay una gran cantidad de factores determinantes que intervienen, pero esperaba un desglose típico o promedio.

Por ejemplo, si el Proyecto A tarda 40 horas en completarse y otros 10 errores de reparación adicionales, entonces este proyecto tendría una relación 4: 1.

Si otro Proyecto (B) tarda 10 horas en completarse pero otros 8 en errores, entonces tendría una relación de 5: 4.

¿Es este un concepto documentado / investigado?

ACTUALIZAR

Gracias por todas las respuestas informativas. Entiendo que es imposible establecer un estándar para este tipo de métrica debido a todas las variables y factores ambientales involucrados. Antes de asignar una respuesta, me gustaría saber si esta métrica tiene un nombre acordado para poder seguir investigando. Me gustaría llegar a un punto en el que pueda comprender las medidas necesarias para generar las métricas yo mismo y, finalmente, llegar a un estándar de referencia para mi proyecto.

El porcentaje de equilibrio de la capacidad total asignada a la reparación de defectos es igual a la tasa de inyección de defectos .

Muchos factores pueden afectar esta tasa, entre ellos, por supuesto: qué tipo de producto está desarrollando el equipo, qué tecnologías y prácticas técnicas utilizan, el nivel de habilidad del equipo, la cultura de la empresa, etc.

Considerando el Equipo B, si crean en promedio 8 unidades de retrabajo por cada 10 unidades de trabajo que completan, entonces trabajar esas 8 unidades creará nuevas 6.4 unidades de retrabajo. Podemos estimar el esfuerzo total que eventualmente tendrán que gastar como la suma de una progresión geométrica:

10 + 8 + 6.4 + 5.12 + ...

El número de errores disminuirá exponencialmente con el tiempo, pero el Equipo B tiene un coeficiente tal en su exponente que irá a cero muy lentamente. En realidad, la suma de los primeros tres términos en la serie anterior es solo 24.4; de los primeros cinco, 33.6; de los primeros 10, 45; de toda la serie, 50. Entonces, resumen del Equipo B: tasa de inyección de defectos, 0.8; desarrollo de características, 10/50 = 20%; fijación de defectos, 80%. 20/80 es su asignación de capacidad sostenible.

Por el contrario, el equipo A está en mucho mejor forma. Su progresión se ve así:

40 + 10 + 2.5 + 0.625 + ...

La suma de esta serie es 53 1/3, por lo que la asignación de desarrollo de características del Equipo A es 40 / (53 1/3) = 75% y la asignación de reparación de defectos es 25%, lo que coincide con su tasa de inyección de defectos de 10/40 = 0.25 .

En realidad, todos los términos en la serie del Equipo A después de los primeros tres son insignificantemente pequeños. Lo que esto significa en términos prácticos es que el Equipo A probablemente pueda eliminar todos sus errores con un par de versiones de mantenimiento, siendo la segunda versión bastante pequeña. Esto también crea una ilusión de que cualquier equipo puede hacer eso. Pero no el equipo B.

Pensé en esta equivalencia mientras leía el nuevo libro de David Anderson, "Kanban" . (El libro trata un tema diferente, pero también aborda las inquietudes sobre la calidad.) Al hablar sobre la calidad del software, Anderson cita este libro, de Capers Jones, "Evaluaciones de software, puntos de referencia y mejores prácticas" :

"... en 2000 ... midió la calidad del software para los equipos de América del Norte ... varió de 6 defectos por punto de función a menos de 3 por 100 puntos de función, un rango de 200 a 1. El punto medio es aproximadamente 1 defecto por 0.6 a 1.0 puntos de función. Esto implica que es común que los equipos gasten más del 90 por ciento de su esfuerzo reparando defectos " . Cita un ejemplo proporcionado por uno de sus colegas de una compañía que pasa el 90% del tiempo arreglando sus errores .

La fluidez con la que Anderson pasa de la tasa de inyección de defectos a la asignación de capacidad de fijación de texto ( demanda de falla es el término para ello) sugiere que la equivalencia de las dos cosas es bien conocida por los investigadores de calidad de software y probablemente se haya sabido por algún tiempo .

Las palabras clave en la línea de razonamiento que estoy tratando de presentar aquí son "equlibrium" y "sostenible". Si eliminamos la sostenibilidad, entonces hay una manera obvia de engañar a estos números: realiza la codificación inicial, luego pasa al código en otro lugar y deja el mantenimiento a otros. O acumula la deuda técnica y la descarga en un nuevo propietario.

Obviamente, ninguna asignación particular se adaptará a todos los equipos. Si decretamos que se debe gastar el 20% en errores, entonces, si un equipo tiene una tasa de inyección de defectos ultra baja, simplemente no tendrán suficientes errores para llenar el tiempo, y si un equipo tuvo una tasa muy alta, sus errores continuará acumulándose.

Las matemáticas que utilicé aquí están simplificadas. Descuidé cosas como los costos de transacción (reuniones de planificación y estimación, autopsias, etc.), lo que afectaría un poco los porcentajes. También omití ecuaciones que simulan sostener un producto y desarrollar otro simultáneamente. Pero la conclusión sigue en pie. Haga lo que pueda, en términos de prácticas técnicas, como pruebas unitarias, integración continua, revisiones de código, etc., para reducir la tasa de inyección de defectos y, en consecuencia, la demanda de fallas. Si puede crear un solo error por cada 10 funciones, tendrá mucho tiempo libre para desarrollar nuevas funciones y satisfacer a sus clientes.

Lamentablemente, creo que esta relación es muy variable en un proyecto determinado. Se verá afectado drásticamente por su entorno, idioma, herramientas, tamaño del equipo y experiencia.

Debería dedicar tiempo a un error solo si lo que gana de la corrección es mayor de lo que invierte.

Utilice una matriz como la siguiente (horizontal - tiempo requerido para corregir el error, vertical - tipo de error - impacto en los usuarios)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Ejemplo de problemas:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

La matriz puede ser más compleja con diferentes niveles de gravedad, esfuerzo, riesgos, etc.

Incluso puede crear un rango para cada error y corregirlos según la clasificación. Algo como:

Bug priority = Risk x Severity x Effort

* Puede ser (1-x) para algunos operandos, dependiendo de la escala que elija :)

Entonces, para responder a su pregunta: depende del tipo de errores, tiempo / presupuesto disponible, etc.

Es muy variable, no solo (por supuesto) en la experiencia y calidad del equipo, y en la dificultad del proyecto (no es lo mismo hacer otra aplicación web estándar que un nuevo núcleo del sistema operativo), sino también en el enfoque de gestión que usted Lo usaré.

Por ejemplo, en un modelo en cascada puede configurar con precisión el primer error en la primera fase de prueba, pero en un entorno ágil puede ser difícil establecer una línea que diga "a partir de ahora, estamos corrigiendo errores", ya que las características pueden cambiar ( y para mí no es justo contar un cambio de función como un error)

Por experiencia, digo que es algo que SIEMPRE está subestimado, y muy fácilmente puede pasar la misma cantidad de horas que el "proyecto original".

La respuesta verdaderamente correcta sería cero horas en la corrección de errores porque su código es perfecto. :-)

Siendo realistas, no puedo decir que haya escuchado a alguien pedir u ofrecer ese tipo de proporción. Eso no quiere decir que algunas empresas no sigan el tiempo para el desarrollo y el mantenimiento. Pero el desarrollo de una aplicación es un período de tiempo tan corto en comparación con el mantenimiento que la mayoría de las empresas no regresan y calculan esa proporción. Probablemente estén más preocupados por saber por qué una aplicación requiere mantenimiento y aplicar esos hallazgos a nuevas aplicaciones.

Tener un criterio demasiado amplio para lo que es un error casi puede duplicar su tiempo. Un administrador demasiado entusiasta que cree que la solicitud de un cliente para agrandar un botón (tienen problemas con el mouse) es una excelente manera de aumentar la cantidad de errores que solucionamos. Solo tomará unos segundos solucionarlo porque no hay necesidad de considerar, probar, recompilar y distribuir un parche. Ah, y se cuenta dos veces como una nueva característica.

El factor determinante más importante para esto es si está trabajando con una nueva tecnología o una existente. Si está trabajando con algo nuevo y está desarrollando algo que no se ha hecho o se ha hecho varias veces en diferentes circunstancias, pasará mucho tiempo reparando errores y haciendo que su proyecto funcione de la manera que desee . Con frecuencia, los errores serán el resultado de trabajar en una esquina, y necesitará hacer una cantidad significativa de trabajo para reestructurar lo que ha hecho. Además, muchos errores resultarán de una comprensión incompleta de las expectativas del usuario y del desconocimiento del desarrollador de los casos límite.

Si está trabajando en una tecnología establecida, la mayoría de los problemas se habrán solucionado en las bibliotecas o en las prácticas de la comunidad, y debería poder buscar en Google, comprar o salir de cualquier error con el que se encuentre.

En software crítico, una relación 1: 1 no es inusual. Solo para las pruebas unitarias, he visto indicadores que mencionan 1 día de pruebas unitarias por cada 10 líneas de código.

Creo que esta pregunta está sesgada: parte de la presuposición de que corregir errores es una fase similar a desarrollar nuevas funcionalidades . Este no es el caso.

Un buen desarrollador no pasará mucho tiempo depurando el código, ya que su código estará libre de errores desde el principio. Un mal desarrollador pasará mucho tiempo depurando su código porque no puede crear abstracciones adecuadas para resolver problemas reales.

Tenga en cuenta que los desarrolladores deben probar su propio código por sí mismos. Es su responsabilidad laboral entregar un código libre de errores. Por lo tanto, es difícil separar la codificación de la depuración.

También es una cuestión de prioridad. Cuando se desarrolla, el tiempo necesario para corregir un error se relaciona exponencialmente con el tiempo transcurrido desde el momento en que insertó el error en el código. Por lo tanto, corregir errores debería ser de mayor prioridad que desarrollar nuevas funcionalidades.

Entonces, en lugar de hablar sobre el "tiempo dedicado a errores", debería hablar sobre el "tiempo dedicado a las pruebas" (pruebas de integración, pruebas de aceptación del usuario ...)

Creo que tienes razón: no obtendrás ninguna métrica significativa debido a la gran cantidad de factores que influyen.

Si ayuda, puedo decirle que los proyectos en los que trabajo (espacio empresarial, sistemas complejos grandes, mucha integración con otros sistemas) tienen una relación de aproximadamente 3: 2. La mayoría de estos no son fallas con el código, más comúnmente fallas con las interfaces. Por ejemplo, el sistema A y B se comunican entre sí a través de la interfaz X. Los desarrolladores del sistema A interpretan la interfaz X de forma ligeramente diferente a los desarrolladores del sistema B. Se produce la comedia.

Una observación a realizar es que el desarrollo de código y las pruebas / corrección de errores del código no deberían ser dos fases distintas. Si prueba a medida que desarrolla, el "costo" de la corrección de errores es menor.

Tomo un punto de vista puramente práctico: ¿qué impide más la utilidad práctica del proyecto? Si se trata de errores en la funcionalidad existente, debe corregir los errores. Si faltan características, debe realizar el desarrollo original, luego volver y corregir los errores una vez que se implementen las características faltantes más graves. Esto requiere familiaridad con sus casos de uso. Un error que bloquea el programa en algún caso de esquina extraño puede ser una prioridad menor que las mejoras de usabilidad menores que afectan a todos. Un pequeño error molesto en la funcionalidad más utilizada puede ser más importante que una función que solo beneficia a las personas que están llevando su software a los extremos.