Clasificar tareas / errores por riesgo de cambios

El proyecto en el que estoy trabajando actualmente tiene un problema: los errores y las tareas a menudo se asignan a personas que son demasiado nuevas o inexpertas y su trabajo termina produciendo más errores en el futuro. El problema es que partes de nuestro software son mucho más "peligrosas" para trabajar que otras debido a problemas de calidad del código. He estado tratando de combatir este problema estimando el riesgo asociado con las tareas y prestando mucha atención a qué desarrolladores se asignan qué tareas.

Usamos JIRA, así que comencé a etiquetar los problemas para realizar un seguimiento de esta estimación. Me di cuenta de que terminé usando varias métricas para clasificar un error / tarea:

• Qué claro / sencillo es. Por ejemplo, si es algo que necesitará mucho trabajo de diseño o solo una simple corrección de errores de la interfaz de usuario.
• Cuán mantenible es el área afectada del código. ¿Es un área bien diseñada o una gran bola de barro?
• Cuánto del programa creo que se verá afectado por el cambio requerido.

Mis etiquetas son un poco desordenadas, ya que no tenía una idea clara cuando comencé cuáles serían las posibles categorías y todavía no las tengo. Estoy pensando en solicitar que se agregue un nuevo campo (algo así como "Riesgo") para que podamos requerir una estimación antes de asignar el trabajo a alguien.

¿Alguien ha tratado con este tipo de cosas antes?

Una de las fallas de la mayoría de los enfoques de seguimiento de errores es que solo tratan con un lado de la ecuación: la vista del sistema por parte del usuario final. Este es un error crítico para solucionarlo, puede esperar una semana (prioridad), este error es doloroso porque es un sproblema de pluralización (gravedad).

Una publicación de blog que describe el seguimiento multidimensional de errores aborda esta cuestión, incluida la vista del desarrollador: PEF y REV.

Los valores de PEF son la vista del usuario:

• P ‍ain: ¿qué tan doloroso es el error cuando se encuentra?
• E ‍fuerzo: ¿cuánto esfuerzo se necesita para evitarlo?
• Frecuencia F : ¿con qué frecuencia ocurre el error?

El lado REV es desde el punto de vista del desarrollador:

• R ‍isk: ¿qué tan arriesgada es la solución?
• E ‍fuerzo: ¿cuánto esfuerzo tomará arreglar?
• V ‍erificabilidad: ¿qué tan fácil es verificar que el error esté solucionado?

Cada uno de estos se mide en una escala de 1..9, siendo 1 bajo / fácil y 9 alto / duro. Los números se suman para dar una puntuación para PEF y REV.

La parte que aborda los bits descritos:

• Qué claro / sencillo es. Por ejemplo, si es algo que necesitará mucho trabajo de diseño o solo una simple corrección de errores de la interfaz de usuario.
• Cuán mantenible es el área afectada del código. ¿Es un área bien diseñada o una gran bola de barro?
• Cuánto del programa creo que se verá afectado por el cambio requerido.

Estos factores influyen en el esfuerzo y el riesgo descritos en REV.

Sí, es algo con lo que se ha luchado antes. He usado (en el pasado) este modelo para campos personalizados en Redmine y fue razonablemente exitoso.

La gran ventaja de esto viene cuando compara los puntajes PEF y REV. Si tienes un PEF de 21 y un REV de 7, eso puede ser una gran victoria. Mientras que un PEF de 7 y un REV de 21 es algo que debe evitarse por un tiempo porque el lado de riesgo y esfuerzo probablemente supere el beneficio que lo soluciona.

Luego se puede ver el puntaje REV y asignar cosas con bajo riesgo a los desarrolladores menos experimentados (bajo riesgo, alto esfuerzo a menudo son ideales para esta situación).

Diría que a lo que te estás refiriendo aquí podría llamarse 'complejidad'. Por supuesto, cuanto más complejo es un cambio, mayor es el 'riesgo' de que un programador inexperto pueda introducir algún error nuevo. No es una mala idea introducir ese campo si es un problema real.

Sin embargo, a juzgar por lo que escribió, parece tener dos problemas:

1. Estás tratando con programadores nuevos o inexpertos.
2. La calidad de (mucho / algo) de su código parece ser cuestionable.

Además de introducir algo como un campo de 'complejidad' (que ayudaría a administrar y priorizar su trabajo), le sugiero que se concentre en mitigar el riesgo de los dos problemas anteriores.

Para abordar el primer problema, crearía un proceso mediante el cual los nuevos programadores primero discutan todos los errores nuevos con un programador más experimentado antes de trabajar en el error. Además, definitivamente presentaré revisiones de código para reducir el riesgo de que se introduzcan nuevos errores y para usar como oportunidad de entrenamiento para que los nuevos programadores se pongan al día más rápidamente.

Con respecto a la calidad del código, haría dos cosas. En primer lugar, detenga el proceso de descomposición: acuerde las normas y prácticas de codificación que evitarían la introducción de un nuevo código inferior. Las revisiones de código sugeridas también ayudarían aquí. En segundo lugar, identificaría las peores partes de su código y comenzaría a refactorizarlas y limpiarlas.

Sí, es una buena idea no dar problemas a los desarrolladores inexpertos que son demasiado complejos. Pero la otra cara es que si solo les dejas hacer las cosas fáciles, entonces no aprenderán.

Sugiero que una estrategia alternativa es instituir un régimen de revisiones de código. Deje que los novatos trabajen en el trabajo en las cosas difíciles (dentro de lo razonable), pero revise a fondo su trabajo.

A corto plazo, esto es más trabajo para todos. A largo plazo, terminará con un equipo completo de desarrolladores que pueden manejar las cosas complejas, Y están "en la misma página" en lo que respecta a la calidad del código.