Hoy es el día 0 del proyecto que me va a llevar a mí y al resto de compañeros a construir una buena y bonita aplicación, de la cual nos ha hablado con entusiasmo nuestra directora, nuestro gerente y el jefe de proyecto.
Tiene pinta de ser un poquillo compleja y, además, el JP lleva casi un mes escribiendo el documento de análisis funcional que estamos esperando como agua de Mayo. A ver si firma de una vez el cliente y nos ponemos a lanzar líneas de código.
La cara de todos se queda un poco más pálida cuando nos encontramos enfrente de 150 páginas de casos de uso, tablas de funcionalidades, de acciones externas e internas, de diagramas de estado, de esquemas de datos, de diagramas de clases. Todo siguiendo un estricto UML.
Para finalizar, o en medio de todo este volumen de papel, me encuentro con la matriz de trazabilidad que relaciona los diferentes casos de uso con el requisito que lo cumplimenta y que, seamos sinceros, es absolutamente ilegible en cuanto supera las 20 filas por 20 columnas.
Hagámoslo Agile, hagámoslo en equipo
Hoy es el día 0 del primer Sprint del proyecto que va a llevar al equipo en donde estoy integrado, a realizar un buena y bonita aplicación. Y de la cual dirección nos ha hablado con entusiasmo.
Como casi siempre, no tenemos Product Owner, si no un JP haciendo labores de Proxy. Y se ha tirado dos semanas haciendo reuniones de toma de requisitos con el cliente para iniciar la construcción del product backlog, para que empecemos a tirar líneas en cuanto tengamos para rellenar el primer Sprint de tareas. Las reuniones para escribir, priorizar y mover las Historias de Usuario seguirán durante todo el proyecto.
Nos removemos en nuestras sillas. Ya empieza la acción. El PO (realmente el proxy), nos da la visión general que el cliente ha transmitido, y nos desglosa las historias de usuario en tareas.
Ahora nos toca el plantear las preguntas. El hacer emerger los mejores diseños y las mejores arquitecturas del análisis funcional de cada historia de usuario, en equipo.
Finalmente salimos de la reunión con el Product BurnDown y el Sprint BurnDown listos para empezar a quemar tareas. Con los criterios de aceptación claros. Y todo en un lenguaje natural claro y sencillo, asimilando el glosario del dominio. Y, por supuesto, al alcance de la mano en el repositorio documental o en el tablero.
Historias de usuario vs casos de uso UML
¿Pero qué es una Historia de Usuario, y porqué son tan importantes como toma de requisitos en un ambiente productivo Agile?
La primera gran diferencia es que en un análisis funcional con descripción de requisitos, generalmente se utiliza UML. Un lenguaje descriptivo pensado inicialmente en la sencillez de la comunicación y que se ha convertido en un, a mi parecer, monstruo que entienden muy pocos y que utilizan correctamente aún menos.
En cambio la Historia de Usuario está escrita en lenguaje coloquial al ser, simplemente, el recordatorio de la conversación con el cliente. Y un acuerdo formal de mínimos para dar por buena la funcionalidad descrita y esperada.
El concepto de Criterios de Aceptación de las Historias de Usuario, es la gran segunda ventaja sobre los requisitos funcionales UML. Ya que no requieren de las terribles matrices de seguimiento de requisitos, al incluir en la propia HU las pruebas que debe superar para ser aceptada como completada. Y que dicha aceptación es binaria: o vale o no vale. No hay medias tintas, ni el 99% finalizado. El concepto de “Done” en estado puro.
Las Historias de Usuario están vivas. Al realizarse el análisis funcional y técnico en profundidad en la reunión de planificación del Sprint, su desglose en tareas lo realiza un equipo de personas. Y ya se sabe lo cierto del dicho que dice “dos cabezas mejor que una”, y no veas si son cinco o nueve. El nivel de detalle y previsión supera en mucho al que puede hacer un único arquitecto o analista funcional.
Mientras, el resto de las Historias de Usuario pueden ser modificadas en su declaración, en su objetivo o en sus criterios de aceptación. Pueden ser re priorizadas u ordenadas por nuevos parámetros que le surjan al cliente. O pueden ser sacadas del Product Backlog al modificar el alcance o las tareas ha desarrollar.
Por último, hay una ventaja de la forma en que se construyen las historias de usuario, una conversación con el cliente, que es muy poderosa. Las historias de usuario, en cualquiera de sus características indican, señalan y emergen otras Historias de Usuario que pudieran estar ocultas o no existir.
Características de una Historia de Usuario
Las Historias de Usuario están divididas en dos apartados diferentes, el enunciado y los criterios de aceptación.
Si estuviéramos escribiéndolas en una cuartilla, como mandan los cánones y que yo nunca cumplo, escribiríamos el enunciado en el anverso y los criterios de aceptación en el reverso. Pero en mi caso particular, que utilizo a veces un tablero físico con post-it pero mucho más tableros electrónicos, siempre pongo el enunciado encima de los criterios de aceptación y los separo con una línea o de alguna forma visible que divida la tarjeta, sea física o virtual, en dos.
La manera más estándar de construir el enunciado es: Como [tipo de usuario] Quiero [hacer, conseguir, obtener algo] Para [el motivo por el que quiero hacer el Quiero]
Y a continuación desgrano los Criterios de aceptación de forma taxativa. Quiero poder pulsar el botón. Quiero ver un listado con las marcas de coches. Quiero abrir la página desde mi móvil y sea agradable de ver (aquí emergen más historias de usuario)
Además, las Historias de Usuario deben cumplir las siguientes características para que puedan realizar su función de manera correcta:
Independientes. Deben ser atómicas en su definición. Es decir, se debe intentar que no dependa de otras historias para poder completarla.
Negociables. Como he dicho anteriormente, son entidades vivas. Deben ser ambiguas en su enunciado para poder debatirlas, dejando su concreción a los criterios de aceptación.
Valoradas. Deben ser valoradas por el cliente. Para poder saber cuanto aporta al Valor de la aplicación y junto con la estimación convertirse en un criterio de prioridad.
Estimables. Aunque sea siempre un poco como leer de una bola de cristal, deben poder ser estimadas. Tener su alcance lo suficientemente definido como para poder suponer una medida de trabajo en la que pueda ser completarla.
Pequeñas. Para poder realizar una estimación con cierta validez y no perder la visión de la Historia de Usuario, se recomienda que sean mayores de dos días y menores de dos semanas.
Verificables. Este es el gran avance de las Historias de Usuario. Que, junto con el cliente, se acuerdan unos Criterios de Aceptación que verifican si se ha cumplido con las funcionalidades descritas y esperadas.
Ejemplo real
Para finalizar este artículo, quiero compartir una Historia de Usuario real para que sirva de ejemplo de lo que estoy hablando.
Como usuario validado.
Quiero poder dar de alta anticipos.
Para poder recibir dinero anticipado para gastos.
Criterios de aceptación:
Quiero poder de alta un anticipo rellenando el formulario de anticipos.
Quiero poder dar de alta la petición de un anticipo del tipo permanente.
No debo poder solicitar dos anticipos permanentes.
No debo poder solicitar dos anticipos normales.
Debo poder solicitar un anticipo permanente y uno normal, y viceversa.
Cuando pulse “Aceptar o Grabar” debe de registrarse la solicitud en el sistema y desencadenar el flujo de aprobaciones.
Cuando pulse “Aceptar o Grabar” el formulario debe quedar bloqueado para su edición.
La visión general, es un gestor de anticipos a cuenta. La historia de usuario trata del formulario para pedir un anticipo para gastos. Y es parte de un Product Backlog real de un proyecto del cual soy responsable.
Y funciona…