EPICS STORIES

agosto 10, 2015

Categories: AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Una de las grandes novedades que introdujeron las metodologías ágiles fue la representación y especificación de los requerimientos: los mismos deben capturarse desde el punto de vista del usuario que interactuará con el sistema. La notación elegida se denominó User Stories (US).

Una US describe una funcionalidad que brinda el sistema que es de interés para usuarios del sistema. La pregunta que surge casi inmediatamente es: ¿qué tan general o específica debe ser una US?

Por ejemplo, una US podría ser: “como usuario quiero poder comprar electrónicamente un producto para evitar salir de mi casa a efectuar la compra”. Esta podría ser la única y gran US de todo un sistema dedicado a la venta mediante Internet. Sin embargo, redactada de esta forma y por sí sola, no es de mucha utilidad para la planificación y gestión de un proyecto. El otro extremo, igual de inútil, sería llenar el backlog de centenares de US con pequeña y limitada funcionalidad. En todo tiene que haber un equilibrio y el mismo viene dado a través de lo que se conoce como EPICS stories o simplemente EPICS [1].

Se trata de US grandes, generales, que se redactan como cualquier US, pero en el futuro serán descompuestas en muchas US más controlables.  Justamente por eso se denominan EPICS, por “épico” en inglés, en alusión a una funcionalidad “gigantesca” o “extraordinaria”. En lo que resta del artículo abordaremos el concepto de EPICS, su utilidad, y la manera de explotarlas a medida que avanzan los sprints y el backlog.

EPICS: Conceptos fundamentales

Al comienzo de un proyecto hay funcionalidades que están más visibles y son sencillas de especificar:

- “como usuario quiero loguearme en el sistema…”,

- “quiero agregar productos a mi carrito de compra”,

- “quiero poder pagar con tarjeta de crédito”,

- “quiero que mis datos estén protegidos”.

Sin embargo hay otras de las cuales no se conoce mucho, pero que de todas maneras se desea expresar que el equipo sabe que existen, aunque sea muy pronto para poder definirlas con mayor granularidad. Para este tipo de funcionalidad se utilizan EPICS. Las mismas permiten en etapas iniciales del proyecto dejar expresada una funcionalidad importante, pero sobre la cual no existen muchos datos todavía y no es posible asignar una estimación sobre su duración o esfuerzo.

Continuando el ejemplo del sistema de ventas online, una posible EPIC podría ser “quiero contar con un protocolo seguro y confiable de comunicación”. Esta US implica quizás el desarrollo de todo un protocolo específico que brinde seguridad y redundancia de datos y que involucre distintas infraestructuras y tecnologías como Posnet o servicios web que proveen las tarjetas de crédito. Dado el contexto, es probable que el equipo de desarrollo no pueda estimar el esfuerzo o duración de esta funcionalidad, y no esté por el momento en condiciones de brindar más detalles o comportamiento. Así, dicha funcionalidad queda expresada en el backlog como una EPIC, especificada de manera general.

El rol de las EPICS en el backlog es justamente ese: dejar por explícito que hay una tarea importante por delante por hacer, pero que por el momento no es posible ni beneficioso hacer nada más.

Descomposición de EPICS

Más adelante, y con el equipo más afianzado en el proyecto, el Scrum Master estará en condiciones de dividir una EPIC en varias US. Éstas US si contarán con la suficiente granularidad y detalle para poder ser estimadas, y podrán ser descompuestas en tareas asignables a los recursos humanos que forman el proyecto. Pero esta descomposición recién se hace al momento de incluir parte de la funcionalidad descrita en la EPIC en el próximo sprint. Tal como está definida, es imposible asignarla a un sprint. Si se desconoce el esfuerzo que le llevará al equipo desarrollarla, es imposible saber si puede “entrar” en el próximo sprint o no.

En este momento el Scrum Master con la colaboración del equipo de desarrollo toma riendas en el asunto y se pasa a dividir una EPIC en US manejables y estimables. Así, en el caso de la EPIC sobre el protocolo, pueden surgir US y tareas más detalladas:

EPIC US
“quiero contar con un protocolo seguro y confiable de comunicación” - estudiar tecnologías y protocolos de comunicación- generar la integración con servicios Posnet

- validar la interacción con los servicios web de las tarjetas de crédito

- desarrollo del protocolo de comunicación

- validación del protocolo

Conclusiones

El rol de las EPICS es importante dentro de las metodologías ágiles. Le brindan al mecanismo la suficiente flexibilidad como para dejar expresado que existe una porción importante del sistema que deberá ser tenida en cuenta y explotada más adelante en el proceso de desarrollo. Pero al mismo tiempo queda explícitamente documentada, lo cual permite su visibilidad, tanto para el equipo de desarrollo y Scrum Master, como así también para el Product Owner y todo aquel involucrado en el proyecto.

Referencias

[1] http://www.romanpichler.com/blog/epics-and-ready-stories/

Top Insights

Ciclos de vida BPM

Ciclos de vida BPM

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Criterios de Aceptación

Criterios de Aceptación

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Escribiendo User Stories en Agile

Escribiendo User Stories en Agile

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
What is TM Forum Frameworx and how to apply it to your business?

What is TM Forum Frameworx and how to...

UncategorizedAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Impact Mapping en Metodologías ágiles

Impact Mapping en Metodologías ágiles

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Top Authors

Axel Salmeron

Axel Salmeron

Sr Developer

Nicolas Cieri

Nicolas Cieri

Solution Architect

Alvaro Soria

Alvaro Soria

Solution Architect

Sergio Fiorillo

Sergio Fiorillo

Engineering Manager

Pablo Alvarez

Pablo Alvarez

Delivery Director, Finance & Commerce

Blog Categories

  • URL copied!