language agnostic - ¿Cómo priorizar errores?

language-agnostic process (15)

En mi compañía actual, no existe una comprensión clara entre los equipos de prueba y desarrollo sobre cuán severo debe ser un error. Hay argumentos que van y vienen para reducir o aumentar la gravedad. Hasta el momento, no tenemos conocimiento de ningún documento que establezca las reglas. El examinador plantea el error y le asigna prioridad en función de su intuición. El desarrollador solicitaría un cambio basado en su carga o algún otro factor.

¿Cómo se clasifica la severidad / prioridad de los errores? ¿Existen normas que guíen la forma en que las prioridades de defectos del software deben determinarse en función de las necesidades del cliente, los plazos y otras cuestiones?

Debe hacerse ahora
Debe hacerse antes de enviar
Molestia menor (no impide que el usuario ejerza la funcionalidad)
Caso Edge / Remote / Tester-from-Mordor

Bueno, ya lo inventé ... mi punto es que la categorización de errores no debería ser una hora semanal + ritual largo ...
En mi humilde opinión, priorizar según un diagrama de flujo es tiempo perdido. Corrige errores en Cat # 1 y # 2 tan rápido como salen a la superficie. Si te encuentras abrumado por errores, disminuye la velocidad y reflexiona. Aplazar Cat # 3 y Cat # 4 si el cronograma no lo permite o si se reemplazan los ítems de mayor prioridad.
Lo más importante es que todos ustedes comprendan esta gravedad y la calidad esperada. No permita que el cumplimiento de los estándares sagrados de X le impida ofrecer lo que el cliente quiere ... software de trabajo.

En cuanto a un estándar, la guía IEEE para la clasificación de anomalías de software, aunque no estoy seguro de cuánto se adopta. IEEE 1044.1-1995

Establezca los requisitos del proyecto para que pueda basar la prioridad de una solución en la prioridad de los requisitos interferidos por el error.

Personalmente, estoy a favor del modelo de severidad / prioridad de dos niveles. Conozco los argumentos para un solo nivel, pero los lugares en los que he trabajado en general. Acabo de ver que una jerarquía de dos niveles funciona mejor.

La severidad es establecida por el equipo de soporte (basado en la información del cliente). La prioridad es establecida por el cliente (con la contribución del equipo de soporte).

Por la gravedad que uso:

1 - Bloqueador / show detenido
2 - Funcionalidad principal no disponible (o efectivamente no disponible), ningún trabajo práctico alrededor posible
3 - Funcionalidad principal no disponible (o ...), posible solución
4 - Funcionalidad menor no disponible (o efectivamente no disponible), no se puede evitar el trabajo
5 - Funcionalidad menor no disponible (o ...), posible solución
6 - Cosmético u otro trivial

Luego, para la prioridad solo uso High, Medium, Low, pero cualquier cosa de 3 a 5 niveles funciona (mucho más que eso está un poco por encima).

Generalmente, primero ordenaba por prioridad primero y luego por gravedad dentro de eso. Lo importante de esto es que el cliente tiene la opinión más importante. Si dicen que la forma en que su logotipo se imprime en un informe es la más alta prioridad, entonces eso es lo que se busca, PERO se lo mira después de la alta prioridad del otro cliente que les impide iniciar sesión.

En términos generales, no lanzaría ningún tema de alta prioridad ni ningún problema de prioridad media con gravedad de 1 a 4. Obviamente, en un mundo ideal arreglarías todo, pero nunca tuve la suerte de tener esa opción.

Reemplace su sistema de seguimiento de errores con fogbugz y elimine completamente el campo de gravedad.

Ver Prioridad vs Severidad

Tuve el mismo problema con uno de nuestros clientes. Al final, creamos un documento en el que se describe qué tipo de errores coincidirían con una cierta gravedad. Aparte de una discusión ocasional usando este documento como una guía, parece funcionar.

Pero tenga en cuenta que los equipos de prueba y los equipos de desarrollo pueden tener opiniones muy diferentes sobre qué es un error grave y qué no. Desde el punto de vista de los probadores, un error de diseño pequeño puede ser de alta prioridad cuando un desarrollador simplemente diga que nadie lo notará.

En nuestro documento, esos errores pueden ser de alta prioridad si son "dañinos para la marca", es decir, si el error de diseño está en el logotipo o en uno de los productos, entonces es grave: si solo hay un párrafo en la página que está a 2 píxeles, entonces no es.

Una opción es que el propietario del producto determine la prioridad del error. Si bien hay cierta intuición general sobre cuán "malo" es un error, puede ser responsabilidad del propietario del producto establecer un orden de precidencia (es decir, el error A debe corregirse antes del error B, etc.).

Cuanta más información (clara y concisa) pueda proporcionarse al propietario del producto puede ayudarlo a hacer esas determinaciones (es decir, cuántos usuarios han experimentado el error, qué funciones no están disponibles como resultado del error, etc.).

Utilizo las siguientes categorías para las características y los errores:

Showstopper, el programa (o una característica principal) no funcionará
Debe tener, una parte significativa de los clientes se molestará por esto
Hubiera sido, algunos clientes serán molestados
Es bueno tener, algunos clientes quieren esto

Normalmente planea arreglar 1, 2 y 3, pero 3 a menudo se pospone para una próxima versión debido a restricciones de tiempo.

El probador dice qué está roto
El desarrollador estima cuánto trabajo será para arreglar
El cliente decide el valor comercial, es decir, la prioridad.

Creo que esta es la escala que utilizamos en un trabajo anterior:

Causa pérdida de archivos o inestabilidad del sistema.
Bloquea el programa.
La característica no funciona.
La característica no funciona, pero hay soluciones.
Problema cosmético.
Solicitud de mejora.

Algunas veces se abusaba de esto: si una característica estaba tan mal diseñada que alguien no podía encontrar la manera de usarla, eso se clasificaba como un 6 y nunca se solucionó.

Trabajo en sistemas de centros de control de emergencia, por lo que este conjunto de niveles de errores es un poco, bueno ... extremo :

alguien muere
falla total del sistema que requiere invocación DR
falla del servidor que requiere respuesta del ingeniero
falla que involucra continuidad de pérdida de llamada
falla que implica pérdida de datos
datos incorrectos grabados
falla de la aplicación - no recuperable
falla de la aplicación: no recuperable, pero reiniciado automáticamente
no cumple con las especificaciones de requisitos, no hay solución
no cumple con la especificación de requisitos, pero tiene una solución alternativa
cosmética - diseño, etc.
en realidad una solicitud de función

Eso está fuera de mi cabeza. En caso de que te lo estés preguntando, es de lo más extremo a lo menos :-)

Algunas cosas que usamos antes. Dividimos la clasificación de defectos en prioridad y gravedad.

Gravedad (establecida por el remitente durante el envío del defecto)

Mayor (5): pérdida de datos, daño de hardware posible o una falla relacionada con la seguridad
Alto (4): pérdida de funcionalidad sin una solución razonable
Medio (3): pérdida de funcionalidad con una solución razonable
Bajo (2): pérdida parcial de una función o un conjunto de características (la función aún cumple los requisitos de diseño)
Más bajo (1): un error cosmético

Prioridad (ajustada por desarrollo, gestión y control de calidad durante la evaluación de defectos)

Más alto (5): el sistema es prácticamente inutilizable con este defecto.
Alto (4): el defecto tendrá un serio impacto en la capacidad de la compañía para vender y mantener este sistema.
Medio (3): la compañía perderá algo de dinero si este defecto está en el sistema, pero podría ser más importante cumplir con el cronograma. Fix después del lanzamiento.
Bajo (2): No demore la liberación, pero solucione este problema después.
Más bajo (1): corrige según lo permitan el tiempo y los recursos.

Ambos números juntos crean un número de prioridad de riesgo (RPN). Simplemente multiplique la severidad con prioridad. Un resultado más alto significa un mayor riesgo. 25 define la última bomba de defecto. 1 se puede hacer durante el tiempo de inactividad o si alguien está aburrido y necesita algo que hacer.

Primer objetivo: los defectos con una calificación del más alto o más alto de cualquier tipo se deben corregir antes de la publicación. Segundo objetivo: los defectos con RPN> 8 deben repararse antes de liberar el producto.

Esto es, por supuesto, un poco artificial, pero ayuda a darles a todas las partes (Soporte, QA / Test, Ingeniería y Gerentes de Producto) una herramienta para establecer prioridades sin eliminar la opinión del otro lado.

"He estado allí hecho eso".

He tenido esta discusión una y otra vez, en diferentes proyectos. Intentamos combinar la prioridad con la gravedad, pero la lección que aprendí es: ¡no combine la gravedad con la prioridad !

Tuvimos muchas lluvia de ideas y reuniones que terminaron con las palabras " esto es ". Múltiples documentos de directrices se han creado y distribuido entre las diferentes "partes", pero después de un tiempo descubrimos que no funcionó al final. Diferentes "partes" piensan diferente sobre los errores: nuestro servicio de ayuda tiene otra comprensión de la prioridad que el equipo de desarrollo o las ventas.

Tener una severidad y un nivel de prioridad rápidamente se convertirá en una gran confusión porque:

al usar números (entre 1 y 5) uno no sabrá lo que significa cada número
¿Qué pasa si un problema tiene la mayor prioridad posible, pero la gravedad más baja posible, y estoy seguro de que esto sucederá?
¿Qué pasa si alguien reduce la gravedad? ¿Necesita reducir la prioridad también?

"Entonces, ¿qué deberías hacer entonces?":

Solo use un tipo de indicador para el "nivel" de un problema: no importa cómo lo llame.
Use números (por ejemplo, 1 - 5, pero podría ser más o menos según sus necesidades) para indicar claramente la importancia, pero combínelo con una palabra clave para que quede claro lo que significa (por ejemplo, "agradable tener", "mostrar stopper"). ) Para algunas personas, prio 1 significa el más importante, para otros 5 does -> por lo tanto, una palabra clave para indicar lo que significa un número es necesario.
Haga una distinción entre un ''problema normal'' o ''alerta roja''. En nuestro caso, una ''alerta roja'' debe resolverse inmediatamente y ponerse en producción inmediatamente. Un problema normal seguirá el desarrollo normal-prueba-despliegue-flujo. La prioridad / severidad / sin embargo-cómo-usted-llame-solo se debe establecer para problemas normales y se ignorará para ''alertas rojas''. *> En la práctica, una ''alerta roja'' puede convertirse en un
''Problema normal'': el equipo de soporte descubrió un error importante y creó una ''alerta roja''. Pero después de algunas investigaciones descubrimos que los datos se habían "corrompido" en la base de datos ya que se insertaron allí directamente y no a través de la aplicación. *
Elija una buena herramienta que le permita personalizar el flujo; pero la mayoría de las herramientas sí.

Use niveles de prioridad que deliberadamente no tienen nada que ver con la gravedad o el impacto , y describa solo la posición conceptual del error en el cronograma. Este campo determinará en qué errores se trabaja, por lo que debe ser muy claro que los hechos del error no están abiertos para la negociación.
Utilice niveles de gravedad que tengan deliberadamente definiciones concretas y verificables que no tengan nada que ver con la programación o la prioridad . He trabajado con éxito con las definiciones de gravedad utilizadas por Debian BTS , generalizadas para aplicar a proyectos de programación en general.

De esta manera, la gravedad es mucho más una cuestión de hecho verificable , independiente de una declaración de prioridad. La prioridad es, entonces, libre de ser alterado arriba y abajo por negociación o lo que sea, sin afectar la información objetiva en el campo de gravedad.

Intentar combinar tanto la "severidad" como la "prioridad" en un solo campo conducirá a argumentos agotadores del alma y tiempo perdido . El reportero de errores necesita una guía firme de hecho para determinar qué tan "malo" es el error, y esto debe ser acordado fácilmente por partes independientes. La prioridad, por otro lado, es el objetivo correcto para la negociación y la programación de juegos.

Estoy de acuerdo con la gente de FogBugz en que esto se debe mantener súper simple: http://fogbugz.stackexchange.com/questions/352/priority-vs-severity

Inventé este esquema, que me resulta fácil de recordar:

pS: los segundos importan, por ejemplo, el servidor está en llamas
pM: los minutos importan, por ejemplo, algo está roto
pH: las horas importan, es decir, no te vayas a la cama hasta que esto esté hecho
pd: días importantes, es decir, prioridad normal
pw: las semanas importan, es decir, menor prioridad
pm: los meses importan, es decir, no hay prisa
py: los años importan, es decir, quizás / algún día, es decir, lista de deseos

Es aproximadamente paralelo al esquema de Debian: http://www.debian.org/Bugs/Developer#severities

Me gusta porque combina de manera directa la prioridad y la gravedad en un solo campo para el cual es fácil establecer un valor.

PD: También puede elegir urgencias intermedias como "pMH" para el intervalo entre "minutos importan" y "horas importan". O "pHd" está entre "horas matizadas" y "los días importan" - aproximadamente, "literalmente no se jale durante toda la noche pero no trabaje en ninguna otra cosa hasta que esté hecho".