¿Deberíamos solucionar ese error?

Question

Al probar errores para un lanzamiento, ¿qué criterios se usan generalmente para determinar si el error se solucionará para el lanzamiento?

Answer 1

El artículo canónico sobre esto es My life as a Code Economist, por Eric Sink.

Realmente vale la pena leer el artículo, pero si quieres que resumió para usted en una lista de control:

1. Cuando ocurre este error, lo malo es el impacto? - Gravedad
2. ¿Con qué frecuencia ocurre este error? - Frecuencia
3. ¿Cuánto esfuerzo se requeriría para solucionar este error? - Costo
4. ¿Cuál es el riesgo de solucionar este error? - Riesgo

Answer 2

• Severidad del efecto sobre el usuario
• frecuencia de aparición
• ¿Está disponible solución?
• Costo para fijar
• tiempo para arreglar
• tiempo restante antes del cierre de la liberación
• disponibilidad de los recursos que pueden hacer el arreglo

Answer 3

En mi experiencia, es simplemente:

• Gravedad del error
• Cantidad de tiempo de desarrollo libre antes del lanzamiento.

Answer 4

Criticality, impacto y dinero generalmente.

1. Criticality: What happens? ¿Daña los datos, reduce el sistema, ese tipo de cosas?
2. Impacto: ¿Cuántas personas se verán afectadas?
3. Dinero: ¿Alguien nos pagará (o peor, retendrá el pago) si nosotros (no) lo arreglamos?

Answer 5

Escribo el software de servidor RDBMS, por lo que cualquier error que pueda causar daños en los datos es inmediatamente un stop-show. Además, cualquier error que pueda hacer que el servidor de la base de datos falle bajo un uso relativamente normal calificaría, al igual que devolver datos incorrectos de una consulta.

También tiene que depender de qué tan desestabilizadora es la corrección y cuánto tiempo llevará.

Answer 6

Muy frecuentemente para nosotros si la gravedad es baja y el producto está a punto de publicarse, es mejor guardar la solución para la próxima versión.

El principio de let let dogs dogs lie.

Llega un punto en el que el código debe bloquearse. Las correcciones de código requieren más pruebas de regresión y eso lleva tiempo.

Triste pero cierto.

Answer 7

Esto es definitivamente una pregunta específica de dominio. Escribo grandes aplicaciones comerciales para los fondos de cobertura, apoyo mesas de operaciones, fondos de inversión, etc. así:

1. cosas que violan el cumplimiento o causar otros problemas legales son muy malas^4
2. cosas que pueden causar exceso de comercio (usted quiere comprar 100.000 acciones de DTE, pero conseguimos que 100.200) son muy^3 mala
3. cosas que impide que el cliente comercial cuando quieren son muy^2 mala
4. cosas que molestar al cliente es muy malo

El otro día hablé con un "Administrador de triage de errores" que trabaja en un campo diferente. Lo puso simplemente:

Primero corrijo el colapso, luego corrijo las cosas que nos hacen perder dinero, luego arreglo las cosas que nos hacen quedar mal, luego corrijo todo lo demás.

Answer 8

Cosas que afectan a la gravedad No las he visto aún en esta publicación.

• SLA - ¿Tiene un impacto en SLA?
• interna (mantenimiento) vs beneficio externo - beneficio externo casi siempre se hace mayor prioridad
• Visual vs Funcional - funcional generalmente se hace mayor prioridad
• Quién lo encontró? (Cliente vs compañero de trabajo) - Cliente obtiene mayor prioridad

Answer 9

Como regla, aplicamos un parche a cualquier error que interrumpa el sistema fuera del ciclo de publicación.

Cualquier otro error se agrega a la acumulación de productos y se prioriza junto con las nuevas características. Al determinar qué incluye el lanzamiento, simplemente tomamos esas tareas con la más alta prioridad. Esto funciona bien para nosotros ya que tenemos un ciclo de publicación mensual.

Usamos el mismo sistema de priorización de errores mencionado por otros en este hilo, con la excepción adicional de que un cliente puede pagar para aumentar la prioridad de un error (o característica).

Answer 10

Hay mucho que decir acerca de la mentalidad de "defecto cero". Los errores de cualquier tipo deben ir siempre a la cima de la pila, o eventualmente lo abrumarán.

Por supuesto, en el mundo real, obtener esa nueva característica brillante para que pueda ganar ese gran cliente nuevo podría ser más importante que arreglar una ligera molestia. El tiempo de comercialización realmente supera la calidad a veces.

Answer 11

Vale la pena entrar en technical debt al no arreglarlo, o hacer una solución rápida y sucia con la intención de corregirlo más tarde.

Answer 12

Hay un montón de grandes respuestas ya existen como de las circunstancias supuesto variará dependiendo del proyecto/empresa/error/hora para la salida/dependencias/...

he encontrado sin embargo los siguientes dos métricas una guía útil.

• ¿Cuántos usuarios se ven afectados?
• ¿Cuán gravemente se ven afectados?

Cuanto más alto sea el error marcado en ambas variables, antes se debería corregir.

Answer 13

Estoy de acuerdo con @Chris Upchurch, pero creo que un factor clave es tener un acuerdo de todas las partes antes de entrar en crunchtime. De esa manera, puede ejecutar su lista de verificación con un mínimo de dientes rechinando y golpeando el pecho.

Answer 14

En cuanto a la toma de decisiones, no puede mejor la respuesta más común basado en la gravedad, impacto, coste, etc.

necesidad de ser un poco cuidadoso con cuando se aplican estas reglas sin embargo. He trabajado en demasiados proyectos en los que los errores se dejaban fuera de control porque no eran responsabilidad de ninguna persona. Las mejores reglas de trabajo que se me ocurrió fueron

• Si usted encuentra un error elevar un informe de error
• Si se puede arreglar, que lo hagan. (se genera un informe ya que la existencia del error puede necesitar informes)
• Si el jefe de equipo entiende el error, debe asignarse una prioridad (u otras medidas utilizadas por el equipo). Agregue la información 'lo que esto significa realmente'. Es importante que el líder del equipo tenga (algo) de control sobre la lista de errores.
• Errores de revisión no corregidos/priorizados en el nivel de gestión. Los errores no entendidos son un riesgo enorme y los poderes deberían tener la oportunidad de comprender el riesgo.
• En todo momento, tienen una amplia vista del proyecto de lo que los principales errores son (esto puede ser separada de prioridad por ejemplo, un 5 lista superior)
• animar a los programadores para corregir errores junto con las tareas de desarrollo

ENTONCES cuando esté considerando un lanzamiento.

• rama del código e instigar una característica congelar
• identificar los errores que la intención de corregir (sin necesidad de pedir ellos :-))
• sólo se suman los errores de esta lista que son reproducibles en el código congelado y de acuerdo