Lección 11 de 19
En Progreso

3.2 Escribir historias de usuario

2 diciembre, 2022

Hemos hablado de temas y características como agrupaciones de trabajo

Estas son construcciones realmente útiles para ayudarnos a organizarnos, pero aún son demasiado grandes para que un equipo trabaje en ellas y brinde valor en plazos cortos. Las personas para las que estamos desarrollando son clientes o usuarios, cada interacción que tienen con nuestro producto es un caso de uso que le cuenta al equipo una historia sobre cómo van a usar nuestro producto.

Las llamamos “User Stories“, y este es el nivel de detalle que necesitamos para saber qué ofrecer. La historia del usuario, entonces, es el nivel táctico de trabajo que se puede entregar rápidamente. Al mismo tiempo, no son tan pequeños como para no ofrecer ningún valor.

Cualquiera en el equipo puede escribir historias de usuario, pero generalmente es el PO. Como parte interesada y representante del cliente, es su deber asegurarse de que todo lo que está pendiente agregue valor para el cliente. Entonces, generalmente escriben las historias de los usuarios

Al escribir historias de usuarios, es mejor usar el acrónimo de Bill Wakes INVEST como guía

  • Primero, las buenas historias de usuario son independientes. Se puede entregar por separado de otras historias y tener valor por sí mismo. Si solo tiene tiempo para hacer una cosa, esta historia puede ser independiente.
  • También son negociables, hasta que la historia se comprometa a trabajar, se puede reescribir, cambiar o cancelar en cualquier momento.
  • Las historias de usuario deben ser valiosas. Ofrece valor a la OP, las partes interesadas y los clientes. En pocas palabras, es significativo.
  • A continuación, también deben ser estimables. Debe poder estimar el tamaño de la historia en puntos de historia. Eso significa que la historia es lo suficientemente descriptiva, así que sabes lo que hay que hacer para terminarla. Solo entonces puedes entender el esfuerzo requerido.
  • Las historias de usuario también deben ser pequeñas. La historia es lo suficientemente pequeña como para completarse en un sprint y ser comprobable por última vez.
  • La historia proporciona suficiente información para que pueda desarrollar pruebas para ella.

Si bien esto parece mucho para lograr con una historia de usuario, tenemos un formato que nos ayuda a escribir buenas historias.

Este formato simple nos dice mucho. Al comprender de qué cliente estamos hablando, obtenemos una mejor comprensión de la necesidad y lo ayuda a concentrarse en una actividad dentro de nuestro producto, definiendo claramente la necesidad y, lo que es más importante, el beneficio esperado de ese requisito ayuda a desencadenar las conversaciones del equipo debe tener para tener claro lo que es valioso.

Usando nuestra aplicación móvil de pedidos de almuerzos, como ejemplo de una buena historia de usuario, podría ser;

Como cliente móvil, quiero crear un perfil para que los pedidos futuros sean más rápidos.

Esto se conoce como Historia de usuario funcional, lo que significa que cumple una función para el usuario final.

También escribirás historias no funcionales. Esas historias ayudan a respaldar la funcionalidad que necesitan los usuarios finales sin beneficiarlos directamente.

Aquí hay un ejemplo, como desarrollador, quiero actualizar el software de la base de datos a la última versión para que tengamos un producto compatible.

Ahora bien, no basta con tener buenas historias de usuario

Cada uno también debe tener criterios de aceptación o “CA”. El “CA” es la herramienta más poderosa que tiene el equipo para reducir los errores al terminar una historia. Cada vez que se escribe una historia de usuario, el PO (Product owner o Dueño del producto) y el equipo colaboran para determinar el CA para la historia.

Entonces, cada historia tiene su propio CA único. En el caso de nuestra historia funcional sobre la creación de un perfil, el CA podría ser que el nombre del cliente se capture y guarde. A continuación, se captura y guarda la dirección de correo electrónico del cliente. También se captura y guarda el número de teléfono del cliente y se captura y guarda la contraseña del cliente.

CA adicional para esta historia garantizaría que se rechacen los números de teléfono, las direcciones y las contraseñas no válidos. Su CA debe ser lo más explícito posible. Para que todas las partes del equipo sepan lo que realmente es hecho por la historia. Las historias de usuario son las herramientas tácticas que utilizan los equipos de scrum para entregar el trabajo de su producto.

Escribir buenas historias de usuarios puede ser un desafío, pero con la práctica, cada vez es más fácil.