Cómo escribir historias de usuarios y por qué son cruciales para el desarrollo exitoso de aplicaciones

En este artículo, explicaremos qué son las Historias de usuarios, cómo construirlas correctamente y por qué debe tenerlas en cuenta, si desea desarrollar una aplicación móvil o web.

Escrito por Barbara Rogala y Cieszysława Tichonow

Esta publicación apareció en AndroidDev Digest # 185

Si desea desarrollar una aplicación móvil o web, User Stories lo ayudará a encontrar un terreno común con un equipo de desarrollo, especialmente si no tiene habilidades de programación y no conoce el lenguaje técnico. Podemos decir que, gracias a User Stories, nuestra implementación de trabajo está mejor preparada y, en algunos casos, el desarrollo puede ser más rápido.

En resumen, Historias de usuarios:

elimine puentes entre los equipos comerciales y técnicos,
  ayuda con la comprensión del producto,
  involucrar a los usuarios de aplicaciones en el modelado de procesos

Pero, ¿cómo podemos alcanzar este nivel y utilizar todas estas ventajas?

En este artículo, intentaremos responder a esa pregunta y explicarle por qué usar User Stories es tan eficiente y valioso desde el punto de vista comercial.

¿Qué es exactamente una historia de usuario?

Una historia de usuario es una descripción de la funcionalidad de una aplicación y debe ser comprensible para todos los involucrados en el proceso de desarrollo del producto, tanto para desarrolladores como para miembros no técnicos del equipo.

Una historia de usuario generalmente consta de un resumen y una descripción. En este artículo, nos centraremos en el Resumen porque es la parte crucial de la Historia del usuario, que en su mayoría se subestima y es difícil de formular.

6 atributos de una buena historia de usuario

Una buena historia de usuario se puede describir a través de seis atributos (INVEST by Bill Wake):

  • Independiente: esto significa que debemos evitar las dependencias entre User Stories tanto como sea posible. Es mejor crear una historia más grande que una con dependencias, lo que puede causar problemas con la estimación y la priorización.
  • Negociable: las historias no son descripciones fijas de funcionalidades y deben contener en su descripción solo información breve sobre las especificaciones básicas. Si se requiere más información, un equipo de desarrollo debe comenzar una discusión con el Propietario del producto.
  • Valioso: los usuarios del software o el propietario del producto (cliente) deben valorar las historias. Gracias a esta dirección, el propietario del producto puede manejar fácilmente la priorización y la programación.
  • Estimable: en la mayoría de los casos, una historia de usuario no es estimable cuando es demasiado grande, no se describe bien o los desarrolladores no tienen el conocimiento suficiente para hacerlo. En todos estos casos, el equipo debe resolver el problema y tratar de preparar la historia para su estimación.
  • Pequeño: el tamaño adecuado de una historia de usuario se basa en el equipo, su conocimiento, las tecnologías que se utilizan y el tipo de proyecto.
  • Comprobable: las historias deben definirse como una parte comprobable de un sistema de trabajo; si una historia ha superado sus pruebas, demuestra que se ha desarrollado con éxito.

Para lograr todos estos puntos, todo el equipo debe trabajar en conjunto y discutir cada historia de usuario sobre reuniones de refinamiento durante Sprints.

Gracias a este enfoque, el alcance del proyecto será claro para todos, lo que seguramente tendrá un impacto en la calidad del proceso de desarrollo.

Plantilla de historia de usuario

Es claramente visible quién es un actor, cómo interactúa con los componentes del sistema y por qué o dónde tiene lugar la interacción. Usar este patrón y recordar estos tres elementos nos permite escribir historias simples y entendibles cada vez y generalmente para cada caso.

Ponte a prueba ¿Qué historia de usuario es correcta?

Ya conocemos las reglas y sabemos qué tipo de criterios debe seguir una buena historia de usuario. Entonces, eche un vistazo a dos ejemplos de cómo se ven las buenas y malas historias de usuario.

Digamos que nos gustaría escribir una historia de usuario perfecta usando un ejemplo de Instagram.

Historia de usuario de Instagram // Ejemplo 1:

Historia de usuario de Instagram // Ejemplo 1

Intenta adivinar cuál de estas dos opciones sería mejor:
 Los datos personales del usuario pueden ser editados por un usuario o el usuario edita su perfil para actualizar sus datos personales.

De un vistazo, la primera historia parece ser lo suficientemente buena. Pero, ¿sabemos por qué / para qué / desde dónde la acción de editar datos debe estar disponible en Instagram? Recuerde que, a veces, es obvio para un autor, aunque no podemos estar seguros de que alguien que trabaje en él lo entienda también.

Entonces, veamos por qué, en esta versión, cuando un Usuario edita su perfil para actualizar sus datos personales, es mejor. Sabemos quién está haciendo (usuario), qué (edita su perfil) y por qué (para actualizar sus datos personales).

Historia de usuario de Instagram // Ejemplo 2

Historia de usuario de Instagram // Ejemplo 2

Podemos comenzar con una historia donde la aplicación debería permitir a los usuarios agregar historias. ¿Ves qué partes de un buen patrón de historia de usuario faltan aquí?

¿Cómo debería ser la versión correcta? Comparémoslo con el ejemplo cuando un Usuario agrega historias a su perfil desde la pestaña de perfil para mostrárselo a sus amigos.

La tabla muestra qué partes faltan en la primera historia de usuario. Sin Quién y Por qué / Para qué / Desde dónde, la acción es completamente ininteligible.

En base a estas dos comparaciones, podemos aprender a reconocer un buen patrón, lo que ayudará a nuestros equipos a construir un producto que coincida con las expectativas del propietario del producto.

8 grandes ventajas de User Stories para su negocio

Mike Cohn escribió sobre 8 grandes ventajas de User Stories en su libro, que muestra perfectamente por qué son valiosas para los negocios:

  1. Las historias de usuario enfatizan la comunicación verbal: en lugar de escribir una descripción o documentación extremadamente detallada para cada requisito, el propietario del producto debe estar en contacto con el equipo de desarrollo. La forma de Historias de usuarios obliga a ambas partes a comunicarse y hacer que el ciclo de retroalimentación sea lo más corto posible. Solo de esta manera obtendrás lo que quieres; en el caso contrario, probablemente solo sea la interpretación del desarrollador del documento escrito.
  2. Las historias de usuario son comprensibles para todos: al contrario de los requisitos técnicos detallados, una buena historia de usuario es clara para los desarrolladores y las personas de negocios, lo que ayuda a implementar el software adecuado.
  3. Las Historias de usuarios son del tamaño adecuado para la planificación: la planificación del lanzamiento, la previsión de riesgos y la priorización son procesos claros cuando los requisitos son del tamaño correcto y no se combinan demasiado con otras partes del software, tanto para desarrolladores como para clientes.
  4. Las historias de usuarios funcionan para el desarrollo iterativo: no es necesario tener una lista completa de historias de usuarios al comienzo del proyecto. El equipo puede comenzar con algunos de ellos y agregar otros nuevos durante el proceso de desarrollo a través de las próximas reuniones de Refinamiento. Esta ventaja es especialmente compatible con productos que no se conocen bien al principio y que se cambiarán a menudo durante el desarrollo.
  5. Las Historias de usuarios fomentan los detalles diferidos: las historias se pueden escribir durante todo el proyecto, por lo que, como Propietario del producto, puede agregar una epopeya más grande cuando lo desee y luego, en cooperación con los desarrolladores, puede describirla fácilmente o dividirla más tarde.
  6. Las Historias de usuarios respaldan el diseño oportunista: el software debe desarrollarse de manera oportunista, porque la mayoría de las veces nuestro producto cambia durante el proceso de implementación y somos incapaces de recordar tantos detalles y predecir todos los posibles problemas o dependencias.
  7. Las Historias de usuarios fomentan el diseño participativo: las Historias de usuarios ayudan a involucrar a usuarios reales en el proceso y le permite reaccionar rápidamente a sus necesidades o expectativas.
  8. Las historias de usuarios acumulan conocimiento tácito: el conocimiento se acumula dentro del equipo, no solo del propietario del producto.

La experiencia nos muestra que la parte más importante del proceso de desarrollo de aplicaciones móviles es una buena comprensión de las necesidades del cliente y los valores reales, que respaldan las ideas que deben implementarse.

Esto solo es posible cuando los desarrolladores y el Propietario del producto usan el mismo método para describir las funcionalidades del software y, como escribí anteriormente, las Historias de usuarios hacen que esto suceda.

Envolver

Las historias de usuario son universales y podemos usarlas en cualquier tipo de proyectos, incluidos los procesos de desarrollo de aplicaciones móviles y web. Preparados adecuadamente, pueden ser de gran ayuda para el equipo y los propietarios del producto.

Si desea profundizar en el tema, le recomendamos encarecidamente el libro de Mike Cohn "Historias de usuarios aplicadas", que está lleno de casos de ejemplo, explicaciones y buenas conclusiones sobre Historias de usuarios.

Ahora es el momento de verificar tus nuevos conocimientos en la vida real

Háganos saber si tiene alguna otra idea cuando se trata de crear una buena historia de usuario. Solo déjanos un comentario sobre el artículo.

Publicado originalmente en iOS y Android Mobile App Development Company - Droids On Roids - Polonia.