debugging - fases - sprint backlog

¿Mejores formas de ajustar la corrección de errores en un proceso de Scrum? (9)

No rastrear defectos en una lista, encontrarlos y solucionarlos - 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 de detener la línea con un desarrollo basado en pruebas y una integración continua, para que podamos encontrar y corregir la mayoría de los defectos en lugar de ponerlos en una lista de reprocesamiento.

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

He estado estudiando y leyendo acerca de Scrum en los últimos días y leyendo sobre planificación y tareas de Sprint. 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 muy agradable libro Scrum y XP de las trincheras :

El propietario del producto imprime los ítems Jira de mayor prioridad, los lleva a la reunión de planificación del sprint y los pone en la pared junto con las otras historias (especificando así implícitamente la prioridad de estos artículos en comparación con las otras historias).
El propietario del producto crea historias que hacen referencia a los artículos de Jira. Por ejemplo, "Soluciona los errores más importantes en la elaboración de informes administrativos, Jira-124, Jira-126 y Jira-180".
La solución de errores se considera fuera del sprint, es decir, el equipo mantiene un factor de enfoque suficientemente bajo (por ejemplo, 50%) para garantizar que tengan tiempo para corregir errores. Entonces simplemente se supone que el equipo pasará una cierta cantidad de tiempo en cada sprint arreglando errores de Jira.
Coloque la cartera de pedidos del producto en Jira (es decir, zócalo de Excel). Trate los errores 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. ¿Hay un híbrido proveniente de esos enfoques que funciona mejor? ¿Cómo manejas esto en tus proyectos?

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 la producción tal como fue diseñada / diseñada. Estos se convierten en PBI de tipo de error para ser priorizados contra un nuevo desarrollo. La funcionalidad faltante en la producción es una característica y se convierte en un elemento de acumulación de productos normal. Cualquier código defectuoso que se encuentre durante un sprint se considera trabajo incompleto y ya que no pasará a la siguiente historia hasta que la actual esté terminada; no es necesario rastrear estos defectos en el sprint ya que el equipo siempre está trabajando en el código ofensivo. Post-its puede ser muy útil aquí para recordatorios rápidos entre compañeros de equipo. Reparar el código dañado siempre tiene precedencia sobre la escritura de un nuevo código. Si los defectos se deben a un malentendido de la historia, entonces debes trabajar en tus condiciones de aceptación antes de comenzar la historia.

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

Tratar todos los errores de la misma manera con los elementos atrasados puede parecer una buena idea en teoría (trabajo rastreado 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 características, entonces necesita trabajar en sus prácticas de ingeniería. Este es un olor que algo más está mal y el seguimiento no es la respuesta. Excavar más hondo. En realidad, los errores siempre son malolientes. No son geniales y si tiene muchos de ellos, necesita encontrar las causas raíz, eliminarlos y dejar de centrarse en el seguimiento de errores.

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

En realidad, creo que lo mejor es responder por jpeacock partir de esta pregunta . ¿Se cuentan las horas invertidas en correcciones de errores para el scrum?

Déjame citarlo:

Si el error es fácil / rápido de solucionar (un trazador de líneas, etc.), entonces simplemente corrígelo.
Si el error no es trivial, y no es un bloqueador, agréguelo a la lista de espera.
Si el error es un bloqueador, agregue una tarea (al sprint actual) para capturar el trabajo requerido para repararlo y empiece a trabajar en él. Esto requiere que se mueva algo más (desde el sprint actual) a la acumulación para tener en cuenta las nuevas horas porque el total de horas disponibles no ha cambiado.

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

Tratar todos los errores de la misma manera con los elementos atrasados puede parecer una buena idea en teoría (trabajo rastreado 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.
El tiempo explícito en cada sprint reservado para las correcciones está bien si está hecho de una manera que sea visible para el dueño del producto. Los errores se deben mencionar 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 sabrá qué está sucediendo en el proyecto.
Poner todo el trabajo acumulado en la herramienta de seguimiento de errores lleva a la misma serie 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 sola historia de usuario 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 meta-tareas reservando un número determinado de horas para la corrección general de errores. De esta forma, el propietario del producto tiene visibilidad del proceso y el gráfico de burndown refleja el progreso.

Solo recuerde cerrar sin piedad todos los "errores" que en realidad son nuevas características y crear nuevos elementos atrasados para ellos. También asegúrese de corregir todos los errores reportados contra el sprint actual antes de que termine el sprint para considerar el sprint como hecho.

He presentado la idea en nuestro proyecto para presentar un breve sprint fix sprint cada tercer sprint. Nuestros sprints actuales son de tres semanas.

La idea es que permitirá que todos los desarrolladores se centren en la solución de errores, permitan centrarse solo en nuevas historias en los sprints regulares y se concentren regularmente 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 se esfuerzan por dimensionar las correcciones de errores sin atascarse para comprender la naturaleza del defecto.

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

Saludos, Kevin.

Mejor pregunta es ¿cómo puedo dejar 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 algún momento futuro. Esto conduce a "sprints de estabilización", es decir, un sprint completo solo para corregir errores. O puede volver a agregarlos a la acumulación y priorizarlos como parte de un sprint futuro. También significa que proporcionará y espera obtener software firmado y lanzado con errores conocidos en él (P3 y P4, también conocido como cosmético y de menor importancia).

Esto no es realmente ágil?

No existe una solución única para todos y cada proyecto es diferente. Los errores también se pueden categorizar de misión crítica a poco vale la pena corregir.

A menos que sea crítico para el funcionamiento del sistema, prefiero que los errores se conviertan en tarjetas de historia. Eso hace que la prioridad del desarrollo de características frente a la solución de errores sea realmente explícita. En un escenario en el que las correcciones de errores se consideran "fuera del sprint", la corrección de errores podría avanzar hacia la solució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 un enfoque de historia. Pruebe algunas cosas diferentes y repítalas en las reuniones de equipos retro.

No sé por qué algo tan simple como arreglar errores se complica con las 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 decida durante la reunión de planificación, el Daily Scrum ayuda a las personas a discutir "impedimentos" en su camino.

¿Por qué?

Entonces, discutan y piensen racionalmente como un equipo si quieren que el defecto, es decir, el problema del retraso acumulado, entre en PBI o permanezcan en este Sprint y lo entreguen ...