¿Las mejores formas de incorporar la corrección de errores en un proceso Scrum? [cerrado]

He estado estudiando y leyendo sobre Scrum en los últimos días y leyendo sobre Sprint Planning y tareas. Un problema que me vino a la mente es cómo lidiar con los errores en Scrum. Henrik Kniberg enumera algunas formas de lidiar con este problema en su excelente libro Scrum and XP from the Trenches :

1. El propietario del producto imprime los elementos de Jira de mayor prioridad, los lleva a la reunión de planificación del sprint y los coloca en la pared junto con las otras historias (especificando así implícitamente la prioridad de estos elementos en comparación con las otras historias).
2. El propietario del producto crea historias que se refieren a artículos de Jira. Por ejemplo, “Solucione los errores de informes de back office más críticos, Jira-124, Jira-126 y Jira-180”.
3. Se considera que la corrección de errores está fuera del sprint, es decir, el equipo mantiene un factor de enfoque lo suficientemente bajo (por ejemplo, 50%) para asegurarse de tener tiempo para corregir errores. Entonces simplemente se asume que el equipo pasará una cierta cantidad de tiempo en cada sprint arreglando los errores informados por Jira
4. Coloca la acumulación de productos en Jira (es decir, deshazte de Excel). Trate a los insectos como cualquier otra historia.

¿Es esto realmente algo que debe decidirse por proyecto o hay mejores soluciones? Puedo pensar en problemas con cada uno de esos enfoques. ¿Existe un híbrido proveniente de esos enfoques que funcione mejor? ¿Cómo maneja esto en sus proyectos?

Esta es una muy buena pregunta y tengo algunas observaciones cuando se trata de diferentes enfoques a este problema.

1. Tratar todos los errores por igual con los elementos del backlog puede parecer una buena idea en teoría (seguimiento del trabajo en un solo lugar) pero no funciona bien en la práctica. Los errores suelen ser de bajo nivel y más numerosos, por lo que si crea una historia de usuario individual para cada error, las historias "reales" se oscurecerán pronto.
2. El tiempo explícito en cada sprint reservado para arreglos está bien si se hace de una manera que sea visible para el propietario del producto. Los errores deben mencionarse durante el scrum diario y la discusión sobre los errores corregidos debe ocurrir durante la revisión del sprint. De lo contrario, el propietario del producto no se dará cuenta de lo que sucede en el proyecto.
3. Poner todo el trabajo pendiente en la herramienta de seguimiento de errores conduce al mismo conjunto de problemas que en 1. Además, la mayoría de los rastreadores de errores no están diseñados con Scrum en mente y usarlos para este propósito puede ser doloroso.

La solución que encontramos más satisfactoria fue poner una historia de usuario única llamada "Tickets" o "Bugs" en cada sprint. Luego, dicha historia se puede dividir en tareas de bajo nivel que describen un error en particular (si se conoce durante la planificación) o metatareas que reservan un número determinado de horas para la corrección de errores generales. De esta manera, el propietario del producto tiene visibilidad del proceso y el gráfico de evolución refleja el progreso.

Solo recuerde cerrar sin piedad todos los "errores" que en realidad son funciones nuevas y crear nuevos elementos de la lista de trabajos pendientes para ellos. También asegúrese de corregir todos los errores reportados en el sprint actual antes de que termine el sprint para considerar el sprint como hecho.

En realidad, creo que lo mejor es la respuesta de jpeacock a esta pregunta . ¿Cuenta las horas dedicadas a la corrección de errores para el scrum?

Déjame citarlo:

• Si el error es fácil / rápido de solucionar (una línea, etc.), simplemente corríjalo.
• Si el error no es trivial y no es un bloqueador, agréguelo al trabajo pendiente.
• Si el error es un bloqueador, agregue una tarea (al sprint actual) para capturar el trabajo necesario para solucionarlo y comience a trabajar en él. Esto requiere que se mueva algo más (del sprint actual) al backlog para tener en cuenta las nuevas horas porque el total de horas disponibles no ha cambiado.

El primer paso es definir qué es un error. Enseño que un error es solo un error si se trata de una funcionalidad que no funciona en producción como estaba previsto / diseñado. Estos se convierten en PBI de tipo error para priorizarlos frente a nuevos desarrollos. La falta de funcionalidad en producción es una característica y se convierte en un elemento normal de la cartera de productos. Cualquier código defectuoso encontrado durante un sprint se considera trabajo incompleto y dado que no se pasa a la siguiente historia hasta que la actual está lista; No es necesario realizar un seguimiento de estos defectos en el sprint, ya que el equipo siempre está trabajando en el código infractor. Los post-it pueden ser muy útiles aquí para recordatorios rápidos entre compañeros de equipo. La corrección de código roto siempre tiene prioridad sobre la escritura de código nuevo.

El inventario es un desperdicio. El seguimiento de errores es inventario. El seguimiento de errores es un desperdicio.

Tratar todos los errores por igual con los elementos del backlog puede parecer una buena idea en teoría (seguimiento del trabajo en un solo lugar) pero no funciona bien en la práctica. Los errores suelen ser de bajo nivel y más numerosos, por lo que si crea una historia de usuario individual para cada error, las historias "reales" se oscurecerán pronto.

Si tiene muchos más errores que funciones, entonces necesita trabajar en sus prácticas de ingeniería. Este es un olor a que algo más está mal y el seguimiento no es la respuesta. Excavar más hondo. En realidad, los insectos siempre huelen mal. No son geniales y si tiene muchos de ellos, necesita encontrar la (s) causa (s) raíz, eliminarlas y dejar de concentrarse en rastrear errores.

No rastree los defectos en una lista, encuéntrelos y corríjalos - Mary Poppendieck

De hecho, si el inventario es un desperdicio, ¿qué pasa con un inventario de defectos ...

Es por eso que siempre trato de implementar una mentalidad Stop-the-Line con desarrollo basado en pruebas e integración continua, para que encontremos y corrijamos la mayoría de los defectos en lugar de ponerlos en una lista de reelaboración.

Y cuando los defectos pasan, los arreglamos antes de escribir un nuevo código (las historias con errores no se hacen de todos modos). Luego, intentamos arreglar nuestro proceso para hacerlo más a prueba de errores y detectar defectos en el momento en que ocurren.

No existe una solución única para todos y cada proyecto es diferente. Los errores también se pueden clasificar desde críticos para la misión hasta que apenas vale la pena corregirlos.

A menos que sea fundamental para el funcionamiento del sistema, prefiero que los errores se conviertan en tarjetas de historia. Eso hace que la prioridad del desarrollo de funciones frente a la corrección de errores sea realmente explícita. En un escenario en el que se considera que las correcciones de errores están "fuera del sprint", la corrección de errores podría avanzar hacia la corrección de errores realmente triviales mientras que las características comerciales realmente importantes no se están desarrollando.

Hemos pasado por una serie de permutaciones antes de establecer el error como enfoque de historia. Pruebe algunas cosas diferentes y repítalas en las reuniones retro del equipo.

En nuestro caso (desarrollo greenfield, 2-3 desarrolladores), los errores encontrados se anotan, se marcan claramente como un error y, según su gravedad, se asignan a la siguiente iteración o se dejan en el backlog. En caso de errores críticos y urgentes, se agregan a la iteración en curso.

No sé por qué algo tan simple como corregir errores es complicado con reglas. Scrum tiene muy pocas reglas, ¿recuerdas? Cada característica, Soporte, Recomendación o Defecto es un problema de Backlog en Scrum, no hay diferenciación. Entonces, como dice la guía de Scrum: las tareas en un Sprint nunca se limitan a lo que usted decide durante la reunión de planificación, el Daily Scrum ayuda a las personas a discutir los "impedimentos" en su camino.

¿Por qué?

Así que discuten y piensen racionalmente como equipo si quieren que el defecto, es decir, el problema de la acumulación, vaya a PBI o permanezca en este Sprint y lo entregue ...

Una mejor pregunta es ¿cómo dejo de crear errores en la fase de desarrollo? ver -> http://bit.ly/UoTa4n

Si está identificando y documentando errores, tendrá que clasificarlos y corregirlos en el futuro. Esto conduce a "sprints de estabilización", es decir, un sprint completo solo para corregir errores. O puede agregarlos nuevamente a la lista de trabajos pendientes y priorizarlos como parte de algún sprint futuro. También significa que proporcionará y esperará que se apruebe y se publique software con errores conocidos (P3 y P4, también conocidos como cosméticos y menores).

¿Esto no es realmente ágil?

He presentado la idea en nuestro proyecto de introducir un breve sprint de corrección de errores cada tercer sprint. Nuestros sprints actuales son de tres semanas.

La idea es que permitirá a todos los desarrolladores concentrarse en la corrección de errores juntos, permitir que se enfoquen solo en historias nuevas en sprints regulares y se mantenga un enfoque regular en reducir la deuda tecnológica.

Las correcciones de errores se agruparán en historias relevantes y se priorizarán. El énfasis no está en el dimensionamiento antes del sprint, ya que los desarrolladores luchan por dimensionar las correcciones de errores sin atascarse para comprender la naturaleza del defecto.

¿Alguien ha probado esto o tiene algún comentario sobre cómo creen que podría funcionar?

Saludos, Kevin.