como-dividir-historias-de-usuario-en-tareas

Cómo dividir historias de usuario en tareas


Las historias de usuario son los elementos en los que dividimos todo el trabajo que hay que hacer en un proyecto o producto en Scrum. Esencialmente contienen el qué hay que construir. En la planificación el equipo Scrum elige cuales de las historias de usuario más importantes va a desarrollar en las semanas que dure el sprint. Además de decidir hasta dónde puede llegar, el equipo debe salir con un plan detallado. Será el cómo lo va a lograr. Para ello normalmente lo que hace el equipo es dividir historias de usuario en tareas.

Dividir historias de usuario en tareas

Gran parte del éxito del Sprint dependerá de la atención y dedicación que se le dé a este proceso. Sin embargo, el paso de dividir las historias de usuario en tareas es complicado para muchos equipos. Requiere experiencia, conocimiento y decisión.

dividir historias de usuario en tareas

Desgraciadamente no hay un procedimiento mágico infalible para dividir historias de usuario en tareas. Dependerá de muchos factores: cómo de grandes son estas historias de usuario, cómo de complejo es el proyecto o producto, experiencia del equipo Scrum, si el producto es interno o externo, etc. Tampoco hay una manera (o yo por lo menos no la conozco ni me la imagino) de enseñar a partir tareas. Es como una habilidad blanda. Se trata de habernos peleado con ello mil veces, y a base de golpes, aprendes a detectar tareas ocultas, identificar riesgos técnicos, anticipar problemas, y hacer las preguntas pertinentes para crear un buen plan.

Las tareas deberían ser pequeñas (entre medio día y 2 días como mucho). Así facilitaremos el seguimiento y la estimación por parte del equipo. En la medida de lo posible, las tareas además deberían poder probarse de forma individual. Esto es, no deben depender de que otra tarea esté terminada para poder probarse.

Primer análisis técnico

El proceso de partir en tareas comienza normalmente con un primer análisis y diseño técnico. Ayuda en este caso dibujar los diferentes componentes software (interfaces de usuario, piezas de lógica de negocio, servicios, orígenes y destinos de datos, etc.) y sus relaciones (cómo interactúan entre ellos). No hace falta que sea un diagrama de clases, estaría más cerca de un diagrama de flujo de datos. Un ejemplo podría ser éste:

Con el diagrama delante será muy sencillo identificar todas las tareas necesarias para crear los componentes que falten o modificar los existentes y así obtener una nueva funcionalidad.

Este diagrama además será de gran ayuda para detectar las posibles dependencias. Por ejemplo, en el caso de que algún componente de los identificados deba desarrollarlo otro equipo. También es de gran ayuda para los desarrolladores a la hora de repartirse el trabajo. Si están claros los límites, cada componente lo podría desarrollar una persona distinta.

Tareas adicionales

Pero no todas las tareas necesarias para terminar una historia de usuario son técnicas. Habitualmente hay muchas tareas adicionales. Los equipos suelen olvidan estas tareas sistemáticamente. Para identificar este tipo de tareas ocultas es muy útil que el equipo cuente con un checklist que les sirva de recordatorio. En los equipos cuento normalmente con 2 checklist.

Una de ellas es un acuerdo de trabajo fundamental en Scrum, la definición de hecho o definition of done (DoD). En esta lista están todas las condiciones necesarias que se deben dar para que una historia de usuario se dé por finalizada. Normalmente por cada criterio de la DoD surgirá una tarea.

La otra checklist que utilizo es una checklist genérica, que contiene tareas típicas dentro de todas o casi todas las historias de usuario de todos los equipos. Aunque sea una lista genérica, conviene adaptarla a cada equipo para eliminar lo que no aplica y añadir algún que otro punto que sea específico del equipo. Para que os hagáis una idea, os pondré un ejemplo:

  • Interfaces y métodos necesarios, incluir además los stubs temporales para trabajar entre back y front por ejemplo.
  • Unit testing, de integración, pruebas de aceptación (automáticas o no), pruebas exploratorias, tests de regresión.
  • Requisitos no funcionales: Rendimiento, escalabilidad, mantenibilidad, seguridad…
  • Revisiones de código.
  • Refactors/Rebuilds necesarios + pruebas asociadas necesarias.
  • Corrección de errores.
  • Reparación de incidencias del análisis de código estático.
  • Preparación de la demo (datos de prueba, scripts…).
  • Actualizar la documentación (técnica, javadoc, de usuario…).

Acabando

Así es como yo aconsejo a los equipos cómo deben dividir historias de usuario en tareas durante las sesiones de planificación. Como cada maestrillo tendrá su librillo, existirán mil maneras y herramientas para complementar o hacer diferente esta actividad fundamental en los equipos Scrum. Estaría encantado de que compartieras cómo lo haces tú, así que no te cortes y deja tu comentario.

dividir historias de usuario en tareas

Finalmente te dejo un artículo de Javier Garzás sobre cómo descomponer historias de usuario en tareas para que amplíes información si lo necesitas. Hay partes repetidas pues también yo lo tomé como inspiración, pero no deja de ser interesante como complemento.

También te puede interesar...

Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...
Agile BCN Open Space primavera de 2017 (II) Este pasado sábado se celebró el Barcelona el Open Space de la comunidad Agile BCN. Cerca de 70 personas nos reunimos en las oficinas de Netmind IT co...
Mejores retrospectivas con la Directiva de Kerth Durante la existencia de este blog uno de los temas centrales y que más entradas ha protagonizado ha sido el de las retrospectivas. Recordemos algunas...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *