Definición de epopeyas
Lukas es propietario de un restaurante que recientemente contrató a una empresa de software para crear un sitio web para su restaurante. La empresa de software utiliza Scrum y, en nuestro escenario, le asigna el rol de Product Owner. Este es un papel importante, especialmente en lo que respecta a los requisitos del proyecto. Lukas cree que comprende las historias de los usuarios y escribe algunas para el equipo. Sin embargo, la respuesta que recibe es que en realidad ha escrito epopeyas, no historias de usuarios. No está familiarizado con este término y busca comprender la diferencia y cómo puede proporcionar lo que se necesita para que el equipo comience a trabajar.
En Scrum, el trabajo del proyecto se divide en porciones más pequeñas, conocidas como historias de usuario . Estos proporcionan detalles de alto nivel sobre la funcionalidad deseada para un usuario específico y están escritos por el propietario del producto, quien es responsable del proyecto y representa a la parte interesada clave. Se completan en ciclos repetidos, conocidos como sprints . Las historias de usuario de calidad cumplen los criterios del acrónimo INVEST , originado por Bill Wake, al ser:
- Independiente (de otras historias de usuarios)
- Negociable (flexible y se puede ajustar si es necesario)
- Valioso (satisfaciendo una necesidad)
- Estimable (en términos de tiempo / complejidad)
- Pequeño (para completar dentro de un sprint)
- Comprobable (se puede verificar si se cumplen los criterios)
Cuando un Product Owner escribe historias de usuario, se evalúan según estos criterios. Si se encuentran con cada uno, se confirman como historias de usuario. Si no cumplen con los criterios, no se consideran historias de usuario. En particular, si no cumplen con los criterios estimables y / o pequeños, se consideran épicos. Las épicas son historias de usuarios que son demasiado grandes o demasiado complejas y deben desglosarse más. Este es el problema de Lukas y lo que ha proporcionado como historias de usuarios. Sin embargo, a medida que busca hacer ajustes, necesita que el equipo lo ayude a comprender mejor por qué las historias de usuarios se identifican como épicas y para ver un ejemplo.
Identificando épicos
Una vez que Lukas tiene una idea de lo que significa una epopeya, discute con el equipo cómo identifican si un elemento de trabajo es una epopeya o una historia de usuario. Si puede comprender estos factores, puede proporcionarles historias de usuarios en lugar de épicas en el futuro. Los factores involucrados en la identificación de epopeyas son el tamaño, la complejidad y la capacidad de estimación del equipo.
Uno de los principales factores para identificar epopeyas es el tamaño de un elemento de trabajo. Las historias de usuario deben ser lo suficientemente pequeñas para completarse en un sprint. La finalización implica desarrollo y pruebas. Si la combinación de estos tarda más que la duración de un sprint en completarse, los elementos de trabajo no son una historia de usuario, sino una epopeya. En algunos casos, un elemento de trabajo podría completarse dentro de un sprint, pero tomaría la mayor parte del sprint. El equipo de desarrollo podría decidir identificarlo como una epopeya.
¿Qué es un equipo Scrum? – Definición y estructura
Otro factor para identificar las epopeyas es la complejidad. Cuando el equipo de desarrollo revisa las historias de los usuarios, le asignan una estimación puntual de la historia , que es un valor que representa el tiempo y el esfuerzo necesarios para completarla. Si el equipo no puede asignar un presupuesto a un elemento de trabajo porque es demasiado complejo, es una historia épica, no de usuario. Además, las historias de usuario deben presentarse de la forma más sencilla posible. Si se pueden desglosar aún más en aspectos más específicos de la funcionalidad, o más historias de usuarios, son épicos.
El último factor para identificar épicas es la capacidad de estimación del equipo. Este factor es más subjetivo que los demás porque se basa en el equipo. El equipo debe completar las historias de usuario que asume dentro de un sprint. Si el equipo no completa las historias de usuario durante un sprint y constantemente tienen un nivel de punto de historia o superior, el equipo podría considerar ese nivel y superior como épicos. Por ejemplo, si un equipo no pudiera completar constantemente historias de usuarios estimadas en 8 o más, considerarían historias de usuarios estimadas en 8 o más como épicas.
Ejemplo de epopeyas
Después de que Lukas comprenda completamente las epopeyas, quiere revisar un ejemplo de lo que proporcionó al equipo para ver cómo se puede dividir de una epopeya en historias de usuarios para que el equipo pueda comenzar a trabajar. Una de las epopeyas que escribió Lukas fue la posibilidad de pedir comida en línea. Comenzó aquí porque vio esto como el propósito principal de su sitio web. Específicamente, escribió: «Como cliente, quiero pedir una comida para llevar en línea». El equipo vio esto como una epopeya basada tanto en el tamaño como en la complejidad.
Desde la perspectiva del equipo, la creación de funciones para pedir una comida para llevar en línea no se podía desarrollar ni probar por completo en un solo sprint. Esta funcionalidad es uno de los principales objetivos del proyecto. No sería realista completar la mayor parte del proyecto en un solo sprint. Esta funcionalidad debe desglosarse aún más para que pueda desarrollarse y probarse de manera incremental.
De la mano de la cuestión del tamaño, la funcionalidad de pedir una comida para llevar en línea es demasiado compleja. Hay varios aspectos de la funcionalidad de nivel inferior que son necesarios para lograr esta funcionalidad de alto nivel. Por ejemplo, un cliente debe poder ver el menú en línea, seleccionar los artículos para pedir y enviar el pedido. Además, el pedido debe recibirse en el restaurante de alguna manera. Cada uno de estos elementos podría ser una historia de usuario.
¿Qué es la gestión ágil de proyectos? – Scrum y metodología
Además, hay muchas preguntas que responder sobre esta funcionalidad. ¿Puede el cliente pagar en línea? Si es así, esta es otra historia de usuario. ¿Se pueden personalizar los elementos del menú de alguna manera? Si es así, esta es otra historia de usuario. La epopeya de Lukas es útil para generar esta conversación y guiar el proyecto, pero el trabajo solo se puede hacer si los requisitos están en forma de historia de usuario.
Resumen de la lección
La forma ideal de requisitos del proyecto en Scrum son las historias de usuario escritas por el Product Owner . Si cumplen con los criterios INVEST , se desarrollan y prueban completamente en un sprint . De lo contrario, podrían clasificarse como épicos y deberían desglosarse más. Los elementos de trabajo se identifican principalmente como épicos en lugar de historias de usuario si son demasiado grandes para completar dentro de un sprint o demasiado complejos para asignar una estimación de puntos de la historia . Además, si el equipo es inexacto por encima de una determinada estimación puntual de la historia, es posible que establezcan el valor como un umbral para las epopeyas en lugar de las historias de usuarios, incluso si los otros factores no se aplican.
Explora más sobre este tema
Selecciona un tema y sigue aprendiendo...
