Seguimiento de errores (bug tracking) – iceScrum

Documentación Esta documentación se aplica solo a iceScrum v7.
Para el antiguo iceScrum R6, lea la documentación o migrate.

Incorpore el seguimiento de errores en su flujo de trabajo ágil

Gestión de defectos

Defectos como historias

En la gestión de proyectos tradicional, los errores a menudo se separan de los requisitos o incluso se gestionan en herramientas dedicadas denominadas «bug trackers». En metodologías ágiles, si mantiene pilas de historias de usuarios y errores separadas, el propietario del producto no puede materializar claramente su visión, los desarrolladores no saben qué implementar a continuación y los stakeholders no saben qué esperar a continuación. Para que sea efectivo, debe haber una y solo una pila de productos ordenada sin ambigüedad.

Por esta razón, los errores se manejan como historias en iceScrum y reciben muy poco tratamiento especial. Si además lo piensa, las historias de usuario y los errores en realidad no son tan diferentes: ambos expresan un comportamiento deseado que el producto no ofrece actualmente.

Historias de defectos

Solo dos campos diferencian historias de defectos e historias de usuarios:

  • El tipo historia de defecto, lo que deja en claro que la historia es un defecto a solucionar. Un icono de «bicho» se muestra en el post-it.
  • El campo versión afectada, que apunta a la versión del producto afectada por el error (por ejemplo, una versión asociada a un sprint anterior).

Crear una historia de defecto efectiva es tan simple como llenar estos campos en combinación con campos de historias regulares, por ejemplo una descripción adecuada, capturas de pantalla adjuntas para demostrar el problema y una dependencia de la historia hecha con la que se relaciona.

Las historias de defectos siguen el flujo de trabajo de historia normal.

Apps y funciones relacionadas

La App de plantilla de historia permite rellenar previamente las historias al crearlas. Por lo tanto, puede definir una plantilla «Bug» con una lista de tareas predeterminada, p. «Reproducir el error», «Escribir una prueba de unidad», «Resolver el error» …

Si sus partes interesadas (stakeholders) están acostumbradas a usar una herramienta separada, puede importar problemas como historias automáticamente gracias a los Apps Bug tracker.

La Apps de pilas personalizadas permite crear vistas de historias filtradas, p. una pila que muestra nuevos errores (las historias de tipo «Historia de defectos» y el estado «Sugerido»).

Finalmente, algunas métricas como los gráficos Burndown Chart y de Pilas del proyecto permiten realizar un seguimiento de la evolución de las tasas de defectos, que por supuesto desea mantener bajos.


Pruébalo gratis ahora
Todo lo que necesita para gestionar sus proyectos ágiles