project-management - office - project management software

¿Deberíamos arreglar ese error? (14)

Al probar errores para una versión, ¿qué criterios se utilizan generalmente para determinar si la falla se solucionará para la versión?

¿Vale la pena endeudarse técnicamente si no lo solucionas, o si haces una solución rápida y sucia con la intención de corregirlo más tarde?

Como regla, corregiremos cualquier error que bloquee 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 priorizar errores como lo mencionaron 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).

Con bastante frecuencia 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 los perros dormidos mentira.

Llega un punto donde el código necesita ser bloqueado. Las correcciones de código requieren más pruebas de regresión y eso lleva tiempo.

Triste pero cierto.

Cosas que afectan la severidad que aún no he visto en esta publicación.

SLA: ¿tiene un impacto en SLA?
Internal (mantenimiento) vs External Benefit - Beneficio externo casi siempre obtiene una mayor prioridad
Visual vs Funcional - funcional generalmente obtiene una mayor prioridad
¿Quién lo encontró? (cliente versus compañero de trabajo) - El cliente obtiene una mayor prioridad

Criticidad, impacto y dinero generalmente.

Criticidad: ¿Qué sucede? ¿Daña los datos, reduce el sistema, ese tipo de cosas?
Impacto: ¿Cuántas personas se verán afectadas?
Dinero: ¿alguien nos pagará (o peor, retendrá el pago) si nosotros (no) lo reparamos?

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

Realmente vale la pena leer el artículo, pero si lo quiere resumir en una lista de verificación:

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

En mi experiencia, es solo:

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

Escribo software de servidor RDBMS, por lo que cualquier error que pueda causar daños en los datos es inmediatamente un stop-stop. 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 cuán desestabilizante sea la solución y cuánto tiempo demorará.

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

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

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

Ya hay muchas respuestas excelentes y, por supuesto, las circunstancias varían según el proyecto / empresa / error / hora de lanzamiento / dependencias / ...

Sin embargo, he encontrado que las siguientes dos métricas son una guía útil.

¿Cuántos usuarios se ven afectados?
¿Qué tan gravemente se ven afectados?

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

Gravedad del efecto en el usuario
Frecuencia de apariencia
¿Hay solución disponible?
Costo de arreglar
Hora de arreglar
Tiempo restante antes de la fecha límite de lanzamiento
Disponibilidad de recursos que pueden hacer la corrección

En términos de tomar decisiones, no se puede mejorar la respuesta principal en función de la gravedad, el impacto, el costo, etc.

Sin embargo, debe tener un poco de cuidado acerca de cuándo aplica estas reglas. He trabajado en demasiados proyectos en los que los errores se descontrolaron porque no eran responsabilidad de ninguna persona. Las mejores reglas de trabajo que se me ocurrió fueron

Si encuentra un error, levante un informe de error
Si puedes arreglarlo, hazlo. (Se genera un informe ya que puede ser necesario informar sobre la existencia del error)
Si el líder del 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.
Revise los errores 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, tenga una visión amplia del proyecto de cuáles son los errores principales (esto puede ser una prioridad separada, por ejemplo, una lista de los 5 principales)
Aliente a los programadores a corregir errores junto con las tareas de desarrollo

ENTONCES cuando estás considerando un lanzamiento.

ramificar el código e instigar una característica de congelación
identifica los errores que intentas corregir (no es necesario pedirlos :-))
solo agregue errores a esta lista que sean reproducibles en el código congelado y acordado

Esta es definitivamente una pregunta específica de dominio. Escribo grandes aplicaciones de trading para Hedge Funds, Prop Trading Desks, Mutual Funds, etc.

Las cosas que violan el cumplimiento o causan otros problemas legales son muy ^ 4 malas
Las cosas que pueden causar un exceso de transacciones (quería comprar 100,000 acciones de DTE pero le conseguimos 100.200) son muy ^ 3 malas
Las cosas que evitan que el cliente se negocie cuando lo desea son muy ^ 2 malas
Las cosas que incomodan al cliente son muy malas

El otro día hablé con un "Administrador de triage de errores" que trabaja en un campo diferente. Él lo dijo simplemente:

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