Después de examinar y analizar más de 10.000 historias de usuarios de diferentes fuentes, hemos obtenido una idea de lo que representa una buena historia de usuario. Si a ti te gustaría aprender a escribir mejores historias de usuario, este artículo debería resultarle útil.
¿Qué es una historia de usuario?
Antes de comenzar con los 10 pasos, revisemos la cuestión de qué es una historia de usuario. Una historia de usuario normalmente se describe como un marcador de posición para una conversación sobre la necesidad de un usuario. Normalmente nos referimos a las tres C: Tarjeta, Conversación y Colaboración. Sin embargo, en muchas organizaciones, las historias de los usuarios SON la lista de requisitos.
Los puristas y entrenadores ágiles suelen decir que la historia del usuario no debe considerarse un sustituto de los requisitos escritos, ya que esto socava la promoción de la colaboración entre los miembros del equipo. Sin embargo, en la mayoría de los casos En la mayoría de las organizaciones, la lista de historias de usuarios es la lista de requisitos..
Y ahora, cubramos 10 pasos para escribir mejores historias de usuarios:
1. Centrarse en las necesidades funcionales
La funcionalidad debe escribirse de la siguiente manera, siempre que sea posible: Como __ necesito __ . En cada historia, incluye todas las funcionalidades que la hacen completa. Incluir movimientos de datos entre sistemas (siempre que su alcance sea agregar, editar o eliminar dicha funcionalidad). Una historia de usuario que comienza con "Cuando" en lugar de "Como" está bien siempre que describa un evento funcional que incluya un usuario, un objeto y una acción. por ejemplo, “cuando el sensor de temperatura detecta 100 grados envía una señal para desactivar la fuente de calor”
Excluya las tareas de equipo y cualquier trabajo de configuración que no esté directamente relacionado con la entrega de funciones nuevas, modificadas o eliminadas.
2. Claro e inequívoco
Si la historia de un usuario no está clara, generará errores. Esto es absolutamente crucial para resolverlo y resolverlo temprano. Debe ser inequívoco para los lectores previstos (al menos: usuarios, desarrolladores, evaluadores, analistas, diseñadores). La prueba fácil de la ambigüedad es garantizar que dos lectores del mismo texto comprendan de la misma manera qué funcionalidad se debe proporcionar; en caso de duda, pregúnteles.
Utilice verbos relacionados con datos como actualizar, enviar o ahorrar. Evite verbos como: considerar, proporcionar, querer, decidir, apoyar y evaluar . Es probable que esto engañe al lector.
3. Valioso y rastreable hasta los resultados comerciales
Este es, en muchos aspectos, el atributo más importante de una historia de usuario. Si la historia no es útil para la empresa, entonces debe excluirse. Idealmente, el valor de la historia puede vincularse directamente a Capacidades y Resultados que sean medibles. es decir, existe una trazabilidad clara entre la funcionalidad de la historia del usuario y la capacidad que se necesita para lograr el negocio medible. resultado.
4. Desde la perspectiva del usuario
Centrarse en la experiencia del usuario específico de la aplicación. También trate de ser específico sobre el tipo y contexto del usuario. Por ejemplo, en lugar de "como usuario", intenta dar contexto dentro de tus nombres de usuario, por ejemplo: loggedin_customer, loggedin_marketing_agent. loggedin_adminstrator. Esto es informativo sobre el contexto sin ser prolijo.
5. Conciso
Las historias de usuarios demasiado detalladas que incluyen demasiados detalles de las necesidades funcionales, declaraciones de diseño y criterios de prueba generarán confusión. Mantenga sus historias breve, simple y preciso. Es mejor ser breve y claro que especificar demasiado.
Intente que sus historias de usuario sean pequeñas y simples, pero lo suficientemente amplias como para evitar la proliferación de historias. Dos consejos específicos son hacer referencia a objetos, no a tipos de objetos (demasiado grandes) ni a atributos de objetos (demasiado detallados). Por ejemplo "como cliente_loggedin puedo actualizar mi perfil” es mejor que "como cliente_loggedin puedo actualizar cualquier dato” o "Como cliente registrado puedo actualizar mi número de teléfono"
6. consistente
Sea consistente con su nombres de usuario y nombres de objetos.
Con los datos mantenidos dentro del sistema, sea coherente con los nombres que utiliza, trate de hacer referencia solo a objetos y tipos de objetos tanto como sea posible, evite los atributos de los objetos dentro de las historias. p.ej perfil del usuario (que incluye un atributo para la fecha de nacimiento) es mejor que fecha de nacimiento.
7. Completo dentro de sí mismo
Si una historia de usuario requiere varios pasos funcionales, inclúyalos todos. p.ej
Antes: Como usuario quiero actualizar los detalles de la tienda.
Después: Como administrador registrado, necesito verificar mi permiso [para actualizar store_record]. Luego puedo actualizar store_record
Las dos declaraciones funcionales indican que es necesario verificar los permisos antes de poder realizar una actualización.
8. CRUD completo y sin duplicar en un conjunto
Si estamos actualizando almacenar información En el ejemplo anterior, ¿existe también una historia de usuario similar que nos permita crear una tienda? ¿Otra historia para Eliminar una tienda? ¿Y otra historia para exhibir una tienda? Las historias que faltan son la causa de la variación del alcance, que a menudo hace que los proyectos avancen más allá de su cronograma original.
Del mismo modo, tenga cuidado con las historias de usuarios duplicadas. Los requisitos duplicados son menos comunes, pero ocurren, así que verifique que no haya duplicado la funcionalidad.
9. Comprobable
Si un lector no puede entender fácilmente cómo probar la historia del usuario, entonces no se puede probar. Nos referimos aquí a las pruebas desde un punto de vista funcional. Se deben incluir todas las restricciones y se deben cuantificar las restricciones escalares.
10. No contiene ningún diseño.
Las historias de usuario no deben contener declaraciones de diseño.
Conclusión
Estos son 10 de mis consejos favoritos para escribir mejores historias de usuarios. Te garantizo que si sigues estos consejos escribirás mejores historias de usuario, y eso te llevará a escribir mejor software.
¿Qué pasa si mis historias de usuario no son buenas? ¿Importa, siempre y cuando tenga la esencia de la historia? Sí lo hace. Una sola ambigüedad conducirá a una pérdida de tiempo y esfuerzo en interpretación, mala interpretación y cierto grado de reelaboración. Una omisión podría requerir una revisión importante del diseño (o introducir deuda técnica si ya es demasiado tarde para cambiar el diseño). Entonces sí, se justifica tener mucho cuidado al escribir historias o requisitos de usuarios. Unos buenos requisitos pueden conducir a una entrega a tiempo. Sin duda, unos requisitos deficientes costarán más y llevarán más tiempo.
Necesitar más
Mira este excelente ejemplo trabajado de mejorar una historia de usuario.
