La historia de usuario no es el “requisito” de las metodologías ágiles

En el contexto de un framework á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.

21 comentarios en “La historia de usuario no es el “requisito” de las metodologías ágiles”

  1. Pingback: Bitacoras.com

  2. 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.

  3. Pingback: Soporte ágil: ¿Aplican las metodologías agiles a un departamento de soporte a incidencias? - Javier Garzás, sobre calidad software y otros temas relacionados

  4. Pingback: Ejemplos y buenas prácticas para descomponer historias de usuario en tareas (parte 1 de 2) - Javier Garzás, sobre calidad software y otros temas relacionados

  5. Pingback: Ejemplos y buenas prácticas para descomponer historias de usuario en tareas (parte 2 de 2) - Javier Garzás, sobre calidad software y otros temas relacionados

  6. Pingback: Scrum para Dummies (1/2). Las ideas de Scrum en 2 post de 5 min. - Javier Garzás, sobre calidad software y otros temas relacionados

  7. Pingback: Roadmap ágil: Usando un “roadmap” en un proyecto ágil (2/2) - Javier Garzás, sobre calidad software y otros temas relacionados

  8. Pingback: Así fue mi primer proyecto ágil (cómo lo gestionamos y cosas que aprendimos) - Javier Garzás, sobre calidad software y otros temas relacionados

  9. Pingback: Historia de Usuario | Business World TI

  10. El punto clave sobre el tema de la documentación es si la metodología está orientada o no a la documentación. Documentar hay que hacerlo en todo aquel proyecto que no sea de usar y tirar por que hay que mantenerlo a lo largo de toda su vida útil.

  11. Hola Javier, ante todo muchas gracias por tus artículos, me parece que van realmente al grano 🙂
    He leído toda la serie que has escrito sobre historias de usuario, tareas técnicas, etc. Pero tengo dudas en este artículo en el que diferencias historia de usuario de requesito. Me queda claro que son cosas diferentes, que la historia de usuario ha de ser una frase corta en un lenguaje que el usuario final o cliente entienda.
    Lo que no veo es cómo enlazar historias de usuario a unos requerimientos. Te cuento cómo lo hacemos nosotros hoy, para que puedas corregirnos… estamos empezando a asociar una cosa con la otra…
    Nosotros creamos unos documentos de requerimientos en Confluence con una plantilla de tipo «Requerimientos», que te permite asociar el documento a una épica, y luego en la plantilla hay una tabla que pone «Requirements» (entiendo que serían sub-requisitos) y ahí estamos poniendo un link a un incidente de jira, que podría desglosarse en otros.
    Bastaría con que esos links (los de cada sub-requisito del documento de requisitos) apuntase a una historia de usuario o bien a otro documento de requisitos?
    No sé si el hecho de disponer de esos documentos de requisitos le resta agilidad al desarrollo… Ni sé si lo que propones es prescindir de esos requisitos y funcionar sólo con historias de usuario…
    Ya puestos, tampoco sé dónde quedarían los casos de uso aquí…
    Ando un poco perdido, porque estoy intentando funcionar de una forma ágil desde hace relativamente poco, a ver si pudieses darme algunas pautas en esto…
    Muchas gracias por adelantado, Javier.
    Un saludo 🙂

  12. Muy buen artículo y blog en general. Claro y conciso. Respecto al tema de historias de usuario y metodologías ágiles mi problema es que he terminado siendo bastante escéptico, principalmente porque no he conseguido experimentarlas pese a que en todas las empresas de software donde he estado (y han sido unas cuantas) se han intentado implantar.
    No me gusta parecer cínico y de hecho creo firmemente en estas metodologías ya que sus ventajas son evidentes frente a las tradicionales. Pero os puedo asegurar que si se consideran las metodologías tradicionales ineficientes y poco flexibles en comparación, es muchísimo peor para el proyecto aplicar una metodología ágil por alguien que no tiene ni idea real de cómo hacerlo, y lo que es peor, está convencida de que sí la tiene.
    Igual me estoy desviando un poco del tema en sí de metodologías y entro en el de las personas, pero al final, las metodologías no son más que maneras de funcionar entre personas.
    Creo que estas metodologías requieren de una madurez personal y profesional más alta que las tradicionales. Un pilar de estas metodologías son las reuniones. Reuniones para decidir cosas, no para que alguien diga lo que hay que hacer a los demás. Se debe huir del concepto piramidal del «jefe». Y hay mucha gente que no entiende o no quiere adoptar este concepto de relación laboral.
    Sin más, quería aportar desde mi experiencia, un aspecto que he reflexionado más de una vez sobre la adopción de estas metodologías que considero que es muy importante y se suele evitar por el pudor de no entrar en temas personales o de comportamiento de las personas. No es tanto desviarse del tema de la metodología en sí, sino verlo desde otra perspectiva.
    Saludos

  13. Hola Javier,
    Un dato interesante; acabo de leer esta publicación y notar que tiene nada más y nada menos que casi 4 años y sigue tan vigente (al menos desde mi experiencia), haciéndome pensar por momentos que estaba escrita hace menos tiempo.
    Hace un par de releases empezamos a escribir historias de usuario y notar que las mismas no tienen el detalle que si tenían el documento EsRe especialmente para los que integramos el equipo de pruebas. Es más, buscando una retroalimentación de la nueva manera de escribir lo que el cliente desea en cada release, nos dimos cuenta que la información allí desplegada es mucho más útil para nosotros que para el mismo cliente! En este momento estamos buscando la forma de acoplar las historias de usuario con los requerimientos funcionales a modo de no perder de vista los grandes temas (técnicos y no técnicos) de cada release; por esa razón caí en este post ;-).
    Como en unos algunos comentarios anteriores, considero que primero habrá que tener en cuenta los fundamentos de la metodología para luego poder empezar la adopción/adaptación al proceso entero (análisis, documentación, programación, pruebas, métricas, etc) y sin duda perder el miedo a intentarlo!
    Saludos,

  14. Javier Garzás por esto eres uno de mis referentes en cuanto a agilismo en el desarrollo de software. Llevo un tiempo desarrollando una propuesta metodológica que busca mezclar de todo un poco que pueda ser útil y más que nada flexibilizar sin perder el enfoque de calidad. En estos dos artículos dejo claro como coincido contigo y planteo dos especificaciones de requisitos.
    1. Sería la historia de usuario que nos permite interactuar con el usuario y clientes: https://metodologiadac.blogspot.com/2017/03/plantilla-de-especificacion-de.html
    2. Sería la especificación o caso de uso detallado para el equipo de desarrollo: https://metodologiadac.blogspot.com/2017/03/plantilla-de-especificacion-de-requisitos2.html

  15. Pingback: Applying Scrum, key Agile insights into this methodology

  16. Entiendo que las historias de usuario son «cosas» a hacer, pero el detalle (especificación) de cada historia de usuario, ¿dónde y cómo se haría?

    Gracias.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba