Estaba pensando en etiquetar los casos resueltos por su causa (probable), por ejemplo
Tal vez se presenten causas comunes en esto, por lo que recibimos comentarios y tomamos medidas precisas para evitarlas. O tal vez esto es solo un ejercicio inútil de estadísticas y circulación de culpas.
¿Qué piensas?
De manera más general, ¿qué tipo de análisis realiza en su rastreador de problemas? ¿Qué otra información además de "¿qué debo hacer hoy?" y "¿podemos entregar?" te sales de eso?
La mejor solución que he visto para esto es el seguimiento de errores a nivel empresarial. Intentan evaluar y determinar la causa raíz del error. No la persona, sino la causa raíz real . Ejemplos de esto podrían ser:
Señalar con el dedo no es útil, e incluso si se hace, no le dimos mucha importancia. Todos cometen errores. Es más importante ver qué errores se repiten, para poder corregirlos. Para las causas raíz enumeradas anteriormente, las soluciones podrían ser (en orden):
+1 a ashes999 por centrarse en la causa raíz , pero caracterizaciones como:
Tienden a ser tan específicos que, con el tiempo, tienen demasiadas categorías para ser útiles. En algunos proyectos (pero no en todos) he categorizado los errores por Fase , una especie de término vago para tratar de capturar cuándo se inyectó el defecto en el ciclo de vida de su proyecto.
Tener un cuadro desplegable que le permite seleccionar entre Requisitos , Diseño , Código , Integración es todo lo que siempre he necesitado. Si eres realmente duro, puedes dividir esto en 2 partes: Phase Injected y Phase Detected . La idea básica aquí es la contención de la fase del defecto : hay buena evidencia que muestra que cuanto más se tarde en encontrar un defecto, más caro será repararlo. Por ejemplo, un error de requisitos es barato de resolver mientras trabaja en sus requisitos, pero puede costar mucho después de haber lanzado su producto.
Incluso si no realiza todo el sofisticado análisis CMMI de nivel 5, saber en qué fase está inyectando problemas es extremadamente útil. Como cualquier otra medida, debe crearla con un objetivo específico en mente: saber que la mayoría de sus defectos están relacionados en última instancia con los requisitos, el diseño o la codificación o lo que sea que le ayude a centrar su atención en dónde debería estar la corrección del proceso. De lo contrario, puede tener la tentación de agregar más y más pruebas. Esta es potencialmente la forma menos eficiente de abordar el problema.
Ver también:
Estoy de acuerdo en que se debe evitar la culpa si desea un entorno de trabajo abierto. En lo que debe concentrarse es en qué área sucedió y en qué parte del ciclo de vida se introdujo:
¿Hay áreas de código que siguen teniendo errores? ¿Son especialmente sensibles a los cambios debido al exceso de complejidad? ¿Deberían estas áreas tener más pruebas unitarias y/o una gestión de versiones más estricta (o incluso una reescritura)?
¿Se están introduciendo errores constantemente al final del proyecto? Esto puede ser un indicador de demasiados cambios de requisitos tardíos. Los errores distribuidos uniformemente a lo largo de la etapa de desarrollo principal pueden solucionarse realizando revisiones de código entre pares.
Incluso si surgen problemas debido a una persona, concentrarse en agregar contramedidas a lo que están trabajando en lugar de ellos le permitirá mitigar los problemas sin causar problemas personales.
Creo que el seguimiento de la causa raíz de los errores es bastante importante, más aún si la causa raíz resulta ser algo sistemático como parte de su proceso de desarrollo.
Por ejemplo, el análisis muestra que el código que se ocupa de la integración de un entregable de una empresa subcontratada se rompe constantemente y la causa raíz es que las especificaciones de los requisitos no se entendieron ni controlaron bien. Este es un problema sistemático y debe abordarse para minimizar el impacto futuro.
Tendemos a rastrear las causas raíz del defecto y el área en la que se aplican las soluciones.
Definitivamente no creo que este sea un ejercicio de distribución de culpas, sino un proceso que permite una mayor comprensión de cuáles fueron las principales causas de los problemas dentro del proyecto. Depende del gerente del proyecto mantener una cultura de no culpar dentro de los límites del proyecto.
O tal vez esto es solo un ejercicio inútil de estadísticas.
Las estadísticas corroborarán las áreas problemáticas clave. Esto ayudará en las revisiones posteriores a la implementación e identificará qué lecciones se pueden aprender para proyectos futuros o incluso beneficiará a otros proyectos que se están ejecutando actualmente.
La causa del error es una métrica muy importante. Por lo general, el nombre es "Resuelto como" con valores: Corrección de código, Problema de entorno, Entidad externa, Datos incorrectos, Brecha de diseño, etc.
No hay un juego de culpas aquí, ya que solo el líder del equipo debe poder categorizarlo. El control de calidad y los desarrolladores no deberían establecer la causa.
Al final del día, es útil saber que el entorno ha causado el 60 % de los problemas y los datos incorrectos en la base de datos causan otro 20 %, mientras que solo el 10 % está relacionado con el código. Por este medio, sabemos que debemos centrarnos más en el entorno y la implementación en nuestro próximo proyecto. Detrás de escena, también puede ayudar a medir el KPI con precisión.
Por supuesto, "culpar" no debería tener nada que ver con eso. Todos estamos comprometidos en un esfuerzo humano extremadamente complejo, y nunca se debe "culpar" a nadie. Necesitamos permanecer enfocados en el proceso, no en las personas que participan en él. El único objetivo debe ser aprender a hacerlo mejor, y este es en realidad un objetivo muy "específico de la situación", no general.
Es muy útil rastrear cuál creemos que fue la causa raíz y exactamente en qué parte del proceso podría haber ocurrido. (Consulte la respuesta de "contención" anterior). ¿Fue realmente que "alguien cometió un error" o es en realidad una señal de algo más? Puede que no sea 'un error!'
Marcia
cenizas999
CoderHawk
Zsolt