Historias de usuario
Páginas: 5 (1124 palabras)
Publicado: 24 de abril de 2013
Historias de Usuario
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 aguade 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 todoeste 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 unbuena 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. Lasreuniones 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 mejoresarquitecturas 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, ami 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 gransegunda 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. Alrealizarse 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...
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 aguade 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 todoeste 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 unbuena 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. Lasreuniones 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 mejoresarquitecturas 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, ami 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 gransegunda 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. Alrealizarse 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...
Leer documento completo
Regístrate para leer el documento completo.