¿Por qué necesitamos tanto prioridad como gravedad?

Entiendo lo que determinan, pero ¿es realmente útil asignarlos a los problemas encontrados? Quiero decir, es necesario arreglarlo rápidamente o no.

Sé cómo configurarlos, clasificarlos, etc. Sé que IEEE / ISO requieren hacerlo. Simplemente no veo por qué.

Es absolutamente posible que esos valores difieran. Si tiene que realizar una venta a una agencia gubernamental importante que requiere un alto rendimiento pero nunca usará el módulo X, entonces tiene mucho sentido comercial corregir un error menor de disponibilidad de la base de datos antes que un error grave en el módulo X. Básicamente, las razones técnicas no son el único factor cuando ejecuta un negocio de software .

Errores de fecha y hora

Error: el procesamiento de fin de año dañará totalmente su base de datos. Eso es claramente un error grave.

Fecha: 15 de diciembre. El error es de alta prioridad.

Fecha: 1 de febrero. El error es de baja prioridad.

Lanzamiento accidental de error de misil

Error: el software de control ICBM vomita cuando va del 28 de febrero al 1 de marzo en años divisibles por 4. El resultado es un lanzamiento sin comando.

Eso es un error tan grave como puede existir. Sin embargo, la prioridad es muy baja: ¿hay alguna posibilidad realista de que el software esté en uso cuando se active la condición?

Inadvertidas palabras "malas" en la pantalla

Error: los mensajes que desbordan su espacio en la pantalla dan como resultado una referencia profana inadvertida a la aparición de Bob. (Mundo real: teníamos gente trabajando en el departamento de "Final Ass". "Ass" = "Assembly".)

Desafortunadamente, mañana hará una presentación en la que conseguir la venta es decisivo para la empresa. Estás haciendo la presentación a alguien llamado "Bob". Severidad: Muy baja. Prioridad: Muy alta.

Tu escribiste:

Quiero decir, es necesario arreglarlo rápidamente o no.

Eso es correcto. Sin embargo, si usted es como la mayoría de las empresas, sus recursos son limitados. O no tienes suficientes personas para solucionar todos los problemas, o no tienes suficiente tiempo.

Dado el hecho de que es necesario corregir un error rápidamente o no, y tiene muchos errores que deben corregirse, "prioridad" responde a la pregunta "¿cuál soluciono primero"?

La gravedad, por otro lado, es un indicador utilizado por la persona que establece la prioridad. Desde el punto de vista de un desarrollador, la gravedad es un punto discutible. Desde la perspectiva del que asigna el trabajo, la gravedad es una información importante que ayuda con el proceso de toma de decisiones.

Por supuesto, todo esto es información muy general. Si usted es un equipo con una acumulación de errores imposiblemente larga, la prioridad y la gravedad significan algo completamente diferente que si estuviera en un equipo que tiene una base de datos de errores casi vacía.

Si está en un equipo donde "alta gravedad == alta prioridad", nada de esto importa y no necesita ambas métricas. Al final del día, estas son solo herramientas. Su equipo necesita decidir cómo usarlos. Para su equipo puede no tener sentido usar ambos.

En mi humilde opinión, poner prioridad y gravedad es solo burocracia.

En la práctica, solo necesita una medida de "importancia". A menudo, se usa la prioridad para ello, y la gravedad se usa como término técnico como "alto = sistema de fallas o lo deja inutilizable", "medio = comportamiento defectuoso, potencialmente dañino", "bajo = molesto, molesto pero inofensivo"

Por lo general, la prioridad va de la mano con la gravedad. Algunos ejemplos contrarios son una "molestia en la que todos siempre se quejan" o un "accidente que ocurrió una vez en un ambiente exótico".

... pero, al final, como desarrollador (o administrador, etc.) solo necesita saber en qué orden debe arreglar / mejorar las cosas, eso es todo. Entonces una medida es suficiente.

La necesidad de prioridad es clara: es saber en qué orden deben abordarse los informes de errores. El otro, en mi humilde opinión como de costumbre, es la burocracia. ¿Por qué lo necesitas? Aparentemente es inútil para ordenar porque la prioridad lo hace. Y las consecuencias (descripción de la gravedad) se describen en el informe de error de todos modos.

Incluso creo que es dañino porque deja menos claro qué error es más importante:

• Algunos pueden pensar que un error "crítico" tiene mayor prioridad que un error "de alta prioridad".
• Algunos usuarios que informan un error pueden confundir gravedad y prioridad
• ... en conjunto, más bien agrega confusión sobre el orden en que deben abordarse los errores

Además de otras respuestas, considere este escenario: el error A tardará 30 minutos en solucionarse y tiene una gravedad 'baja'; El error B puede tardar más de 2 semanas en solucionarse y tener una gravedad 'alta'. Además, el error B puede requerir mucha discusión y coordinación en el equipo de desarrollo y quizás fuera del equipo; El error A puede ser reparado por un solo desarrollador inmediatamente. Está perfectamente bien establecer una mayor prioridad en el error A.

Por supuesto, "severidad" y "prioridad" pueden interpretarse de diferentes maneras.

En un pequeño rastreador de errores que hice para mi propio uso, preferí 'dificultad' y 'prioridad' donde los problemas de alta gravedad siempre tendrían la máxima prioridad, y podría decidir retrasar el trabajo en base a la dificultad.

Una cosa que no me gusta de la 'gravedad' es que solo se aplica a errores y no a características. Puede ser mejor tener una lista única de todos los problemas ordenados por prioridad y dificultad, ya que es más directamente útil decidir "¿en qué trabajaré después?".

Diseñé e implementé procesos en una empresa de software que obtuvieron la certificación ISO9001: 2007. Ha habido actualizaciones al estándar desde 2007, por lo que puede haber requisitos adicionales que no conozco ... sin embargo:

El estándar ISO9001 se trata de garantizar que su empresa diseñe e implemente procesos que tengan circuitos de retroalimentación para mejorar el proceso cuando se identifiquen defectos del producto y del proceso.

Durante la fase de diseño, los requisitos se centran en si la solución propuesta, si se implementa correctamente, realmente resolvería el resumen de diseño (validación) y verificar si la implementación realmente se ha implementado sin defectos (verificación)

En el ciclo de retroalimentación, cuando se identifican defectos, no es suficiente que se registren. También se debe evaluar la gravedad de un defecto y priorizar el reproceso.

La parte clave es que la norma ISO no define cómo su empresa en particular decide evaluar su gravedad y tomar decisiones sobre la prioridad. Es un asunto comercial y de gobierno que la empresa debe decidir y documentar.

Como está escrito en el estándar como un requisito, cualquier empresa certificada tendrá un proceso para evaluar la gravedad de un defecto y un proceso para determinar la prioridad del trabajo para corregir el error. Definitivamente son dos decisiones separadas que deben tomarse.

La gravedad del error es solo un punto de datos. Impacto en el cliente es otro punto de datos. También hay un esfuerzo por corregir, la antigüedad del defecto, la vida comercial restante en el producto y cualquier otro factor que la empresa decida incluir en su toma de decisiones. Lo único que no debe escribirse como "defecto presente para que el gerente de producto decida la prioridad", ya que eso solo define la autoridad para tomar la decisión y no define el proceso que siguen para tomar la decisión.

Prefiero la priorización que está sesgada hacia la entrega de una alta tasa de cambios pequeños e importantes, ya que esto parece proporcionar el mejor impulso para la confiabilidad general del producto. Esto significa que un error grave que requerirá mucho trabajo para solucionarlo necesitaría que su trabajo se descomponga en fragmentos más pequeños para obtener la prioridad suficiente para ser programado.

Por razones que difieren mucho en prioridad y gravedad:

Un simple ejemplo. Imagine que tiene un lugar angosto que evita la escala de su sistema: algunos algoritmos tienen una complejidad O (N ^ 3), donde N es el recuento de las tiendas del cliente. El cliente dice que abrirá 200 nuevas tiendas el próximo año y que los cálculos necesarios (distribución de mercancías, planificación del transporte, etc.) no se completarán a tiempo. Pero, actualmente este cliente tiene solo 30 tiendas, y los recursos son suficientes. La tarea de optimizar este algoritmo (a O (N ^ 2) o mejor) es definitivamente importante (perderá el cliente si no se implementa), pero probablemente no sea urgente: tiene unos meses para implementar el nuevo algoritmo.

Ejemplo 2: una aplicación se bloquea sistemáticamente, pero esta versión deja de usarse en unos días debido a una actualización o migración. La reparación es urgente porque los bloqueos realmente afectan la experiencia del usuario, pero es de poca importancia.

Por supuesto, ambos parámetros se unifican usando alguna métrica (ya sea formal o informal) para producir un plan de trabajo a corto plazo, porque este último es unidimensional (secuencia de tareas). Pero a largo plazo, no se unificarán.