La historia de usuario no es el “requisito” de las metodologías ágiles
Archivado en agil en Dec.22, 2011 por jgarzas
En el contexto de una metodología ágil, popularmente se asocia el concepto “historia de usuario” con el de “requisito funcional”. Se habla de que las metodologías ágiles usan la “historia de usuario” y las tradicionales el “requisito funcional”. Aunque detrás del concepto historia de usuario hay muchos aspectos particulares que la hacen sustancialmente diferente de lo que es un requisito, diferencias que muchas veces son poco conocidas y que llevan a muchos equipos a muchas dudas y confusiones.
Una historia de usuario describe funcionalidad que será útil para el usuario, o comprador, de un sistema software. Y aunque normalmente las historias de usuario, asociadas a las metodologías ágiles, suelen escribirse en post-it o tarjetas, son mucho más que eso. Ron Jeffries comentaba que una historia no es sólo una descripción de una funcionalidad, normalmente en un post-it, una historia de usuario además está formada por otras dos partes más:
- La conversación que conllevan, ya que son una herramienta para interactuar.
- El cómo se confirma su implementación, las pruebas y verificación de la misma.
Las historias de usuario, frente a mostrar un “cómo”, sólo dicen el “qué”. Es decir, muestran funcionalidad que será desarrollada, pero no cómo se desarrollará. Por ello, cosas como que “el software se escribirá en C++” no es una buena historia de usuario.
Una historia de usuario no es la especificación de un requisito software
Como decía al principio, con mucha frecuencia se equiparan a las historias de usuario con los requisitos. Pero por definición, las historias de usuario no suelen, ni deben, tener el nivel de detalle que suele tener la especificación de un requisito. Si una historia de usuario tiene demasiada información, o incluso ocupa varios folios… no es una historia de usuario. Por ello se recomienda que las historias de usuario se escriban en un espacio reducido, y que el soporte físico, el post-it o la tarjeta, tenga apenas una frase.
Una historia de usuario debería ser pequeña, memorizable, y que pudiera ser desarrollada por un par de programadores en una semana. Pero claro, al tener una única frase, es imposible que una historia de usuario contenga toda la información necesaria para desarrollar. En tan reducido espacio no pueden contener el diseño, las pruebas, normativa, etc. Ni tampoco detalles para codificar.
Todo lo anterior presenta uno de los principales problemas que suelen encontrar los equipos de desarrollo a la hora de trabajar con metodologías ágiles. Por un lado se ven seducidos por la idea ágil, pero a la hora de ponerla en práctica encuentran problemas como que hay un montón de información (especificaciones, necesidades, normativas, no funcionalidades, criterios de interfaz, etc.) que típicamente estaban en la especificación de requisitos y que los equipos asocian que ahora deben estar en las historias de usuario. Pero la teoría dice que no debe ser así, que una historia de usuario es normalmente un post-it, y en un post-it no entra tal cantidad de información, con lo que muchos equipos acaban dividiendo en trozos de unos cuantos folios las tradicionales especificaciones de requisitos, llamando a cada una de esas divisiones historia de usuario. Pero esas divisiones, no son historias de usuario.
Para resolver el anterior problema hay que entender que las historias de usuario son lo que son porque su objetivo es, entre otros, lograr la interacción con el equipo y con el usuario, por encima de documentar (manifiesto ágil). Aunque la realidad de los proyectos y de los negocios hace que la teoría se deba ajustar a la práctica, para lo cual hay quien necesariamente relaja la agilidad usando los tradicionales requisitos en ciclos de vida ágil, hay quién usa casos de uso en vez de la historia de usuario o hay quien utiliza técnicas de trazabilidad para relacionar la historia de usuario con otros documentos, como normativa del cliente, diseños, etc. Constatando, como solemos comentar, que la teoría ágil se debe adaptar a cada caso en particular, muchas veces relajando la agilidad, obteniendo la verdadera riqueza y productividad de las múltiples soluciones que ofrece la ingeniería del software.
Referencias sobre el concepto historia de usuario
Parte de la información de este post está extraída del libro “User Stories Applied to Software Development”, el cual recomiendo para todo aquel interesado en este tema.
Otras entradas relacionadas con esta:
- Soporte ágil: ¿Aplican las metodologías agiles a un departamento de soporte a incidencias?
- Metodologías ágiles
- Una guía con lo más destacado sobre metodologías ágiles
- Experiencia en la implantación de CMMI-DEV v1.2 en una micropyme con metodologías ágiles y software libre
- Resumen de la semana: del 19 al 25 de Diciembre de 2011
Javier Garzás es profesor en la Universidad Rey Juan Carlos y director de
Información Bitacoras.com…
Valora en Bitacoras.com: En el contexto de una metodología ágil, popularmente se asocia el concepto “historia de usuario” con el de “requisito funcional”. Se habla de que las metodologías ágiles usan la “historia de usuario” y las tra……
Es que aquí cada uno pone su sal..
Sin acritud, pero,… a veces creo que hay mucho “ágil” improvisado..
En ninguna parte del manifiesto agil se habla de “docuemnto”, “documentar” o “documentacion” (http://agilemanifesto.org/iso/es/principles.html) por lo que no queda claro hasta donde mayor o menor documentación es más o menos ágil.
A mi modo de ver, las metodologías ágiles tienen varios aspectos para caracterizarlas, pero el principal no es el relacionado con la documentación sino que es la posibilidad de flexibilizar el control que proponen las metodologías tradicionales, en función de la incorporacion del conocimiento.
Me explico un poco mejor, en las metodologías tradicionales, al inicio de un proyecto, justo cuando menos conocemos sobre el dominio del problema, debemos establecer cuestiones tales como que cosas vamos a hacer y cuando las vamos a hacer con un nivel de detalle bastante alto. Y esto condiciona el resto del ciclo de vida. Y aumenta el costo de los cambios. Por eso en general buscan controlar desvios. El objetivo no es en si otorgar el valor buscado sino no desviarnos de lo que preveimos al inicio (cuando menos información teníamos).
En las metodologías ágiles en cambio, el control también es un objetivo (por eso se usan cosas tales como el burn-down-chart), pero como controlar TODO el proyecto es muy costoso y complejo, se priorizan que cosas se van a controlar llegando a extremos como los de kanban que minimizan la cantidad de tareas a controlar. Hacer poco pero bien. Y además al construir software de manera incremental, probablemente lo que el usuario acuerda que ya está correcto, no cambie, y las funciones en desarrollo, solo cambién requisitos que no fueron desarrollados aún por lo que el costo del cambio es mínimo.
Si para realizar las tareas de una iteración trazo una historia de usuario con UML (casos de uso o cualquier otro diagrama), o con lenguajes más duros como OCL, en todo caso estoy agregando valor a la especificación del requerimiento, tal vez sirva para entregar software funcionando mucho más temprano que si no tuviesemos dicha especificación, con lo cual cumplimos el manifiesto ágil. El punto pasa por no ceñirse a un proceso completo para todas las historias de usuario, sino solo para aquellas donde mayor especificación asegura tener el software esperado por el usuario antes.
En síntesis coincido bastante con que cada equipo lo debe implementar de la manera más eficiente, dado que según el manifiesto ágil, la mejor forma de funcionar es con equipos auto-organizados. No obstante el reducir documentación por el solo hecho de reducirla no implica ser más o menos ágil.
Muy buen artículo.
Saludos.
Hola,
Ese elemento especial que las caracteriza yo lo llamaría ciclo de vida iterativo.
Muy interesante el comentario
Saludos
[...] historia de usuario no es exactamente un ticket de incidencia. Te recomiendo aquí este post sobre el concepto “historia de usuario”. Aunque siempre se pueden hacer adaptaciones. Las historias de usuario pueden ser filtradas y [...]