Las Épicas son más usuales cuando se comienza a construir un producto o cuando se hace una extensión importante de un producto existente. Esto es así porque con los nuevos requisitos tenemos una tendencia natural a ser ambiciosos en cuanto a funcionalidad, y más aún, para conseguirla toda a la vez :-). Las mejoras (de requisitos ya implementados) y correcciones de fallos no suelen caer en categoría de Épicas.
En la siguiente figura se presentan 4 alternativas para enfrentar Épicas, haciendo analogía (un poco forzada) con lo que sería enfrentarnos zanparnos mucha comida.
En la imagen superior izquierda se ilustra la opción por defecto, no hacer nada en especial para abordar una Épica, asumiendo que se tardará un tiempo importante en terminarla y que esto puede conllevar inconvenientes. En la imagen superior derecha, aunque se mantiene la Épica como un solo ítem, éste se aborda colaborativamente, por ejemplo, dos o más desarrolladores trabajando a la vez en en la Épica. Esto haría posible terminar la Épica en un tiempo más corto y evita complicaciones que pueden surgir por dividir la Épica en ítems más pequeños. Esta opción es aconsejable cuando la Épica no es muy grande, es decir, cuando abordada colaborativamente sí que es posible terminarla dentro de una semana de trabajo.
La imagen de abajo a la izquierda ilustra dicha división de la Épica en ítems más pequeños. La división de una Épica en varios ítems es atractiva cuando se pueden abordar en paralelo varios de esos ítems. Pero el hacer trabajo en paralelo se ve obstaculizado cuando los ítems no son bastante independiente debido a las dificultades de coordinación e integración que puede conllevar la terminación dichos ítems. Otro importante inconvenientes es que al dividir la Épica podemos estar perdiendo la oportunidad de identificar lo esencial respecto de lo secundario, es decir, no cuestionar si es imprescindible implementar toda la Épica.
La opción de abajo a la derecha, intenta ilustrar que en lugar de zamparnos gran cantidad de comida a la vez, que lo mejor es hacerlo de forma progresiva y estratégicamente organizado para una dieta equilibrada. Esta es la opción más alineada con un enfoque ágil auténtico, pero siempre que se lleve a cabo con una orientación de MVP (Minimun Viable Product). Desarrollar una Épica con orientación MVP significa desarrollarla incrementalmente, paso a paso, poniendo el primer objetivo en una implementación mínima pero satisfactoria para una determinada versión del producto. Es decir, tal como se aplica MVP a nivel de producto como un todo, aplicarlo a nivel de una Épica. En la práctica esto conlleva discriminar entre lo esencial y lo secundario de la Épica. En términos de división de la Épica, solo necesitamos establecer dos ítems; uno como primera versión de la Épica y otro representando el "resto" de la Épica. Si trabajamos con Sprints el ítem primera versión se incluye en el Sprint y el "resto" se mantiene en el Backlog. Una vez terminado el ítem correspondiente a la primera versión MVP de la Épica el proceso puede repetirse con el ítem "resto" de la Épica. Esto continuaría hasta que se consuma y termine todo el trabajo restante de la Épica o hasta que el "resto" ya no sea tan prioritario en comparación con otros ítems pendientes. Es precisamente esta última situación la gran diferencia respecto de una división temprana del una Épica en varios ítems. Cuando se desarrolla incrementalmente una Épica, todo su desarrollo puede ser incremental, es decir, no es necesario definir en detalle toda la Épica, sino solo el MVP que se va a implementar inmediatamente (lectura recomendada: ¿Análisis-Parálisis o No Análisis?. MVP la respuesta razonable).
Patricio Letelier
No hay comentarios:
Publicar un comentario