Las Historias de Usuario son la forma principal de capturar los requisitos en Extreme Programming (XP). Son descripciones concisas de una funcionalidad del sistema desde la perspectiva del usuario final, escritas en un lenguaje sencillo y no técnico. Su objetivo es facilitar la comunicación y la comprensión de lo que el cliente realmente necesita.
5.1. Qué son y cómo se redactan
Una Historia de Usuario es una breve descripción de una funcionalidad deseada, expresada en el lenguaje del negocio y enfocada en el valor que aporta al usuario. En XP, son el cliente quien las escribe, aunque el equipo de desarrollo puede ayudar a refinarlas.
El formato estándar para redactar una historia de usuario es:
Como [rol del usuario], quiero [acción/funcionalidad], para poder [beneficio/razón].
- Como [rol del usuario]: Identifica quién es el usuario que necesita la funcionalidad. Puede ser un tipo de usuario (ej. "administrador", "cliente", "visitante") o un sistema externo.
- Quiero [acción/funcionalidad]: Describe lo que el usuario quiere hacer con el sistema. Debe ser una acción concreta y observable.
- Para poder [beneficio/razón]: Explica el valor o el objetivo que el usuario logrará al realizar esa acción. Esta parte es crucial para entender la importancia de la historia.
Además de este formato, las historias de usuario deben cumplir con las "Tres C" y los criterios INVEST:
- Las Tres C:
- Tarjeta (Card): La historia se escribe en una tarjeta física o digital como un recordatorio de la conversación.
- Conversación (Conversation): La tarjeta no es el requisito completo; es un punto de partida para una conversación detallada entre el cliente y el equipo.
- Confirmación (Confirmation): Se definen los criterios de aceptación que el cliente usará para confirmar que la historia ha sido implementada correctamente.
- Criterios INVEST: Las historias deben ser:
- Independientes: Se pueden desarrollar y entregar de forma aislada.
- Negociables: No son contratos rígidos; son flexibles y pueden cambiar.
- Valiosas: Aportan valor real al cliente o usuario.
- Estimables: El equipo puede estimar el esfuerzo necesario para completarlas.
- Pequeñas (Small): Son lo suficientemente pequeñas para ser manejables y completarse en una iteración.
- Testeables: Tienen criterios de aceptación claros que permiten verificar su implementación.
5.2. Priorización por valor de negocio
En XP, la priorización de las historias de usuario es una responsabilidad clave del cliente y se basa fundamentalmente en el valor de negocio que cada historia aporta. El objetivo es asegurar que el equipo siempre esté trabajando en las funcionalidades que generen el mayor retorno de inversión para el negocio.
- Valor de Negocio: El cliente asigna un valor a cada historia, que puede ser monetario, estratégico, de reducción de riesgos, de aprendizaje, etc.
- Estimación del Esfuerzo: El equipo de desarrollo estima el esfuerzo técnico necesario para implementar cada historia, a menudo utilizando técnicas como los "puntos de historia" o "días ideales".
- Cálculo de Prioridad: La prioridad se determina combinando el valor de negocio con el esfuerzo. Las historias con una alta relación valor/esfuerzo son las que se priorizan primero.
- Revisión Continua: La lista de historias (backlog) se revisa y reprioriza constantemente, ya que el valor de negocio y las necesidades pueden cambiar a lo largo del proyecto.
Esta priorización colaborativa asegura que el equipo siempre esté enfocado en entregar lo más importante para el cliente.
5.3. Ejemplo de historia de usuario
Para ilustrar cómo se redacta una historia de usuario y sus criterios de aceptación, consideremos el siguiente ejemplo para una aplicación de gestión de tareas:
Historia de Usuario:
Como usuario registrado,
quiero poder crear una nueva tarea,
para poder organizar mis actividades pendientes.
Criterios de Aceptación:
- El usuario debe estar autenticado para crear una tarea.
- La tarea debe tener un título (obligatorio, máximo 100 caracteres).
- La tarea puede tener una descripción (opcional, máximo 500 caracteres).
- La tarea puede tener una fecha de vencimiento (opcional).
- Al crear la tarea, esta se muestra en la lista de tareas pendientes del usuario.
- El sistema debe notificar al usuario si la creación de la tarea fue exitosa o si hubo algún error.
Estos criterios son la base para que los desarrolladores implementen la funcionalidad y para que los testers verifiquen su correcto funcionamiento.
5.4. Iteraciones cortas y entregas frecuentes
Las historias de usuario están intrínsecamente ligadas a las iteraciones cortas y las entregas frecuentes en XP. Una historia de usuario debe ser lo suficientemente pequeña como para poder ser implementada y probada dentro de una única iteración (generalmente de 1 a 3 semanas).
- Iteraciones Cortas: Permiten al equipo enfocarse en un conjunto limitado de historias de usuario, completarlas y obtener feedback rápidamente.
- Entregas Frecuentes: Al final de cada iteración, o incluso más a menudo, se entrega software funcional al cliente. Esto permite que el cliente vea el progreso real, pruebe las funcionalidades implementadas y proporcione feedback temprano.
Este ciclo continuo de "planificar, implementar, probar, entregar y obtener feedback" impulsado por las historias de usuario, es lo que permite a XP ser altamente adaptable y responder eficazmente a los cambios.