Cuando nos enfrentamos a la gestión de un proyecto, uno de los puntos clave del mismo es la gestión de tareas y su flujo. Qué tipo de tareas puede tener un proyecto y a qué estados pueden cambiar vendrán determinados por la tipología del proyecto, el tipo de gestión que vayamos a realizar y cómo está conformado el equipo que trabajará en él. En este artículo vamos a repasar algunos principios relacionados con los distintos tipos de tareas que podríamos encontrar en un proyecto agile.
Los proyectos denominados ágiles han sido la cuna de nuevos tipos de tareas que hasta no hace tantas décadas no existían. Scrum ha sido el framework que más ha popularizado las mismas, y gracias a ello palabras como Epic o User Story son tan comunes en la gestión de proyectos que nadie va a levantar una ceja si las decimos en alto. Dada esta popularidad, vamos a enumera los principales tipos de tareas que podríamos ver en un desarrollo ágil gestionado desde Secture:
- Epica (Epic).
- Historias de usuario (User Story).
- Spike.
- Tarea.
- Tarea QA.
- Bug backlog/bug/hot fix.
Épica
Objetivo de alto nivel que se busca en un proyecto. No es una tarea en sí, sino que sirve para agrupar una serie de tareas e historias de usuario que buscan un mismo fin. Es decir, es un requisito a alto nivel, una idea primordial que, para abordarse, necesita desglosarse en paquetes funcionales más pequeños.
De esta manera, una épica podría ser «Sistema de compras en la plataforma», que contendría un número de tareas, historias de usuario, etc en su interior que estarían enfocadas en conseguir tener un sistema completo de compras. Por ejemplo, tendríamos que desarrollar una ficha de producto, un buscador, un carrito de la compra, conectarnos a una pasarela de pago, gestionar inventario, gestionar envíos/devoluciones, etc, etc.
Si estamos trabajando bajo un sistema iterativo basado en sprints, es importante entender que una épica, por tamaño y complejidad, no suele poder acabarse en un sólo sprint.
Flujo y estados de una épica
Las épicas se usan a modo conceptual. Los estados que pueden albergar dependerán bastante de quién dirija el proyecto, pero podríamos hacer una aproximación bastante acertada si contemplamos los siguientes:
- Backlog: la épica aún no está lista para trabajar sobre ella. Bien puede ser porque aún no tenemos completas todas las tareas/historias de usuario que la componen, bien porque aún no es el momento de abordarla.
- To Do: está lista para iniciarse en alguno de los sprints venideros.
- In progress: la épica está en progreso. Eso significa que se está trabajando sobre una o más de las tareas/historias de usuario que la componen.
- Blocked: por alguna razón, en estos momentos es imposible seguir trabajando en tareas/historias de usuario de la épica, por tanto se queda bloqueada.
- Done: las tareas/historias de usuario que pertenecen a la épica se han terminado
- Published: la épica se ha puesto en producción.
- Discarted: hay veces en que, según avanza nuestro proyecto/producto, nos damos cuenta de que hay una funcionalidad (o un grupo de funcionalidades) que ya no tienen sentido o han perdido todo su valor. En ese caso, quedarían descartadas. Es mejor descartar que borrar, así mantenemos un pequeño histórico de todo lo que pretendíamos desarrollar.
Historia de usuario
Las historias de usuario son, en esencia, una forma ágil y sencilla de representar lo que antiguamente llamábamos un requisito funcional. Por fortuna, las reglas que existen para crear una historia de usuario permiten que sea un sistema mucho más coherente, transparente y participativo que los clásicos manuales funcionales llenos de párrafos y párrafos ininteligibles.
Como nota adicional, comentaré que una historia de usuario puede ser parte de una épica, pero también puede ir suelta. Muchas historias de usuario no pertenecen a una épica debido a que no necesitan agruparse y tienen sentido por sí mismas. De hecho, el uso de épicas no es absolutamente necesario en un proyecto agile.
¿Cómo crear una historia de usuario?
Las historias de usuario están divididas en tres partes, conocidas como las tres C: card, conversación y confirmación.
Card (tarjeta)
Esta es la frase (o título, para quien lo prefiera) que nos adelanta qué es lo que se pretende abordar en la fase de desarrollo. Tiene el siguiente formato:
Como [tipo de usuario] necesito [necesidad] para [beneficio esperado]
Esto define tres aspectos fundamentales en una HU:
- Tipo de usuario: nos asegura el hecho de que tenemos identificados todos los tipos de usuarios que afectan al proyecto. Por ejemplo, el tipo de usuario podría ser el cliente, el administrador de la plataforma, los usuarios premium, etc, etc. Esto responde al «para quién».
- Necesidad: nos asegura el hecho de tener definido qué es lo que pretendemos al desarrollar esta funcionalidad. Esto responde al «qué».
- Beneficio esperado: nos asegura del hecho de que esta HU aporta un valor concreto al usuario definido. Aquí detallamos cuál es el objetivo final de este desarrollo. Esto responde al «por qué».
Ejemplos de cabeceras válidas de historias de usuario:
- Como [usuario de la plataforma], necesito [un lugar donde poder registrarme] para [acceder a las funcionalidades de la misma].
- Como [administrador del e-commerce], necesito [un formulario] para [poder dar de alta productos nuevos].
- Como [comprador], necesito [un lugar en la web donde se vean mis compras] para [poder ver el estado del envío].
Conversación
La conversación es un debate cara a cara con la persona que ha creado la HU (Product Owner, Product Manager, etc). En esta conversación se busca lo siguiente:
- Que el equipo entero (desarrolladores, diseñadores, PM/PO, etc) comprendan la HU y sus objetivos. La idea es seguir con la conversación hasta que todo el mundo tiene claro qué se busca, para quién y por qué.
- Que las personas que trabajarán para desarrollar la historia, tengan claras las tareas que van a tener que crear para conseguirlo.
- Que el equipo que vaya a trabajar sobre la HU pueda estimar su dificultad (bien en tiempo, bien en puntos de esfuerzo).
La importancia de este debate reside en el hecho de que las historias de usuario no deben ser un mandato de la gerencia del proyecto o del cliente, sino una petición de una necesidad cuya solución (la forma en la qua la abordaremos) provenga del equipo entero. Durante esta conversación el equipo entenderá qué se pretende, se acordará cómo llegar a ello y, por último, se llegará a un compromiso del coste de realizarlo, bien en puntos de esfuerzo (que cada vez se usan menos), bien en tiempo.
Además, ya en ese momento o un poco después, los encargados del desarrollo de cada historia de usuario deberán crearse a sí mismos las tareas necesarias para esa labor (luego hablaremos de esto), y asociarlas a la historia de usuario pertinente.
Confirmación
También llamada Criterios de aceptación. Este es el acuerdo de comportamiento en cuanto vamos a tratar de construir y que va a reflejar si conseguimos realizar lo que se esperaba.
Los criterios de aceptación son las condiciones que la historia de usuario debe cumplir para que se dé su desarrollo como correctamente terminado. Tienen un comportamiento binario: o se cumplen o no se cumplen, no hay estados intermedios.
Ejemplos de criterios de confirmación clásicos que pueden acompañar a una historia de usuario (en Secture no los trabajamos exactamente así, un poco más abajo lo explico):
- Dada una búsqueda del usuario en la home, cuando le da al botón intro en su teclado, entonces le reenviaremos a la página de resultados.
- Dado que el usuario ha presionado el botón comprar y ha llegado a la página de confirmar compra, cuando elige PayPal como método de pago, entonces le reenviamos a la pasarela de pago de PayPal.
Nosotros, en Secture, no usamos el método clásico, ya que, en términos generales, se hacen más complejos de entender y, sobretodo, cohesionar entre ellos. Nosotros usamos un lenguaje llamado Gherkin, que nos ayuda a tener estructurado el comportamiento esperado, de una manera que entienden tanto los clientes, como los PMs, como los desarrolladores, testers, etc. Escribiremos, no dentro de mucho, otro artículo que explique Gherkin.
Flujo y estados de una historia de usuario
Los estados y flujos de una historia de usuario son muy similares a los de la épica:
- Backlog: la historia de usuario aún no está lista para trabajar sobre ella. Bien puede ser porque aún no tenemos completas todas las tareas que la componen, bien porque aún no es el momento de abordarla.
- To Do: está lista para iniciarse en el actual sprint.
- In progress: la historia de usuario está en progreso. Eso significa que se está trabajando sobre una o más de las tareas que la componen.
- Blocked: por alguna razón, en estos momentos es imposible seguir trabajando en sus tareas.
- Done: todas las tareas que pertenecen a esta historia de usuario se han terminado
- Published: todos los desarrollos de las tareas hijas (working progress) se ha puesto en producción.
- Discarted: ha quedado descartada por algún motivo. En el caso de las historias descartadas, éstas no cuentan de cara al incremento de valor de un sprint.
Spike
Un spike no es más que un ejercicio de I+D dentro de un sprint. Hay veces en que necesitamos tiempo para indagar en algo, ya sea un aspecto técnico o no, y esta investigación por sí misma no tiene sentido en formato de historia de usuario, ya que no aporta valor (working progress) al final del sprint. Dicho esto, tan sólo tiene dos normas:
- Su duración no debe exceder la duración de un sprint.
- No cuenta de cara al incremento de valor del sprint.
Flujo y estados de un spike
Los flujos y estados de un spike son muy parecidos a los de una historia de usuario, salvo por la excepción del estado Published, el cual no tiene sentido al tratarse de un ejercicio de I+D.
Tarea
Las tareas nacen a partir de las historias de usuario. Una vez tenemos una historia de usuario cerrada y discutida (en el buen sentido de la palabra), toca crear las tareas necesarias para cumplir con todos los criterios de aceptación. Si, por ejemplo, tenemos una historia de usuario que nos pide que montemos un sistema de login en base a un user y un password, de ahí nacerían distintas tareas que implicarían, muy probablemente, a desarrolladores frontend, desarrolladores backend, diseñador, etc, etc. Podríamos encontrar tareas del siguiente tipo:
- Crear tabla en base de datos para guardar usuarios de la plataforma.
- Diseñar formulario de login.
- Maquetar formulario de login.
- Crear validaciones locales de datos.
- Crear un endpoint que…
- Etc, etc
Las tareas, a diferencia de las historias de usuario, han de crearlas las personas que las vayan a realizar. Si son, por ejemplo, técnicas, las debe crear el equipo de desarrollo. Un PO no sabe, ni tiene por qué saber, de aspectos técnicos, por lo que no debe ser la figura que defina una tarea asociada a una historia de usuario.
Flujo y estados de una tarea
Los flujos y estados de una tarea son más complejos que los que hemos visto hasta ahora. El flujo de trabajo que suelen seguir los equipos de desarrollo requiere de una serie de estados nuevos que vamos a ver a continuación:
- Backlog: la tarea aún no está lista para trabajar sobre ella debido a que aún no la hemos terminado de definir.
- To Do: está lista para iniciarse.
- In progress: está en progreso.
- Ready to Code Review: si estás trabajando en un equipo con más desarrolladores y tenéis implementados buenas prácticas y protocolos a la hora de hacer código, lo idóneo es que otro desarrollador chequee el código realizado en la tarea antes de darlo por bueno. Este estado no siempre tiene sentido, ya que hay tareas que no tienen por qué implicar desarrollo de código (por ejemplo, crear una nueva columna en una tabla de la base de datos).
- Code Review: la tarea está pasando el proceso de Code Review en estos momentos.
- Ready to Test: la tarea está lista para ser probada por QA en algún entorno.
- Testing: la tarea está siendo probada por QA en algún entorno.
- Done: la tarea se ha finalizado.
- Published: la tarea se ha puesto en producción.
- Blocked: por alguna razón, en estos momentos es imposible seguir trabajando en ella.
- Discarted: la tarea ha quedado descartada por algún motivo.
Tarea QA
Las tareas QA son tareas que tienen como finalidad el realizar una prueba (testing) sobre:
- Otra tarea.
- Una historia de usuario.
- Un proceso o flujo que puede incluir varias tareas y/o historias de usuario.
Las tareas QA pueden estar planificadas en el sprint o aparecer por sorpresa (por ejemplo, si a partir de un hotfix o bug aparece una tarea de control de calidad para evaluar que ha sido resuelto). Estas tareas las debe hacer un QA engineer y pueden ser tanto de carácter manual/funcional (usando el soft desarrollado directamente) como de carácter automático (test unitarios, test de integración, end to end, etc).
Flujo y estados de una tarea
Los flujos y estados de una tarea QA son algo más sencillos que los de las tareas estándar:
- Backlog: la tarea QA aún no está lista para trabajar sobre ella debido a que aún no la hemos terminado de definir.
- To Do: está lista para iniciarse.
- In progress: está en progreso.
- Done: se ha finalizado.
- Blocked: por alguna razón, en estos momentos es imposible seguir trabajando en ella.
- Discarted: ha quedado descartada por algún motivo.
Este tipo de tareas suele afectar a los estados de otras tareas estándar, ya que muchas veces estaremos haciendo testing sobre las mismas (estado Testing) y, si descubrimos que su comportamiento no es el esperado, la tarea estándar pasará a un estado To Do, mientras que si todo funciona correctamente, pasaríamos la misma a Done.
Bug backlog, bug y hot fix
Si hacemos una búsqueda por internet, veremos que hay muchas opiniones sobre cuál es la manera de gestionar los errores o bugs dentro de un proyecto. Personalmente prefiero conceptualizar los bugs en tres tipologías distintas:
- Hot fix: errores críticos que necesitan resolverse sí o sí y de forma inmediata. No son predecibles y no estaban planificados para el sprint, pero tienen prioridad y afectan a nuestras previsiones de cantidad de working progress a entregar al final del sprint. No cuentan de cara al incremento de valor de un sprint.
- Bugs: son aquellos bugs que se detectan durante un sprint y son subsanables en el mismo. Se encuentran bien a través de procesos como las tareas QA o las quejas de los usuarios, por ejemplo. Aunque no estaban planificados, el sprint puede absorberlos (recordemos que, idealmente, todos los sprints reservan un 20% del tiempo a este tipo de tareas). No cuentan de cara al incremento de valor de un sprint.
- Bug backlog: son bugs detectados en anteriores sprints cuya resolución no pudo ejecutarse en los mismos. Una vez recopilados, creamos una historia de usuario que contemple resolverlos. Debido a que son planificables, sí cuentan de cara al incremento de valor de un sprint.
Recordemos que el hecho de que un bug no cuente de cara al incremento de valor de un sprint, no significa que no haya que medir su impacto y esfuerzo. Debemos hacerlo para entender cuánto tiempo estamos dedicando a resolver problemas (desarrollo correctivo) en vez de a crear valor (desarrollo evolutivo). Cuantos más datos tengamos, más fácil será encontrar las causas y generar líneas de acción para evitar este tipo de desarrollos.
Flujo y estados de un bug backlog, bug y hot fix
Los flujos y estados de un tarea de tipo bug son exactamente los mismos que los de una tarea estándar, ya que será necesario pasar por los mismos procesos que ante una tarea ordinaria.
Conclusiones
Hay mucho debate sobre los tipos de tareas que existen y sus flujos de estado. Lo ideal es que cojas aquello que consideres que mejor se adapta a tu proyecto, a tu equipo y al contexto general en el que te mueves y hagas pruebas. El tiempo y la experiencia te irán ayudando a pulir aspectos y matizar ideas. También descubrirás que no todos los proyectos se gestionan igual y tienen las mismas reglas. Lo importante es tener una base sólida con la que empezar (y creo que este artículo te puede ayudar a ello) para coger experiencia y hacer tus propias modificaciones.
