Escribir historias de usuarios para definir el trabajo del equipo

En mucho métodos ágiles, una de las herramientas clave para comunicarse entre el propietario del producto (el cliente) y el equipo de desarrollo es la historia del usuario. Martin Fowler y Kent Beck definen una historia de usuario como "un pedazo de funcionalidad que es de valor para el cliente. Cuanto más corta sea la historia, mejor. La historia representa un concepto y no una especificación detallada. Una historia de usuario no es más que un acuerdo en el que el cliente y los desarrolladores conversarán sobre una función ".


Ejemplos de historias de usuario bien escritas:

En general, las historias de los usuarios se escriben desde la perspectiva de las personas para las que se está desarrollando su proyecto.

En términos simples y concisos, una historia de usuario describe lo que la persona necesita. Cualquiera que lea la historia del usuario debe ser capaz de entender qué se requiere para implementar la historia. La definición de la historia establece por qué la persona necesita la funcionalidad. Esta declaración ayuda al equipo de desarrollo a comprender cómo usará el usuario la función y cómo medir si se cumple el objetivo.

Las historias de usuario deben tener criterios de aceptación y una definición de hecho: Los criterios de aceptación son el conjunto de requisitos que se deben cumplir para que se complete una historia de usuario. La definición de hecho es un conjunto de criterios que es común en las historias de usuarios relacionadas que deben cumplirse para cerrar las historias.

Por ejemplo, cada historia debe tener casos de prueba automatizados que validen los requisitos funcionales y no funcionales. Los criterios de aceptación y una definición de hecho proporcionan una visión clara para todo el equipo de las condiciones que deben cumplirse para declarar que la historia del usuario está "hecha".

Para aprender cómo ayudar a su equipo a escribir buenas historias de usuarios, revise el siguiente ejemplo de historias de usuarios mal escritas y vea cómo se pueden mejorar.

Bob es un desarrollador web. Necesita conocer las áreas de su sitio web a las que no se accede para que pueda mejorar el sitio web.
Mala historia: Bob necesita un informe sobre el uso del sitio web.
Esta historia es demasiado general. Un desarrollador no sabría qué implementar. La historia no indica por qué Bob necesita el informe. Debido a que esa información está excluida, el equipo de desarrollo puede escribir funciones que no cumplan con los requisitos de Bob.
Buena historia: como desarrollador web, Bob necesita un informe que muestre las estadísticas de uso de cada página de su sitio web para que pueda determinar qué páginas no se visitan con frecuencia y realizar mejoras.

 

Administrar historias de usuarios

Después de aprender a escribir buenas historias de usuario, necesita un lugar para rastrearlas y administrarlas. Almacene historias de usuarios en un sistema de seguimiento de funciones, como GitHub Issues, para que su equipo pueda clasificar las historias y rastrearlas hasta que finalicen.

Ninguna herramienta puede reemplazar la comunicación de humano a humano. No permita que la herramienta afecte la comunicación y se convierta solo en un sistema humano-a-sistema. Las personas deben hablar entre ellas y recordar que las historias son marcadores de posición para una comunicación más profunda.

A medida que aumentan las historias de usuarios, el equipo debe comunicarse con las partes interesadas, tanto los arquitectos como los clientes que desean la historia del usuario, para garantizar que, cuando se entregue, satisfaga los requisitos de las partes interesadas. Su equipo puede almacenar los resultados de las comunicaciones de las partes interesadas en el sistema de seguimiento para que toda la información necesaria para diseñar, implementar, probar y entregar la historia del usuario esté en un solo lugar.

 

Las historias de usuario deben cubrir más de lo que hace el producto

Un conjunto completo de historias de usuarios a menudo se olvidan en el proceso de inicio. Esas historias de usuario son las que están "en el medio" de las acciones obvias. Las historias de usuario sobre las facetas no funcionales son necesarias para deleitar al usuario, como la disponibilidad, el rendimiento y la seguridad.