¿Qué es una historia de usuario?
Según uno de los iniciador del movimiento Agile Alistair Cockburn, "Una tarjeta de historia es una promesa para una conversación". Específicamente, es una conversación con su cliente que da como resultado una descripción de una función de software desde su perspectiva. Esta es la base de una historia de usuario, una parte esencial del ciclo de vida del desarrollo de software Agile y Lean. Los temas, las iniciativas, las épicas y las historias son todos los bloques de construcción, desde grandes hasta pequeños, que ayudan a organizar la funcionalidad necesaria para crear una solución de software centrada en el usuario. Los términos pueden parecer familiares desde el punto de vista de la literatura, y con razón. Una historia de usuario es una narrativa simple, mientras que las historias relacionadas componen una épica. A continuación, le mostremos cómo funcionan juntos estos términos:
-
Temas: Un propósito ambicioso o un objetivo de alto nivel.
-
Iniciativa: Una colección de épicas que ayudarán a alcanzar el objetivo principal.
-
Épicas: Una necesidad empresarial de alto nivel o una gran historia de usuario. Son difíciles de implementar en una sola iteración, por lo que se dividen en historias más pequeñas. Toda una épica generalmente se incluye en una sola publicación.
-
Historias de usuario: requisitos cortos o escenarios de usuario que aportan algún valor y se escriben desde la perspectiva del usuario. Cada historia está limitada por un sprint o iteración.
A continuación se puede ver un ejemplo de esto:
El tema (a la izquierda) es el objetivo empresarial de alto nivel que se compone de iniciativas asociadas, épicas que apoyan esas iniciativas e historias (a la derecha) que describen los requisitos granulares.
Una organización de desarrollo de software puede tener el noble objetivo de modernizar su solución. Para lograr esta tarea, deben proporcionar una experiencia de usuario inolvidable. Por ejemplo, esa experiencia de usuario debe proporcionar una interfaz web moderna, realizar rápidamente y trabajar en una variedad de dispositivos de usuario. En este escenario, cada una de estas épicas se dividirá en historias de usuario específicas.
¿Qué es una historia de usuario épica?
Una épica es una necesidad empresarial de alto nivel o una gran historia de usuario. Las épicas son demasiado complejas para implementarlas en un solo sprint o iteración, por lo que se dividen en varias historias de usuario más pequeñas. El beneficio de las épicas es la capacidad de desarrollar y colaborar en ideas más grandes antes de crear numerosas historias de usuario. La épica se puede mantener como la idea original, creando un punto de referencia futuro.
¿Cuál es el propósito de una historia de usuario?
Una historia de usuario está destinada a ayudar en el desarrollo de una solución de software. Lamentablemente, no es raro desarrollar una solución de software que simplemente no atraiga a la base de clientes prevista. Las historias de usuario están destinadas a mitigar este riesgo al proporcionar una comprensión clara y exhaustiva de los requisitos de los usuarios finales que garantizan que las funciones de software cumplan con las expectativas.
¿Cómo utilizan las empresas historias de usuario?
Las historias de usuario son uno de los artefactos principales utilizados en el desarrollo de Agile. Se crean para describir las funciones y los requisitos funcionales y no funcionales y componen una lista priorizada de funcionalidad destinada al desarrollo. Esta lista se denomina actividades pendientes del producto.
Las historias de usuario se convierten en parte de un mapa de historias de usuario, un método que se utiliza para ordenar historias de usuario a lo largo de un eje horizontal y vertical para representar diferentes niveles de facilidad de uso. El eje horizontal se guía por las actividades que explican cómo interactúa el usuario con el sistema para realizar una función. El eje vertical representa un aumento de los niveles de complejidad. La primera fila es una representación fundamental de la función. La siguiente fila agrega un poco más funcionalidad, y así sucesivamente. A cada historia de usuario se le asigna un punto de historia o una estimación teórica del esfuerzo o dificultad que se necesitará para desarrollar la funcionalidad. Muchas organizaciones utilizan herramientas automatizadas de asignación de historias. Las herramientas más populares son Jira, Rally by CA, StoriesOnBoard y FeatureMap.
Plantilla de mapa de historias de usuario
También puede usar esta plantilla para crear su propio mapa de historias. Puede completar la plantilla utilizando Microsoft Word o recrearla utilizando notas post-it que se adhieren a la pared. Ajuste la cantidad de cuadros según las necesidades de desarrollo de su organización.
¿Cuáles son las características de una historia de usuario?
Independientemente del marco Agile utilizado, la programación extrema (XP), Kanban, DAD (Entrega Agile disciplinada), DMD o Scrum, las historias de usuario son las mismas. La historia de usuario describe el tipo de usuario: La persona, la función que desea y el beneficio que espera experimentar de la función. Una historia de usuario sólida está escrita siguiendo la estructura de la razón de la función (RGB):
Como
La historia de usuario debe tener las siguientes cualidades:
-
Ser lo suficientemente completa como para demostrar el valor del usuario.
-
Centrarse en el usuario
-
Empezar con una épica.
-
Ser breve, sencilla y clara.
-
Contener archivos y documentación de soporte si es necesario.
-
Ser lo suficientemente completa como para demostrar el valor, pero lo suficientemente sencilla como para desarrollarse en una sola iteración.
-
Estar escrita en función de la opinión de todas las partes interesadas.
-
Ser flexible y negociable sin afectar otras historias o funciones.
-
Ser fácil de probar.
-
Incluir criterios de aceptación (condiciones de satisfacción) para los evaluadores.
Es posible que escuche los términos historias de usuario y los requisitos del sistema utilizados indistintamente. Tradicionalmente, el desarrollo en cascada utiliza los requisitos del sistema para definir cómo debe funcionar una solución de software. Entran en extensos detalles que incluyen riesgos, alcance y otras pautas específicas del desarrollo. Las historias de usuario, por otro lado, son simples, promueven el debate y apoyan la metodología de desarrollo Agile, que adopta la colaboración y el cambio.
Como se mencionó anteriormente, las historias de usuario deben ser simples pero completas. Por ejemplo, una buena historia de usuario podría leerse así:
Como cliente bancario, quiero poder depositar un cheque en línea, para que no tenga que visitar el banco.
A continuación, le mostramos un ejemplo de una historia de usuario que es demasiado detallada:
Como cliente del banco, quiero poder depositar un cheque en línea, ver e imprimir informes históricos de depósito para no tener que visitar el banco.
¿Qué es un punto de historia?
A cada historia de usuario se le asigna asociado un punto de historia, una medida del esfuerzo o dificultad requerida para desarrollarlo e implementarlo. Los equipos pueden usar números de un solo dígito (1, 2, 3), varios dígitos (100, 200, 300) o cualquier otro formato que elija. La relación es el factor importante. Por ejemplo, una historia asignada a 200 puntos de historia requerirá un doble de esfuerzo como 100 puntos de historia asignado.
¿Cuál es el criterio de aceptación del usuario?
Los criterios de aceptación, también conocidos como condiciones de satisfacción, garantizan que la solución de software satisfaga las necesidades de los usuarios o partes interesadas. Estos criterios pueden incluir requisitos de rendimiento, estándares, escenarios y reglas del comportamiento del sistema. El equipo de pruebas utiliza criterios de aceptación para verificar que el desarrollo esté completo. Una vez que se cumplen estos parámetros, se considera "terminada" la historia o la función.
Cómo escribir historias de usuario efectivas
Escribir sus primeras historias de usuario puede ser difícil, especialmente porque son la base de la funcionalidad de su producto. Las historias de usuario se desarrollan más comúnmente durante la etapa inicial de desarrollo y se utilizan en la planificación de iteraciones y sprints, pero se pueden crear en cualquier momento (al inicio, para proporcionar un alcance de todo el proyecto / solución; en construcción, para identificar nuevas historias, eliminar historias innecesarias y dividir historias en partes más pequeñas; transición) y agregarse al trabajo pendiente para la próxima iteración.
Los siguientes 10 consejos lo ayudarán a crear historias de usuario efectivas:
-
Ponga a los usuarios en primer lugar: El propósito de una historia de usuario es demostrar la funcionalidad desde la perspectiva de un usuario. Asegúrese de entrevistar o encuestar a los usuarios e incluir información objetiva definida por el usuario. En algunos casos, el usuario puede no ser una persona, sino un sistema.
-
Defina personas: Comprender a sus usuarios es un elemento esencial para escribir una historia de usuario. Cree personajes ficticios que representen a los usuarios finales objetivo (estos pueden incluir consumidores, compradores, compradores, compradores frecuentes, contadores, profesionales de Recursos Humanos). Los comportamientos de compra, los problemas que buscan resolver y los objetivos generales son piezas importantes de información que debe tener sobre su cliente ideal. Utilice estos nombres de personas en lugar de el rol de usuario genérico al escribir sus historias.
-
Colabore: Asegúrese de obtener todas las partes interesadas relevantes en una habitación para colaborar durante la creación de historias de usuario. La gestión de productos, los ingenieros/desarrolladores, los evaluadores, la atención al cliente, las ventas y el cliente deben estar representados.
-
Mantenga la simplicidad: Mantenga la historia sencilla y clara. Utilice una voz activa y céntrese solo en hechos importantes.
-
Empiece con Epics y Refine: Comience con una historia de usuario más amplia para comprender completamente la funcionalidad general y, luego, profundizar en los detalles de la función real. Cada paso de un proceso más amplio debe convertirse en una historia única. Este proceso le permite hacer que la historia se ajuste a un solo sprint o iteración.
-
Incluya criterios de aceptación: Escriba criterios de aceptación que definan lo que constituye "hecho" para esa historia en particular. Los criterios de aceptación son un colaborador perfecto para los casos de prueba que el equipo de pruebas utilizará para garantizar que la función esté lista para el usuario.
-
Empiece con notas posteriores o tarjetas de índice: Cuando las historias de usuario surgieron por primera vez como parte de la programación extrema (XP), se capturaron en tarjetas de índice simples. El uso de este método fomenta la colaboración y la discusión, la visibilidad y la transparencia, y es una manera fácil de mover las cosas y el guión gráfico en un entorno colaborativo.
-
Muestre historias de usuario en un área accesible: Hacer que la historia de usuario sea visible en un área abierta, como una pared o una pizarra, fomenta la colaboración en todo el proyecto de desarrollo. La visualización de la historia puede mejorarse con diagramas, prototipos, diagramas de flujo de trabajo, mapas de historias y bocetos.
-
Adopte comentarios: El desarrollo Agile adopta flexibilidad. Los comentarios le permiten perfeccionar la funcionalidad para asegurarse de que el producto entrega valor al usuario.
-
Incluya estimaciones de tiempo: El tiempo que se tarda en completar el desarrollo en función de una historia de usuario es importante para planificar iteraciones y publicaciones. Las estimaciones de tiempo pueden ayudar a asignar tareas y subtareas a los miembros del equipo.
Hay dos técnicas principales que pueden ayudarlo a escribir historias de usuario:
-
Tres C: Iniciada por Ron Jeffries en 2001, la fórmula de Tres C incluye una tarjeta o una nota post-it, una conversación entre los usuarios, desarrolladores, evaluadores y propietarios de productos sobre la función y la confirmación de que se ha cumplido el objetivo.
-
INVEST: Este criterio, introducido por Bill Wake en 2003 y popularizado por el libro de Mark Cohn, Historias de usuario aplicadas para el desarrollo de software Agile, evalúa el valor de una historia de usuario asegurando que sea independiente (puede desarrollarse en cualquier secuencia), negociable, valiosa (para un usuario o negocio), estimable(para completar), pequeña (diseño, prueba y código en una sola iteración) y comprobable.
Para obtener más información sobre cómo escribir una historia de usuario y obtener consejos y plantillas que lo ayudarán a empezar, lea Cómo escribir una historia de usuario en el desarrollo de software que realmente se centra en el usuario.
¿Quién escribe la historia de usuario?
No se trata necesariamente de quién escribe la historia de usuario, sino de quién está involucrado en el proceso de desarrollo de la historia de usuario. El objetivo es un debate colaborativo que da como resultado una historia de usuario. Gestión de productos, ingenieros / desarrollo, probadores, atención al cliente, ventas y, lo más importante, el cliente debe participar en el proceso. El gerente de productos o el propietario del producto suele ser el propietario de las historias de usuario a lo largo del ciclo de vida del desarrollo.
¿Cuál es la definición de hecho en Agile?
Cada equipo tendrá su propia definición de hecho o completo en el desarrollo de Agile, y esta definición puede variar en función de lo que se esté evaluando como completo: una historia de usuario, un sprint o una versión completa. Hay criterios que pueden ponerse en marcha para garantizar que una característica o función esté realmente completa. La lista de verificación de criterios puede incluir lo siguiente:
-
¿El código está escrito?
-
¿Se ha probado el código?
-
¿La función cumple con los criterios de aceptación?
-
¿La función se integra y funciona con la solución existente?
-
¿Se han actualizado las especificaciones técnicas del producto?
-
¿Se ha actualizado la documentación del producto?
¿Los casos de uso y las historias de usuario son lo mismo?
Los términos historia de usuario y caso de uso son similares, pero los casos de uso contienen mucho más detalles granulares en comparación con una historia de usuario. Una historia de usuario se escribe durante un debate colaborativo y representa la perspectiva de un usuario, incluye el objetivo del usuario y los criterios de aceptación.
¿Los casos de uso y las historias de usuario son lo mismo?
Los términos historia de usuario y caso de uso son similares, pero los casos de uso contienen mucho más detalles granulares en comparación con una historia de usuario. Una historia de usuario se escribe durante un debate colaborativo y representa la perspectiva de un usuario, incluye el objetivo del usuario y los criterios de aceptación.
Esta misma información se incluye en un caso de uso, pero el caso de uso va aún más profundo y describe los requisitos funcionales de la solución, incluidas todas las vías de interacción del usuario/sistema y los posibles riesgos. Muchos proyectos de desarrollo integrarán la creación de historias de usuario, la asignación de historias y los casos de uso para crear un producto completo y detallado.
Ejemplos de historias de usuario, beneficios y desafíos
Las historias de usuario suelen escribirse en función de los atributos funcionales. Por ejemplo, "Como cliente, quiero depositar un cheque por medios electrónicos, para evitar conducir al banco o cajero automático". Sin embargo, hay características no funcionales, o restricciones técnicas, que también son importantes. Con este mismo ejemplo bancario, las restricciones más técnicas pueden escribirse como siguientes: "Como cliente, quiero depositar 12 cheques en una sola transacción electrónica". Comprender los detalles específicos (que pueden parecer más técnicos) permite al equipo de desarrollo pensar en las restricciones que pueden tener que colocar en una historia de usuario abierta para que sea posible.
Las plantillas de historias de usuario y otras plantillas Agile están disponibles para descargar aquí.
Ventajas de la historia de usuario
Las historias de usuario son un elemento común del desarrollo de Agile, y usarlas correctamente proporciona grandes beneficios a aquellos que están desarrollando la solución y el cliente utilizando el software.
|
Beneficio del cliente |
Beneficio del proveedor de software |
|
Encuentre un mayor valor en la solución de software. |
Aumente la ventaja competitiva. |
|
Construya una relación positiva y colaborativa con el proveedor. |
Fomente la colaboración y la cooperación. |
|
Aumente la satisfacción. |
Impulse la transparencia. |
|
Elimine los detalles técnicos para incluir a los clientes y a las partes interesadas no técnicas. |
Reduzca el riesgo. |
|
Céntrese en las necesidades de los clientes. |
Aumente la satisfacción del cliente. |
|
Céntrese en el valor. |
|
|
Evite ajustes innecesarios de las actividades pendientes |
|
|
Elimine los detalles técnicos que puedan obstaculizar la colaboración. |
|
|
Desarrolle soluciones creativas. |
|
|
Respalde la flexibilidad del desarrollo De Agile. |
Desafíos de la historia de usuario
Al igual que con cualquier proyecto de negocios, hay desafíos que surgen. El libro Historias de usuario Aplicadas para Agile Software de Mike Cohn identifica el problema central en el desarrollo de software con esta sencilla observación: "Los requisitos de software son un problema de comunicación". El proceso de desarrollo de historias de usuario está destinado a remediar este desafío, pero el aumento de la comunicación puede resultarle tedioso a algunas partes interesadas internas. Desafíos de la historia de usuario
Otros desafíos incluyen los siguientes:
-
Garantizar que la historia de usuario sea lo suficientemente completa como para demostrar su valor, pero lo suficientemente sencilla como para desarrollarla en una sola iteración.
-
Centrarse en cómo crear e incluir detalles técnicos que no son innecesarios en esta etapa de desarrollo.
-
Las conversaciones y la colaboración pueden parecer lentas y abrumadoras.
Las historias de usuario ayudan a cambiar a las organizaciones de desarrollo de software de un enfoque revisado y basado en los requisitos para un enfoque colaborativo y centrado en el usuario. Son simples, sencillas y representativas de las expectativas del cliente. Esta táctica fomenta las conversaciones entre las partes interesadas internas y los clientes, lo que da como resultado un producto más competitivo que es valioso para las personas más importantes de su negocio, sus usuarios.
Mejore la visibilidad de las historias de usuario con Smartsheet para el desarrollo de software
Empodere a sus empleados para que vayan más allá gracias a una plataforma flexible, diseñada para satisfacer las necesidades de su equipo y capaz de adaptarse cuando esas necesidades cambien. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas claves y obtenga visibilidad en tiempo real acerca del trabajo en curso gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en el mismo tiempo. Pruebe Smartsheet gratis hoy mismo.