¿Cómo tratamos los errores en el entorno Scrum?

Recientemente comenzamos a trabajar en Scrum con uno de nuestros productos. Antes de eso, trabajábamos con una metodología Waterfall.

Creamos historias para la nueva característica y también incluimos los errores para la próxima versión y estamos estimando historias en puntos de historia. No estamos seguros de cómo lidiar con los errores. ¿Necesitamos estimar los puntos de la historia o el número de días para los errores?

El equipo encuentra que, para algunos de los errores, la mayor parte del esfuerzo se dedica al análisis, ya que el error requiere esfuerzos de depuración y resolución de problemas en lugar de la implementación real del código.

¿Cómo estimamos estos casos específicos, donde la mayor parte del esfuerzo se dedica al análisis y parte de ese análisis puede tardar días o semanas en completarse?

Por favor ayuda

Esto parece que se ha preguntado (y respondido) antes, pero no estoy extrayendo duplicados. ¿Alguien más puede encontrar un duplicado que sea un objetivo cercano válido?

Respuestas (3)

Elija un enfoque de estimación coherente que utilice puntos de la historia (no confíe en las horas).

Tienes opciones:

Opción 1:

Nunca estimes el tamaño del defecto en puntos de historia. Razonando, surge un defecto cuando no se cumplió un criterio de aceptación anterior de una historia existente (ya estimada). Al estimar el defecto de una manera, se cuenta dos veces la parte del trabajo requerida para entregar la historia.

Resultado, las iteraciones con muchos defectos muestran una velocidad más baja. El equipo se ve obligado a discutir por qué su velocidad ha disminuido y por qué se producen tantos defectos. Con... es más difícil para el equipo comprometerse a completar todo en la iteración si no lo han dimensionado formalmente.

Opcion 2:

Siempre estime puntualmente el tamaño del defecto. Razonando, en una iteración queremos alinear la carga de trabajo de la historia/defecto con lo que el equipo tiene capacidad para completar.

Resultado, el equipo mantiene una velocidad constante y puede comprometerse con precisión a trabajar dentro de una iteración. Con... no es tan obvio empíricamente que el trabajo de valor agregado está disminuyendo a medida que aumenta la carga de defectos.

La estimación de horas y la asignación de tareas quedan a su discreción en Scrum. Personalmente, desaconsejo el seguimiento formal de tareas u horas en su software scrum, ya que genera una sobrecarga adicional y puede dar una sensación de microgestión indeseable a algunos equipos.

"Con... es más difícil para el equipo comprometerse a completar todo en la iteración si no lo han dimensionado formalmente". no realmente, ya que esto se hace durante la planificación del sprint: usa su capacidad en horas para asignar tiempo a esos errores, haciendo este dimensionamiento formal en ese momento.
La estimación de horas durante la planificación del sprint no es un requisito de scrum. Por estimación formal me refiero a una estimación puntual de la historia. Es posible retrocalcular la capacidad en función de las prácticas históricas de señalización de historias, pero nuevamente, solo sabe que tiene X capacidad total, de las cuales Y historias + Z defectos deberían sumar X. Si no apunta, estime los defectos sin embargo, está haciendo Y + Z puede o no ser igual a X.

Si está haciendo Scrum, tenga como política que hablará sobre el progreso de los errores durante la reunión diaria. Cuando sepa cuál es la causa raíz, puede comenzar a manejar el error como una historia de usuario: puede dar tamaño o estimaciones porque sabe con lo que está tratando.

Si no escucha ningún progreso, digamos en 2 o 3 días, sobre el problema, debe hacer algo al respecto porque un error grave puede poner en riesgo su proyecto. Puede sugerir que más personas se ocupen del problema, puede cancelar el sprint (discuta esta posibilidad con su PO) o puede escalar la situación y pedir sugerencias al OP o a otros equipos.

Lo primero es lo primero

Si la corrección del error demora días o incluso semanas, es una clara señal de un diseño de código deficiente . Esto significa que el código de su proyecto es difícil de probar, lo que debería preocuparle mucho más que la estimación de errores.

Estimacion

A medida que comienza con Scrum y está acostumbrado a las estimaciones de días/horas, le sugiero que maneje cuatro tipos de problemas:

  1. Historia del usuario. Agrega la funcionalidad del producto de cara al usuario. Ejemplo: "Como usuario quiero iniciar sesión a través de Facebook". Estimar historias de usuarios en puntos de historia .
  2. Subtarea. Hijo de una historia de usuario. Refleja lo que se debe hacer para completar la Historia. Cada historia debe tener al menos una subtarea. Ejemplo: "Implementar vista de inicio de sesión". Estimar subtareas en horas .
  3. Bicho. La falta de coincidencia de cómo se esperaba que funcionara el sistema frente al comportamiento real. Ejemplo: "Hacer un pedido redirige a un usuario a la página 404". Estimación de errores en horas .
  4. Tarea. Cualquier cosa, que no tenga nada que ver con la experiencia del usuario y no pertenezca a ninguna historia de usuario. Ejemplo: "Instalar y configurar Jenkins". Estimar Tareas en horas .

Así es como se beneficia de este enfoque:

  • Puedes medir cómo evoluciona tu Producto. Solo usa la velocidad de Sprint basada en Story Points. Lo que muestra claramente que si su Sprint está lleno de tareas y errores, su Producto no evoluciona.
  • Puede rastrear su Sprint Burndown. Todo lo que haces en el Sprint es una subtarea de una historia, un error o una tarea. Los estima en horas y puede realizar un seguimiento del rendimiento dentro del Sprint.

Pero presta atención al primer párrafo por favor. Las correcciones de errores nunca deberían llevar días o semanas.

Gracias por la respuesta. El motivo por el que tarda más tiempo es que el código del producto no fue escrito originalmente por el equipo. El equipo obtuvo el código debido a la gestión del proveedor por parte del cliente. Inicialmente fue trabajado por otra empresa y ahora somos nosotros los encargados de trabajar en ello. Sí, tuvimos una transición de conocimiento inicial, pero puede esperar la brecha en la comprensión de la funcionalidad y la implementación del código. Entonces, esto nos está causando retrasos en la corrección de errores.
@ramu: Si la falta de familiaridad con (secciones de) el código es un problema, entonces debe tenerlo en cuenta en sus estimaciones.
¿Cómo tratamos los errores en el entorno Scrum?
RespuestasAquíPolítica de privacidad1y, 0v