Épico en ágil

Definición

La empresa de software de Leonard está realizando algunos cambios. Están buscando un enfoque diferente para administrar proyectos, por lo que ha estado ayudando a su equipo a explorar Agile. Uno de los aspectos únicos de Agile es el tratamiento de los requisitos del proyecto. Al igual que las metodologías tradicionales, los requisitos del proyecto en Agile deben definirse antes de asumirlos. Sin embargo, a diferencia de las metodologías tradicionales, el proyecto puede avanzar sin que todos los requisitos del proyecto estén definidos por adelantado. Estos requisitos menos definidos, conocidos como epopeyas, son perfectamente aceptables tal como están hasta que sea necesario asumirlos. Esto permite que los requisitos evolucionen a medida que el equipo aprende más trabajando en el proyecto. Leonard y su equipo se sienten atraídos por la flexibilidad en Agile que se obtiene mediante el uso de épicas.

Historias del usuario

Agile adopta un enfoque incremental e iterativo de los proyectos. Esto implica desglosar los requisitos del proyecto para que sean más pequeños y más manejables, de modo que puedan completarse en períodos de tiempo repetidos más cortos o iteraciones. Para ser asumidos por el equipo de desarrollo, los requisitos del proyecto deben tomar la forma de historias de usuario , que detallan aspectos específicos de la funcionalidad deseada para los usuarios finales. Hay dos aspectos que definen las historias de usuario, incluida la estructura y el tamaño. Las historias de usuario siguen una estructura definida que responde preguntas sobre quién, qué y por qué. Detallan un usuario específico, una funcionalidad deseada y el motivo de la funcionalidad, que es una necesidad o un valor comercial. No solo hay detalles con respecto a la definición de una historia de usuario, sino también a su tamaño. Las historias de usuario deben ser lo suficientemente pequeñas para ser completadas, completamente desarrolladas y probadas, en una sola iteración.

Épicas

Además de las historias de usuario, los requisitos del proyecto también pueden tomar la forma de epopeyas , que son relativamente indefinidas o demasiado grandes para completarlas en una sola iteración. A diferencia de las historias de usuario, que son paralelas a los requisitos de proyecto definidos de las metodologías tradicionales, las epopeyas son únicas. Las metodologías tradicionales no permiten que el proyecto avance hasta que se definan todos los requisitos, por lo que no hay paralelo. Las epopeyas a menudo se consideran historias de usuarios que son demasiado grandes o demasiado complejas. Esto se debe a que, a medida que las epopeyas se desglosan o se definen con mayor detalle, el resultado final debe ser historias de usuario que el equipo pueda completar. Si bien es útil pensar en las epopeyas como una variación de las historias de los usuarios, no siempre son similares. Mientras que las historias de usuarios tienen una estructura específica, las epopeyas no. Por lo general, incluyen algunos elementos de una historia de usuario, como el usuario, la funcionalidad y el motivo, pero pueden o no incluirlos todos. En relación con el proyecto en general, las epopeyas se mantienen en la cartera de pedidos del producto , que es una agrupación priorizada del trabajo del proyecto que aún no ha sido asumido por el equipo. Los elementos en la parte superior de la lista de trabajos pendientes deben estar en estado listo o en forma de historia de usuario. Están organizados con la máxima prioridad en la parte superior, ya que la historia de usuario se tomará a continuación. Los épicos deberían estar más abajo en la lista de trabajos pendientes, ya que no están listos.

Ejemplo

Una vez que Leonard y su equipo comienzan a comprender los requisitos del proyecto en Agile, específicamente los épicos, pasa a un ejemplo tangible. Este es su equipo para hacerse cargo de lo que han aprendido. Recientemente, completaron el trabajo en un sitio web para un departamento de parques y recreación. Usando una metodología tradicional, pasaron una cantidad significativa de tiempo al principio definiendo todos los requisitos del proyecto antes de poder comenzar a trabajar. Él cree que Agile, con la capacidad de usar épicas, habría facilitado el proyecto. Un ejemplo de un Leonard épico y su equipo habrían trabajado con cuentas de usuario involucradas. La epopeya podría haber comenzado de alto nivel y permanecer relativamente indefinida. Al comienzo del proyecto, todo lo que se necesitaba era un marcador de posición porque no era necesario definirlo para comenzar a trabajar en el sitio. Posteriormente, una vez construidas las diferentes áreas, el equipo pudo haber definido usuarios específicos, las áreas a las que tendrían acceso y por qué era necesario. Un ejemplo adicional de una epopeya sería la capacidad de los entrenadores de programar campos de práctica para sus equipos en línea. Este artículo tiene mucha más definición pero es un poco demasiado grande. Si el equipo de Leonard tuviera la capacidad de tratarlo como una epopeya, podría haber sido escrito y luego desglosado mientras el equipo se preparaba para asumirlo. Una historia de usuario podría haberse centrado en mostrar un calendario, mientras que otra podría haberse centrado en la capacidad de guardar una reserva. En general, las epopeyas permiten a los equipos de proyecto trabajar en diferentes aspectos de la funcionalidad sin tener todos los detalles de cada posible requisito definido. Se pueden usar como marcadores de posición para elementos que el equipo no quiere perder de vista y luego volver a visitarlos una vez que se deba comenzar a trabajar en ellos. Los requisitos pueden evolucionar con el tiempo y el equipo puede aprender sobre la marcha.

Resumen de la lección

En Agile, los requisitos del proyecto suelen adoptar dos formas: historias de usuario y epopeyas . Las historias de usuario tienen una estructura específica y se pueden completar en una iteración. Son exclusivos de Agile, pero los requisitos de las metodologías tradicionales son paralelos en el sentido de que deben definirse completamente antes de que pueda comenzar a trabajar en ellos. Las épicas a menudo se consideran historias de usuarios que son demasiado complejas o demasiado grandes. No tienen paralelo en las metodologías tradicionales porque no tienen que estar bien definidas y pueden permanecer en este estado a medida que comienzan otros trabajos de proyectos. Las épicas permanecen en la parte inferior de la acumulación de productos hasta que se convierten en una prioridad más alta. En este punto, se dividen en historias de usuarios para que pueda comenzar el trabajo.

Rodrigo Ricardo Editor y fundador