Frente a la concepción tradicional de los requisitos software, donde trabajábamos con listados de necesidades, peticiones o restricciones del usuario con respecto a lo que debe hacer y cómo debe comportarse un sistema, en el contexto de las metodologías ágiles se ha optado por recoger esta información utilizando lo que se conocen como Historias de Usuario.
Una historia de usuario describe una funcionalidad que será útil para el usuario, o comprador, de un sistema software. Así, frente a mostrar un cómo, las historias de usuario cuentan un qué: describen una funcionalidad que deberá ser desarrollada, pero no cómo se desarrollará.
Pero además, Ron Jeffries comentaba que una historia de usuario no es sólo una descripción de una funcionalidad, normalmente en un post-it, si no que una historia de usuario incluirá otros dos componentes:
- La conversación que conllevan, ya que son una herramienta para facilitar la interacción entre usuarios y desarrolladores.
- La forma de confirmar que se ha implementado correctamente, es decir, de comprobar que el sistema entrega la funcionalidad a la que hace referencia esa historia.
Historias de usuario vs Requisitos
Aunque popularmente se ha asociado el concepto de historia de usuario con el de requisito funcional, una historia de usuario no es la especificación de un requisito software: detrás del concepto de historia de usuario hay muchos aspectos particulares que la hacen sustancialmente diferente de lo que es un requisito.
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. Por ello se recomienda que las historias de usuario se escriban en un espacio reducido, y que el soporte físico donde se recogen, habitualmente un post-it o tarjeta, incluya apenas una frase. Así, una historia de usuario debería ser pequeña, memorizable, y debería poder 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 la funcionalidad que describe.
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 entre el equipo de desarrolladores y el usuario. Ambos deberán interactuar para completar la información que no incluye la historia de usuario para poder desarrollar la funcionalidad descrita.