¿Cómo dar cuenta de una iteración de corrección de errores?

Hemos implementado Scrum con bastante éxito durante los últimos 5 meses. Sin embargo, estamos lejos de 3 semanas PROD sin jamás hacer cualquier prueba de integración de extremo a extremo. ¡AY! Necesito ayuda. Sin abordar las causas de esto (en ESTE punto), ahora necesitamos planificar la iteración actual, que consiste en mejoras menores y MUCHAS correcciones de errores aún desconocidas. ¿Cómo explicas este escenario? ¿Cómo planea su iteración para corregir errores que aún no se han encontrado?

Scrum o no, la corrección de errores es básicamente imposible de predecir. Lo mejor que creo que puedes hacer es:

• Comience a probar de inmediato, sin una estimación inicial de cuándo se realizará.
• Cuando descubra cada error, haga un análisis inicial hasta el punto en que pueda estimarlo.
• Estime el error y decida si tiene que arreglarse y si debe arreglarse para la revelación inicial.
• Si tiene que ser reparado, agréguelo a la iteración.
• Trazar un gráfico de quemado. En algún momento comenzará a disminuir, lo que significa que ya no encontrarás errores más rápido de lo que logras solucionarlos. En ese momento, podrá dar una estimación aproximada (y progresivamente más precisa) cuando se pueda realizar el lanzamiento.

De lo que debe asegurarse la próxima vez que comience a probar temprano y corrija los errores a medida que avanza. Todas las metodologías sensatas, ágiles o no, requieren la reparación de errores conocidos antes de avanzar con nuevas características. También debe tener en cuenta cuánto tiempo se dedicó a la corrección de errores de cada función, para que pueda mejorar su estimación para implementar la función en el estado depurado en el futuro.

La estimación y la corrección de errores están bien cubiertas por Joel Spolsky en Programación Basada en Evidencia y Corrección de errores . No está relacionado con Scrum, pero creo que es lo suficientemente general como para que gran parte se aplique.

¿Cómo dar cuenta de una iteración de corrección de errores? ¿Cómo planea su iteración para corregir errores que aún no se han encontrado?

En cuanto a una "iteración de corrección de errores". Los errores encontrados no deben tratarse de manera diferente a las historias. Trabaje con el equipo para estimar el esfuerzo (puntos de la historia) para corregir cada error y trabaje con el propietario / cliente del producto para decidir si el error debe pasar a la siguiente iteración.

En cuanto a "errores aún por encontrar". Preferiblemente, el equipo está encontrando y solucionando problemas en cada iteración. Si no es así, discuta esto en su próxima retrospectiva. Si la calidad del producto es tan baja que no es posible su lanzamiento, mueva inmediatamente sus mejores " buscadores de errores " para encontrar errores (no corregirlos). Si la calidad es lo suficientemente alta como para proporcionar una versión beta para usuarios seleccionados, hágalo. Si no puede, entonces, como mínimo, proporcione demostraciones de usuarios en vivo que discutan las áreas débiles que recomienda mejorar.

No planificamos 'iteraciones de corrección de errores', pero sí planificamos iteraciones de prueba del sistema antes de cada lanzamiento. La prueba del sistema consiste en pruebas de integración, regresión y reales en todas las partes del producto. Los probadores prueban el producto (un sistema heredado bastante grande) y los desarrolladores corrigen los errores encontrados. Si no se encuentran errores, comenzamos a investigar los cronogramas de características para el próximo proyecto o trabajamos en mejoras internas.

Actualmente, planeamos seis semanas de pruebas del sistema después de la congelación del código (para un proyecto de cinco meses, prueba del sistema incluida), para asegurarnos de que todo funcione. Esto está por encima de todas las pruebas que se realizan durante las iteraciones de implementación.

Debe definir un conjunto de criterios de "lanzamiento". Estos podrían incluir:

• Tiempo medio entre fallos
• Número de defectos encontrados por día
• Severidad de defectos encontrados por día
• Número de defectos pendientes

etc.

Luego, al final de cada iteración, donde algunas personas realizan pruebas (ya sea manualmente o escribiendo pruebas automáticas) y otras corrigen la verificación para ver si cumple con sus criterios. Si tienes una versión, si no, entonces ve a otra iteración.

Debería existir la posibilidad de una anulación de esto, así como a menudo los números en bruto no presentan una imagen realista de la aplicación. Es posible que tenga un par de defectos realmente graves, pero solo se manifiestan en condiciones poco frecuentes con las que puede vivir a corto plazo.

Una forma de hacerlo es escribir historias para sus pruebas de integración, durante las cuales escribe nuevas historias para cualquier error que encuentre, luego corrija las historias de errores en la próxima iteración.

Otra forma de hacerlo es hacer una historia que diga "Solucionar errores encontrados en las pruebas de integración". De versiones anteriores, debe tener una idea de cuántos problemas se encuentran generalmente y qué tan difíciles son de solucionar, para que pueda asignar puntos de la historia en función de ese conocimiento. Tal vez podría dividirlo en componentes si eso lo hace más manejable. Siempre hay una incertidumbre inevitable en esto. Agregue algunos puntos de historia adicionales para explicarlo.

Probablemente se haya dado cuenta tardíamente de que, si es posible, la mejor manera es incorporar una pequeña prueba de integración en cada iteración. Felicitaciones por reconocer eso y mejorar un poco tu proceso para tu próximo lanzamiento.