En este tutorial, aprenderás sobre una parte importante del enfoque ágil para el desarrollo de software: las historias de usuario.

Te guiaré a través de qué son las historias de usuario, las trampas comunes que he visto al crear historias de usuario y los marcos que existen para validar si tu historia de usuario es “buena”.

Aquí está lo que cubriremos:

Los Comienzos de Agile

Es probable que hayas oído hablar del Desarrollo Ágil y las Historias de Usuario. Pero si no lo has hecho, tengamos una breve lección de historia:

Las Historias de Usuario son parte de un concepto más amplio llamado metodologías Ágiles.

Las metodologías Ágiles existen desde 2001, cuando 17 ingenieros de software muy respetados se reunieron en una estación de esquí en Utah y crearon el ahora famoso Manifiesto Ágil.

Si nombres como Robert Martin, Martin Fowler y Kent Beck no significan nada para ti, una vez que hayas terminado este artículo, búscalos. Tienen una gran cantidad de conocimiento y, entre ellos, le dieron al mundo del software una forma más fluida de entregar proyectos, llamada Agile.

¿Qué es Agile?

Agile es más una forma de pensar que un método prescrito. Existen métodos prescritos, como Scrum y Kanban, pero Agile es un concepto.

Agile promueve la colaboración, la retroalimentación rápida y la entrega de valor frecuentemente al usuario.

La forma de pensar Ágil fomenta la flexibilidad en la planificación de proyectos, lo que contrasta marcadamente con su competidor de la época, la planificación de proyectos en Cascada, que era muy rígida en cuanto a lo que se entregaba y cuándo.

Las metodologías ágiles promueven realizar “lo justo necesario” en investigación al inicio para comenzar el proyecto, y luego aprender, iterar y cambiar el diseño y el entregable según sea necesario a lo largo del proyecto hasta que se entregue el código final. Este enfoque de “cambiar y aprender sobre la marcha” se llama “planificación adaptativa”.

Agile promueve entregar algo de valor de manera rápida y frecuente, generalmente en forma de entrega de código a producción al final de cada “sprint” de dos semanas. Esto, nuevamente, es muy diferente de la planificación tradicional en cascada, que a menudo requeriría meses de desarrollo antes de que cualquier cambio visible para el usuario pudiera ser entregado a producción.

Otra parte clave de Agile es el enfoque que pone en los interesados trabajando juntos de manera cercana y frecuente. Producto, QA, Ingeniería y Ventas tienen una gran aportación y retroalimentación constante sobre el proyecto a lo largo de su ciclo de vida.

Ahora que sabes un poco más sobre cómo funciona Agile, profundicemos en cómo validamos el valor para el usuario.

Entramos en la Historia de Usuario.

¿Qué es una Historia de Usuario?

Una historia de usuario es una manera en lenguaje sencillo de conectar al ingeniero con el objetivo final del software.

Está diseñada para que una persona no técnica pueda leerla y entender lo que se está entregando, y para que un ingeniero pueda mirarla y ver el valor y cómo validar que has entregado ese valor.

Estructura de una Historia de Usuario

Como [tipo de usuario], cuando [realizo acción], [resultado esperado]

En su forma más básica, eso es todo.

Estás poniendo el énfasis en el usuario final y el “valor” que entregarás.

Vamos a profundizar en las entradas:

  • Tipo de usuario: No hay un “usuario” que sirva para todos. Tienes “usuarios administradores”, tienes “usuarios registrados”, tienes “usuarios con permiso X” o “usuarios en el rol Y”. Esto es ser específico sobre quién está realizando la acción

  • Realizar acción: ¿Qué está haciendo el usuario? ¿Haciendo clic en el botón “iniciar sesión”? ¿Eliminando un registro? ¿Enviando un formulario?

  • Resultado esperado: Una vez que tu usuario ha realizado la acción, ¿qué debería pasar? Si han hecho clic en “iniciar sesión” con la dirección de correo electrónico y la contraseña correctas, ¿a dónde deberían ser dirigidos? Si han hecho clic en “iniciar sesión” con una dirección de correo electrónico y contraseña incorrectas, ¿qué debería pasar?

Ejemplo de Historias de Usuario:

Veamos ejemplos de historias de usuario para una página de inicio de sesión.

No hay nada mejor que ejemplos.

Establezcamos el escenario. Tienes una página de inicio de sesión con un cuadro de texto para ingresar una dirección de correo electrónico y un cuadro de texto para ingresar una contraseña. Tienes un botón de enviar. Eso es todo.

¿Cuáles son las diferentes permutaciones que pueden ocurrir en esta página desde la perspectiva del usuario?

Como usuario autenticado, cuando se carga la página, soy redirigido a la página de inicio de sesión.

Si ya estoy autenticado, no quiero tener que volver a ingresar mis datos, solo redirígeme a la página de inicio de sesión.

Como usuario no autenticado, cuando ingreso la dirección de correo electrónico correcta pero la contraseña incorrecta y hago clic en Iniciar sesión, aparece un mensaje de error.

Soy un usuario que no está autenticado, y he ingresado los datos incorrectos. No debería estar autenticado.

Como usuario no autenticado, cuando ingreso una dirección de correo electrónico y una contraseña incorrectas y hago clic en iniciar sesión, aparece un mensaje de error.

De nuevo. No soy un usuario autenticado. He ingresado datos incorrectos, no debería estar autenticado.

Como usuario no autenticado, cuando ingreso la dirección de correo electrónico y la contraseña correctas y hago clic en iniciar sesión, soy redirigido a la página de inicio de sesión.

Esta vez, no estoy autenticado, ingreso los datos correctos y hago clic en iniciar sesión. Estoy autenticado en el sistema.

¿Puedes ver cómo todos estos se centran en el usuario?

Puede que notes que algunos de los “comportamientos esperados” en lo anterior no están completamente definidos. Abordaremos eso más adelante en los criterios de aceptación.

Cómo hacer buenas Historias de Usuario

Hay un buen modelo llamado el modelo INVEST que muestra de manera muy simple cómo saber si tus historias de usuario son buenas.

Modelo INVEST:

  • Independiente: Puede desarrollarse por separado.

  • Negociable: Abierto a discusión y cambio.

  • Valioso: Ofrece valor al usuario.

  • Estimable: Puede ser estimado en esfuerzo.

  • Small: Se ajusta dentro de un sprint.

  • Testable: Tiene criterios de aceptación claros.

Apliquemos este modelo INVEST a uno de los ejemplos de historias de usuario mencionados anteriormente:

Como un usuario no registrado, cuando ingreso la dirección de correo electrónico y la contraseña correctas y hago clic en iniciar sesión, soy redirigido a la página de inicio de sesión.

(Voy a hacer algunas suposiciones aquí, ya que esta es una base de código teórica y un proyecto teórico)

¿Es esta historia independiente? Yo diría que sí. Es una historia pequeña que involucra solo unos pocos componentes que probablemente ya existen. Sin embargo, si la base de datos aún no se ha creado para el proyecto, eso nos daría una dependencia. Esto ya no sería independiente.

¿Es negociable? Bueno, de nuevo, sí. Esta historia podría cambiarse fácilmente para redirigir a la página de perfil del usuario en lugar de su página de inicio.

Esta historia es definitivamente valiosa. Una vez implementada, el usuario puede iniciar sesión. Si la historia fuera:

Como usuario no registrado, cuando ingreso la dirección de correo electrónico y la contraseña correctas y hago clic en iniciar sesión, no sucede nada

Esto no sería valioso. El usuario no obtendría nada de esto.

¿Es la historia estimable? De nuevo, tenemos que hacer algunas suposiciones en este escenario inventado, pero ciertamente espero que esto sea fácilmente estimado. Es una historia concisa, que involucra pocos componentes, en un dominio que todos conocen y tiene criterios de aceptación claros.

La historia es ciertamente pequeña. Hay poca ambigüedad en lo que se necesita hacer, hay un solo camino del usuario y resultados claros. Echemos un vistazo a una historia que sería demasiado grande:

Como usuario no registrado, la página de inicio de sesión debería funcionar como se espera.

Como se discutió más arriba en este artículo, hay muchas maneras en que la página de inicio de sesión puede y debe funcionar. “Debería funcionar como se espera” parece cubrir todas esas permutaciones. Esto sería demasiado grande para dimensionarse efectivamente como una historia y probablemente demasiado grande para completarse en un solo sprint.

La historia es definitivamente Comprobable. Hay acciones de usuario claras que tienen un resultado claro. Esta historia de usuario puede ser cubierta por Pruebas Unitarias, Pruebas de Integración y Pruebas Manuales.

¡Parece que hemos creado una buena historia de usuario!

Si utilizas la estructura que he definido arriba, y la historia cumple con los criterios del modelo INVEST, probablemente sea una buena historia.

Errores comunes en la creación de Historias de Usuario

He visto Historias de Usuario fallar en el pasado donde las personas han pasado por alto algunos aspectos cruciales de la historia de usuario:

Enfocándose en los aspectos técnicos

Como mis ejemplos muestran arriba, la historia de usuario es no técnica.

No debería haber referencia a un nombre de servicio, un nombre de base de datos, o validación basada en algo que el usuario no puede ver.

Tan pronto como tu historia ya no pueda ser entendida por el usuario final, te has equivocado.

Enfócate en lo que el usuario va a hacer y en lo que el usuario va a ver.

Veamos un ejemplo de una historia enfocada técnicamente:

Como usuario no registrado, cuando hago clic en el enlace de contraseña olvidada con una dirección de correo electrónico correcta, se registra un registro en una tabla de base de datos indicando que se ha enviado el enlace para restablecer la contraseña.

Esta historia no puede ser verificada por un usuario y los usuarios no técnicos pueden no entender lo que significa.

Arreglémoslo:

Como usuario no registrado, cuando hago clic en el enlace de contraseña olvidada con una dirección de correo electrónico correcta, se envía un correo electrónico a la dirección proporcionada con un enlace para restablecer la contraseña.

Los usuarios no técnicos pueden entender esto y pone el enfoque en el usuario, no en el producto.

Colaboración de interesados

Agile es colaborativo.

Las historias de usuario necesitan la aportación de Producto, BA, QA, Ingenieros y, lo más importante, Usuarios.

Así es como asegurarás que estás entregando lo que el usuario quiere. Muchas manos hacen el trabajo ligero.

Si, por ejemplo, solo un equipo de ingeniería creara las historias de usuario, podrían verse algo así:

Como usuario registrado, cuando se carga la página, soy redirigido a la página de inicio de sesión

Como usuario no registrado, cuando ingreso la dirección de correo electrónico correcta pero la contraseña incorrecta y hago clic en Iniciar sesión, aparece un mensaje de error

Como usuario no registrado, cuando ingreso una dirección de correo electrónico y una contraseña incorrectas y hago clic en iniciar sesión, aparece un mensaje de error.

Y eso está bien. Pero ahora pongamos a QA involucrado, que viene desde una perspectiva diferente ya que tienen diferentes experiencias con el software:

Como usuario no registrado, cuando ingreso una dirección de correo electrónico correcta en hebreo y una contraseña correcta, soy redirigido a la página de inicio

Como usuario no registrado, cuando ingreso una dirección de correo electrónico y contraseña correctas y hago clic repetidamente en iniciar sesión, soy redirigido a la página de inicio

Genial. Ahora estamos obteniendo un conjunto más completo de historias de usuario que cubren más situaciones. Pero, ¿qué pasa si involucramos a Producto?

Como usuario no registrado, cuando se carga la página, mi gestor de contraseñas debería precargar mi nombre de usuario y contraseña, cuando hago clic en iniciar sesión, soy redirigido a la página de inicio

El equipo de Producto conoce a los usuarios. Saben que las personas realmente utilizan gestores de contraseñas. Debemos asegurarnos de que cuando el usuario no escribe nada (ya que el texto es cargado por el gestor de contraseñas), el inicio de sesión aún funcione correctamente.

Historias de Usuario Vagas

La idea detrás de una buena historia de usuario es que todos, independientemente de su experiencia, puedan entenderla.

Si has escrito una Historia de Usuario que puede ser interpretada de 10 maneras diferentes por 10 personas distintas, has cometido un error.

Mencioné anteriormente que tocaría el tema de los criterios de aceptación, y ahora es el momento de hacerlo.

Reexaminemos la siguiente Historia de Usuario:

Como un usuario no registrado, cuando ingreso una dirección de correo electrónico y una contraseña incorrectas y hago clic en iniciar sesión, aparece un mensaje de error.

Hay vaguedad en eso.

¿Qué mensaje debería aparecer? Cuando la página se recarga después de un intento de inicio de sesión inválido, ¿debería el cuadro de texto del nombre de usuario volver a estar vacío o pre-poblado con el valor ingresado previamente? ¿Qué significa “dirección de correo electrónico incorrecta”? ¿Una dirección de correo electrónico que nunca se ha visto antes, o una dirección de correo electrónico que no es válida en ese momento (no ha pagado la suscripción, suscripción cancelada, etc.)

Así que, como puedes ver, los detalles importan.

Esta Historia de Usuario es un ejemplo bastante fabricado y he logrado encontrar muchas preguntas al respecto.

Vamos a solucionar el problema:

Como un usuario no registrado, cuando ingreso una dirección de correo electrónico que no está registrada en el sistema, cuando hago clic en iniciar sesión, aparece un mensaje de error.

Eso eliminó las preguntas sobre la acción del usuario pero no resolvió el problema sobre el mensaje de error esperado.

Ingrese los criterios de aceptación.

Dentro de la historia de usuario, necesitas tener un conjunto de criterios de aceptación que defina si la implementación de la historia de usuario es la esperada.

Cosas como:

  • Mensaje de error: “Dirección de correo electrónico o contraseña inválida”

  • La casilla de texto de Dirección de Correo Electrónico y Contraseña se restablece a vacía al recargar

  • Usuario no puede acceder a páginas donde se requiere inicio de sesión

  • Se le presenta al usuario una sugerencia de “contraseña olvidada”.

Los criterios de aceptación establecen lo que se espera de la implementación.

Cómo comenzar con Historias de Usuario

Empieza pequeño.

No serás perfecto al refinar y crear historias de usuario al principio.

Crear historias de usuario es tanto un arte como una ciencia. La práctica hace al maestro.

La creación de Historias de Usuario debe hacerse en grupo. A menudo, esto se hace con el enfoque de los “3 Amigos”, donde un ingeniero, una persona de producto y un QA se sientan juntos y generan diferentes permutaciones que necesitas soportar.

Una vez que hayas entregado tu proyecto, reflexiona. Echa un vistazo atrás y ve qué brechas tienes en tus historias de usuario. Habrá errores que los usuarios encuentren, que el control de calidad (QA) y las pruebas de aceptación de usuario (UAT) encuentren, y estos se deben a brechas en tus historias de usuario o brechas en tus pruebas. De cualquier manera, deberías aprender de ellos para la próxima vez.

Conclusión

Ágil es colaborativo. Scrum es colaborativo. Crear Historias de Usuario es colaborativo. Recuerda eso.

Cuantas más personas de diferentes áreas de especialización tengas generando ideas para la creación de historias de usuario, más probable será que cubras el conjunto completo de flujos de trabajo.

El usuario es el enfoque. Si alguna vez estás incluyendo terminología que tu usuario no entiende, repensa la historia de usuario.

No serás perfecto en esto desde el principio, pero a medida que hagas más y más, más rápido y efectivo te volverás. Toma esto de alguien que ha estado haciendo esto durante más de 10 años. La diferencia en velocidad y calidad de mi creación de Historias de Usuario hoy en comparación con hace 10 años es un mundo aparte.

Consulta mis publicaciones en mi blog, Just Another Tech Lead, o suscríbete a mi boletín semanal por correo electrónico aquí.