Desglosando una historia compleja al inicio del proyecto

Estoy tratando de familiarizarme con la gestión ágil de proyectos (con Pivotal Tracker) pero sigo encontrándome con paredes cuando trato de definir las primeras historias de un proyecto. Tome por ejemplo esta historia muy simple:

"Un usuario debe poder etiquetar un producto"

Suponiendo que ya he definido "producto" en otra parte, esta historia posiblemente implicaría escribir un sistema de etiquetado polimórfico debajo del capó, al completar la identificación de ese sistema, finalmente se puede agregar la capacidad de etiquetar un producto.

Mi problema es con la cantidad de trabajo oculto en esta historia. ¿Puedo definir tareas para completar la historia, pero se supone que las historias en su conjunto son de 1-2 días de trabajo? No me siento bien con la historia que solo revela la punta del iceberg, pero esa es la única parte que se relaciona con el Usuario.

¿Cómo superas este tipo de cosas? ¿Cuáles son las mejores prácticas?

ACTUALIZACIÓN 25/08 Gracias a todos por su orientación, he tenido en cuenta todos los consejos sobre cómo definir historias. Ahora me estoy cambiando a Jira Grasshopper, que tiene un mejor soporte para las tareas dentro de las historias (asignación, estimaciones, etc.) y seguimiento de las tareas de desarrollo una vez que ha comenzado el sprint.

Si necesita que sus historias sean de 1 a 2 días de trabajo de desarrollador cada una, tal vez debería dividir cada historia en tareas de usuario específicas que son de 1 a 2 días de trabajo de desarrollador.

Considere la siguiente "historia de usuario":

Un usuario debe poder recibir una factura de un producto comprado.

Piense en lo que implica el diseño de la base de datos, para brindarle al usuario esta capacidad. Necesita una tabla de clientes, una tabla de encabezado de factura y una tabla de líneas de pedido de factura, y aún no hemos hablado de aceptar pagos.

En realidad, las historias de usuarios no son tan simples. Las historias de usuario completas incluyen un tutorial de los pasos del usuario involucrados:

• El usuario pone el producto en el carrito
• El usuario especifica la cantidad
• El usuario especifica el tipo de envío

y así. En resumen, debe desglosar sus historias de usuario en detalles más finos.

Se supone que las historias no son "1-2 días de trabajo". En Scrum, las historias se estiman normalmente utilizando Story Points, un sistema de tamaño relativo. Si usa la planificación, las historias de póker reciben un valor de puntos: el tiempo que lleva la historia para implementar depende de la velocidad que haya establecido su equipo.

Si cree que la historia está ocultando complejidad (podría llamarla una historia épica ), debe dividirla en historias más pequeñas. Asegúrese de que las nuevas historias sigan los criterios de INVEST .

Pero puede estar diseñando esto en exceso; El principio XP de YAGNI se aplica aquí. Para ser explícito, no debe implementar un "sistema de etiquetado polimórfico debajo del capó", a menos que realmente lo necesite. Incluso entonces, debe diseñarse mejorando el sistema existente, que ha desarrollado con un buen conjunto de pruebas.

Si está seguro de que necesita este complejo sistema de etiquetado, debe mencionar la complejidad en historias separadas. Mike Cohn describe el enfoque del diseño como " intencional, pero emergente "

Parece que estás confundiendo historias y tareas.

Historia del usuario

Una historia de usuario es una "característica" completa, algo que cuando se agrega al producto, proporciona más valor al producto.

Una historia de usuario no debe ser más grande de lo que se puede implementar durante un sprint . Durante la primera parte de la planificación del sprint, usted decide en qué historias de usuario desea trabajar durante el sprint. El objetivo del sprint es completar estas historias de usuarios, agregando así más valor al producto.

Tarea

Durante la segunda parte de la fase de planificación del sprint, los desarrolladores dividen la historia en tareas . Las tareas son tareas de desarrollo. Podrían ser cosas como "Agregar columna a la base de datos", "Extender servicio x", etc. Una tarea no debe ser más grande de lo que se puede completar en un día.

Durante el scrum diario evalúa el progreso de estas tareas. Si una tarea ha estado en progreso durante más de un scrum diario, está tardando demasiado y usted, como equipo, tiene la responsabilidad de resolver esa situación.

Recuerde, las historias de los usuarios representan un valor comercial para los interesados. Los interesados ​​deberían estar interesados ​​en completar las historias de los usuarios, no las tareas.

La división de tareas es una herramienta para que el equipo de desarrollo administre el sprint, monitoree el progreso de las historias de los usuarios durante un sprint y visualice posibles problemas.

Los interesados ​​no deben preocuparse por estas tareas de desarrollo. Desafortunadamente, según mi experiencia, a menudo lo hacen, particularmente para organizaciones nuevas en el desarrollo ágil. Sin embargo, lidiar con esta situación es un asunto diferente.

Épico

Si una historia de usuario es más grande de lo que crees que puedes completar en un sprint, se llama épica. Debe dividirse en varias historias de usuarios más pequeñas antes de que usted, como equipo, pueda comenzar a trabajar en ello.

Recuerde que una historia de usuario agrega valor al usuario final, por lo que dividir una historia épica en una historia de "front-end" y una de "back-end" no es la forma correcta. Agregar el back-end para una nueva característica no proporciona en sí mismo valor a los usuarios finales.

Dividir una historia épica en historias de usuario manejables dentro del marco de tiempo de un sprint no siempre es fácil cuando no tienes experiencia en hacerlo.

Usando Pivotal Tracker

Creo que Pivotal Tracker es una gran herramienta para rastrear historias de usuarios. Pero no es una herramienta de scrum como tal, y la forma en que el scrum enseña a dividir historias en tareas no se maneja fácilmente con un rastreador fundamental. Puede habilitar la capacidad de agregar tareas a las historias de los usuarios. Pero si está ejecutando un proyecto usando scrum, sugeriría usar una pizarra blanca y notas adhesivas para rastrear el progreso de las tareas durante un sprint.

Tener un objetivo de diseño de implementar un sistema de etiquetado polimórfico está bien, pero aún debe concentrarse en implementar las características que el cliente desea. Esto podría significar que, la historia de usuario de grano fino por la historia de usuario de grano fino, su sistema evoluciona para tener un sistema de etiquetado polimórfico con el tiempo. Sin embargo, en cualquier momento de ese viaje, debe tener un sistema compuesto por muchas características pequeñas y comprobables, descritas por una colección de Historias de usuarios que ha implementado.

En este caso, parece que "Etiquetar productos" en su sistema podría ser una epopeya, es decir, algo que es mucho más grande que una sola historia de usuario y puede dividirse en varias historias más pequeñas con un poco de esfuerzo. Tomando una buena cantidad de licencia artística, puedo pensar en las siguientes Historias de usuarios que podrían ser más o menos aplicables a sus requisitos:

• Como administrador del sistema, quiero sembrar el sistema con algunas etiquetas válidas para que los usuarios tengan algunos valores para elegir la primera vez que utilicen la función de etiquetado.
• Como usuario del sistema, quiero poder buscar un producto por su nombre para poder etiquetarlo más tarde.
• Como usuario del sistema, quiero poder leer la descripción de un producto para poder decidir qué etiquetas debería tener.
• Como usuario del sistema, quiero poder ver una imagen del producto para poder decidir qué etiquetas debería tener.
• Como usuario del sistema, quiero poder adjuntar una sola etiqueta a un solo producto.
• Como usuario del sistema, quiero poder eliminar una sola etiqueta de un solo producto.
• Como usuario del sistema, quiero poder adjuntar una sola etiqueta a varios productos.
• Como usuario del sistema, quiero poder adjuntar múltiples etiquetas a un solo producto.
• Como administrador del sistema, quiero ver una lista distinta de las etiquetas en uso en el sistema para poder decidir si alguna de ellas es duplicada.
• Como administrador del sistema, quiero consolidar las etiquetas duplicadas.

... y podría seguir.

Dudo que alguno de estos sea tan realista que los use, pero espero que ilustren el tipo de detalle al que puede acceder con sus Historias de usuarios.

Si una historia de usuario realmente no se puede subdividir en historias más pequeñas y aún la considera demasiado grande para intentar implementarla de una vez, puede dividirla en segmentos verticales. Esta es una técnica que significa entregar solo una parte de la función en cada Historia de usuario, pero cada parte es una porción comprobable de todas las capas relevantes de la tecnología, por ejemplo, para un sitio web, esto podría significar cambiar las capas de la base de datos, la aplicación y la interfaz de usuario. Evite tener una historia de usuario para el trabajo de la base de datos, otra para la aplicación y otra para la interfaz de usuario, ya que estas no serán verificables individualmente.

Tomando aún más licencia artística, podría dividir "Como usuario del sistema quiero poder adjuntar una sola etiqueta a un solo producto". en los siguientes cortes verticales:

• Como usuario del sistema que mira un solo producto, quiero poder buscar una lista de etiquetas para poder decidir cuál aplicar.
• Como usuario del sistema que mira un solo producto, después de haber decidido aplicar una etiqueta a ese producto, quiero poder aplicarlo.
• Como usuario del sistema que mira un solo producto, después de haber aplicado una etiqueta a ese producto, quiero un mensaje de confirmación en la pantalla que me indique que se ha guardado correctamente.

Cada uno de ellos es comprobable, si no particularmente valioso por derecho propio.

Hay libros escritos con el único propósito de descubrir la forma correcta de describir y desglosar sus requisitos. Por lo tanto, no es una tarea fácil.

Muchas veces encuentro equipos de desarrollo que buscan soluciones complejas en lugar de las más simples. Esto podría deberse a la historia en sí o porque el equipo quiere buscar una solución demasiado compleja que no solo resuelva esta historia sino que también establezca las bases para las historias x, y y z. Esta es una buena intención, pero aumenta el alcance donde se puede hacer el mismo trabajo con menos trabajo. Siempre es difícil juzgar cuánto diseño tiene que ir a una historia para no arruinar historias futuras arruinando el diseño. Esta decisión es para que la tome el equipo.

Como propietario de un producto, solo puede influir en esto dividiendo las historias en piezas más pequeñas. Debería preguntarse: ¿Es la historia la solución más pequeña que se nos ocurre en este momento? ¿Podemos dividirlo en conjuntos de características reducidas que algún día se convertirán en el "gran sistema de etiquetado flexible que siempre he querido"? Puede comenzar con un sistema de etiquetas para una sola etiqueta, luego extenderlo para incluir una lista de etiquetas preseleccionadas y luego dejar que el usuario defina etiquetas, etc.

Para el equipo de desarrollo se reduce a: ¿Podemos encontrar un enfoque más simple para darnos cuenta de la historia, pero aún así tener una arquitectura sólida que cumpla con el trabajo hoy sin comprometer las características futuras?

Si está abierto a aceptar soluciones intermedias y el equipo de desarrollo también trata de ofrecer la solución más simple pero buena, entonces probablemente encontrará el punto ideal en el que el tamaño de las historias que desea hacer es correcto (cuanto más pequeño, mejor) . Esto no quiere decir que solo tienes pequeñas historias. Algunos son más grandes que otros, esto es solo un hecho que debes aceptar, o si son demasiado grandes, divide las historias en pedazos más pequeños.