Historias de Usuario

Las historias de usuario no son documentos de requisitos. Son marcadores de posición para conversaciones.

Ron Jeffries capturó esto como las "3 C":

Tarjeta: Una descripción breve que cabe en una tarjeta índice. "Como usuario, quiero restablecer mi contraseña para poder recuperar el acceso a mi cuenta."

Conversación: El diálogo entre desarrolladores y clientes que desarrolla los detalles. ¿Qué significa "restablecer"? ¿Enlace por correo electrónico? ¿Código SMS? ¿Preguntas de seguridad?

Confirmación: Los criterios de aceptación que te dicen cuándo la historia está terminada. "Dado un correo electrónico válido, cuando hago clic en 'restablecer contraseña', entonces recibo un correo electrónico con un enlace de restablecimiento en 1 minuto."

La tarjeta no es el requisito. La conversación es el requisito. La tarjeta es solo un recordatorio para tener la conversación.

El formato clásico de historia es:

Como [tipo de usuario] Quiero [alguna capacidad] Para que [valor de negocio]

Por ejemplo:

• Como comprador, quiero filtrar productos por precio para que pueda encontrar artículos dentro de mi presupuesto.
• Como administrador, quiero exportar datos de usuarios a CSV para que pueda analizar tendencias en Excel.
• Como invitado, quiero pagar sin crear una cuenta para que pueda comprar rápidamente.

La cláusula "para que" es crucial. Explica por qué la funcionalidad importa. Esto ayuda a los desarrolladores a tomar buenas decisiones sobre la implementación y ayuda a los propietarios de producto a priorizar.

Malas historias omiten el por qué:

• "Como usuario, quiero un botón azul." (¿Por qué? ¿Qué hace?)
• "Implementar funcionalidad de búsqueda." (¿Para quién? ¿Qué valor?)

Buenas historias conectan funcionalidades con valor:

• "Como cliente recurrente, quiero volver a pedir mi última compra para que pueda comprar de nuevo sin buscar."

El acrónimo INVEST describe las cualidades de las buenas historias:

Independiente: Las historias pueden desarrollarse en cualquier orden. Sin dependencias entre historias.

Negociable: El alcance es flexible. Los detalles se negocian a través de la conversación.

Valiosa: Cada historia entrega valor a los usuarios. No hay "historias técnicas" sin beneficio para el usuario.

Estimable: El equipo puede estimar qué tan grande es. Si no, la historia necesita aclaración o división.

Pequeña: Una historia debe tomar menos de una semana de trabajo. Idealmente unos pocos días.

Comprobable: Hay criterios de aceptación claros. Puedes verificar cuándo está terminada.

Cuando una historia viola INVEST, corrígela:

• Historias dependientes: Combínalas o rompe la dependencia
• Historias grandes: Divide en piezas más pequeñas
• Historias no estimables: Haz un spike primero para reducir la incertidumbre
• Historias no comprobables: Aclara los criterios de aceptación

Las historias grandes necesitan dividirse. ¿Pero cómo?

Dividir por paso del flujo de trabajo: "El usuario puede completar el pago" →

• El usuario puede agregar artículos al carrito
• El usuario puede ingresar dirección de envío
• El usuario puede ingresar información de pago
• El usuario puede confirmar y realizar el pedido

Dividir por variación de datos: "El usuario puede pagar el pedido" →

• El usuario puede pagar con tarjeta de crédito
• El usuario puede pagar con PayPal
• El usuario puede pagar con tarjeta de regalo

Dividir por operación: "El usuario puede gestionar su perfil" →

• El usuario puede ver su perfil
• El usuario puede editar su nombre
• El usuario puede cambiar su correo electrónico
• El usuario puede eliminar su cuenta

Dividir por rendimiento: "La búsqueda devuelve resultados rápidamente" →

• La búsqueda devuelve resultados (cualquier velocidad)
• La búsqueda devuelve resultados en menos de 2 segundos

Cada historia dividida debe ser desplegable independientemente. Si no puedes desplegar soporte parcial de tarjeta de crédito (solo Visa, no Mastercard), eso sigue siendo una división: entregas valor incrementalmente.

Vale la pena repetirlo: las historias no son especificaciones.

Los documentos de requisitos tradicionales intentan especificar cada detalle por adelantado. Esto falla porque:

• No puedes conocer todos los detalles antes de empezar
• Los documentos escritos son interpretados de manera diferente por diferentes lectores
• Las especificaciones quedan desactualizadas a medida que cambia la comprensión
• Desalientan la conversación

Las historias abrazan la incertidumbre. La tarjeta captura la intención. La conversación completa los detalles justo a tiempo. La confirmación verifica la comprensión.

El cliente permanece involucrado durante todo el proceso. Cuando los desarrolladores tienen preguntas, le preguntan al cliente, no al documento. Esto mantiene al equipo alineado y se adapta al aprendizaje.

Las historias también fomentan diferir decisiones. No tienes que decidir cada caso extremo por adelantado. Maneja primero el camino principal. Cuando encuentres un caso extremo, ten una conversación entonces.

Este es el enfoque de XP para los requisitos: lo justo, justo a tiempo, a través de la conversación.