Historia del usuario - User story
| Desarrollo de software |
|---|
En el desarrollo de software y la gestión de productos , una historia de usuario es una descripción informal en lenguaje natural de las características de un sistema de software. Están escritos desde la perspectiva de un usuario final o usuario de un sistema y pueden registrarse en fichas, notas adhesivas o digitalmente en un software de gestión de proyectos. Dependiendo del proyecto, las historias de usuario pueden ser escritas por diferentes partes interesadas como el cliente, el usuario, el gerente o el equipo de desarrollo.
Las historias de usuario son un tipo de objeto de límite . Facilitan la comunicación y la creación de sentido ; y puede ayudar a los equipos de software a documentar su comprensión del sistema y su contexto.
Historia
- 1998: Alistair Cockburn visitó el proyecto Chrysler C3 en Detroit y acuñó la frase "Una historia de usuario es una promesa para una conversación".
- 1999: Kent Beck publicó la primera edición del libro Extreme Programming Explained , presentando Extreme Programming (XP) y el uso de historias de usuario en el juego de planificación .
- 2001: Ron Jeffries propuso una fórmula de "Tres C" para la creación de historias de usuario:
- La tarjeta (o, a menudo, una nota post-it ) es una ficha física tangible para contener los conceptos;
- La conversación es entre las partes interesadas (clientes, usuarios, desarrolladores, probadores, etc.). Es verbal y, a menudo, se complementa con documentación;
- La Confirmación asegura que se hayan alcanzado los objetivos de la conversación.
- 2001: El equipo de XP de Connextra en Londres ideó el formato de historia de usuario y compartió ejemplos con otros.
- 2004: Mike Cohn generalizó los principios de las historias de usuario más allá del uso de tarjetas en su libro User Stories Applied: For Agile Software Development, que ahora se considera la referencia estándar para el tema según Martin Fowler . Cohn nombra a Rachel Davies como la inventora de las historias de usuarios. Si bien Davies era miembro del equipo de Connextra, le da crédito al equipo en su conjunto por el invento.
- 2014: Después de un primer artículo en 2005 y una entrada de blog en 2008, en 2014 Jeff Patton publicó la técnica de mapeo de historias de usuario, que pretende mejorar con un enfoque sistemático la identificación de historias de usuarios y estructurar las historias para dar mejor visibilidad a su interdependencia.
Principio
Las historias de usuario están escritas por o para usuarios o clientes para influir en la funcionalidad del sistema que se está desarrollando. En algunos equipos, el gerente de producto (o propietario del producto en Scrum ) es el principal responsable de formular historias de usuarios y organizarlas en una cartera de productos . En otros equipos, cualquiera puede escribir una historia de usuario. Las historias de usuario se pueden desarrollar a través de la discusión con las partes interesadas, basadas en personas o simplemente inventadas.
Plantillas comunes
Las historias de usuario pueden seguir uno de varios formatos o plantillas.
La más común es la plantilla Connextra , que se indica a continuación. Mike Cohn sugirió que la cláusula "para que" sea opcional, aunque a menudo es útil.
As a <role> I can <capability>, so that <receive benefit>
Chris Matts sugirió que "buscar el valor" era el primer paso para entregar software con éxito y propuso esta alternativa:
In order to <receive benefit> as a <role>, I can <goal/desire>
Otra plantilla basada en las Cinco W especifica:
As <who> <when> <where>, I want <what> because <why>
Ejemplos de
Prueba de detección (historia épica)
- Como gerente de recursos humanos, quiero crear un cuestionario de selección para poder entender si deseo enviar posibles reclutas al gerente funcional.
Recordatorio de prueba
- Como gerente, quiero explorar mis cuestionarios existentes para poder recordar lo que tengo implementado y averiguar si puedo reutilizar o actualizar un cuestionario existente para el puesto que necesito ahora.
Copia de seguridad limitada
- Como usuario, puedo indicar carpetas de las que no se deben realizar copias de seguridad para que mi unidad de copia de seguridad no se llene con cosas que no necesito guardar.
Uso
Una parte central de muchas metodologías de desarrollo ágiles, como en el juego de planificación de XP , las historias de usuario describen lo que se puede construir en el proyecto de software. Las historias de usuario son priorizadas por el cliente (o el propietario del producto en Scrum ) para indicar cuáles son las más importantes para el sistema y serán desglosadas en tareas y estimadas por los desarrolladores. Una forma de estimar es mediante una escala de Fibonacci .
Cuando las historias de usuario están a punto de implementarse, los desarrolladores deben tener la posibilidad de hablar con el cliente al respecto. Las historias cortas pueden ser difíciles de interpretar, pueden requerir algunos conocimientos previos o los requisitos pueden haber cambiado desde que se escribió la historia.
Las historias de usuario se pueden ampliar para agregar detalles basados en estas conversaciones. Esto puede incluir notas, archivos adjuntos y criterios de aceptación.
Criterios de aceptación
Mike Cohn define los criterios de aceptación como "notas sobre lo que debe hacer la historia para que el propietario del producto la acepte como completa". Definen los límites de una historia de usuario y se utilizan para confirmar cuando una historia se completa y funciona según lo previsto.
La cantidad apropiada de información que se incluirá en los criterios de aceptación varía según el equipo, el programa y el proyecto. Algunos pueden incluir 'criterios predecesores', "El usuario ya ha iniciado sesión y ya ha editado su información una vez". Algunos pueden escribir los criterios de aceptación en un formato ágil típico, Dado-Cuándo-Entonces . Otros pueden simplemente usar viñetas tomadas de los requisitos originales recopilados de los clientes o partes interesadas.
Para que una historia se considere terminada o completa, se deben cumplir todos los criterios de aceptación.
Beneficios
No hay pruebas sólidas de que el uso de historias de usuarios aumente el éxito del software o la productividad de los desarrolladores. Sin embargo, las historias de usuarios facilitan la creación de sentido sin una estructuración indebida de problemas, que está vinculada al éxito.
Limitaciones
Las limitaciones de las historias de usuario incluyen:
- Problema de ampliación: las historias de usuario escritas en pequeñas tarjetas físicas son difíciles de mantener, difíciles de escalar a grandes proyectos y problemáticas para equipos distribuidos geográficamente.
- Vagas, informales e incompletas : las tarjetas de historias de usuarios se consideran iniciadores de conversaciones. Al ser informales, están abiertos a muchas interpretaciones. Siendo breves, no establecen todos los detalles necesarios para implementar una función. Por lo tanto, las historias son inapropiadas para llegar a acuerdos formales o redactar contratos legales.
- Falta de requisitos no funcionales : las historias de usuario rara vez incluyen detalles de requisitos de rendimiento o no funcionales, por lo que las pruebas no funcionales (por ejemplo, el tiempo de respuesta) pueden pasarse por alto.
- No necesariamente representan cómo se debe construir la tecnología: dado que las historias de usuarios a menudo se escriben desde la perspectiva comercial, una vez que un equipo técnico comienza a implementar, puede encontrar que las limitaciones técnicas requieren un esfuerzo que puede ser más amplio que el alcance de una historia individual . A veces, dividir las historias en historias más pequeñas puede ayudar a resolver este problema. Otras veces, las historias "solo técnicas" son las más apropiadas. Estas historias 'solo técnicas' pueden ser cuestionadas por las partes interesadas del negocio por no ofrecer un valor que se pueda demostrar a los clientes / partes interesadas.
Relación con epopeyas, temas e iniciativas
En muchos contextos, las historias de usuarios se utilizan y también se resumen en grupos por razones semánticas y organizativas. Los diferentes usos dependen del punto de vista, por ejemplo, mirando desde la perspectiva del usuario como propietario del producto en relación con las características o desde la perspectiva de la empresa en relación con la organización de tareas.
Si bien algunos sugieren usar 'épico' y 'tema' como etiquetas para cualquier tipo de agrupación imaginable de historias de usuario, la administración de la organización tiende a usarlo para estructurar y unir cargas de trabajo sólidas. Por ejemplo, Jira parece usar una lista de tareas organizada jerárquicamente , en la que nombraron el primer nivel de tareas pendientes como 'historia de usuario', el segundo nivel 'epopeyas' (agrupación de historias de usuario) y el tercero. nivel 'iniciativas' (agrupación de epopeyas). Sin embargo, las iniciativas no siempre están presentes en el desarrollo de la gestión de productos y solo añaden otro nivel de granularidad. En Jira, existen 'temas' (con fines de seguimiento) que permiten relacionar y agrupar elementos de diferentes partes de la jerarquía fija .
En este uso, Jira cambia el significado de los temas en la perspectiva de una organización: por ejemplo, cuánto tiempo dedicamos al desarrollo del tema "xyz". Pero otra definición de temas es: un conjunto de historias, epopeyas, características, etc. para un usuario que forma una unidad semántica u objetivo común . Probablemente no haya una definición común porque existen diferentes enfoques para diferentes estilos de diseño y desarrollo de productos. En este sentido, algunos también sugieren no utilizar ningún tipo de jerarquías y grupos duros.
Épico
Las historias grandes o las historias de múltiples usuarios que están muy estrechamente relacionadas se resumen como épicas. Una explicación común de las epopeyas también es: una historia de usuario que es demasiado grande para un sprint.
Iniciativa
Múltiples epopeyas o historias agrupadas jerárquicamente, en su mayoría conocidas de Jira.
Tema
Múltiples epopeyas o historias agrupadas por un tema común o una relación semántica.
Mapa de la historia
Un story map organiza las historias de los usuarios de acuerdo con un flujo narrativo que presenta el panorama general del producto. La técnica fue desarrollada por Jeff Patton de 2005 a 2014 para abordar el riesgo de proyectos inundados con historias de usuarios muy detalladas que distraen la realización de los principales objetivos del producto.
El mapeo de historias de usuario utiliza talleres con los usuarios para identificar primero las principales actividades comerciales. Cada una de estas actividades principales puede involucrar a varios tipos de usuarios o personas.
La línea narrativa transversal horizontal se traza luego identificando las principales tareas del usuario individual involucrado en estas actividades comerciales. La línea se mantiene durante todo el proyecto. Las historias de usuario más detalladas se recopilan y recopilan como de costumbre con la práctica de la historia de usuario. Pero cada nueva historia de usuario se inserta en el flujo narrativo o se relaciona verticalmente con una tarea principal.
El eje horizontal corresponde a la cobertura de los objetivos del producto y el eje vertical a las necesidades de los usuarios individuales.
De esta manera, es posible describir incluso sistemas grandes sin perder el panorama general.
Los Story Maps pueden proporcionar fácilmente una visualización gráfica bidimensional del Product Backlog : En la parte superior del mapa están los encabezados bajo los cuales se agrupan las historias, generalmente denominadas 'épicas' (grandes historias de usuarios de grano grueso), 'temas' (colecciones de historias de usuarios relacionadas) o 'actividades'. Estos se identifican al orientar el flujo de trabajo del usuario o "el orden en el que explicaría el comportamiento del sistema". Verticalmente, debajo de las epopeyas, las cartas de historias reales se asignan y ordenan por prioridad. La primera fila horizontal es un "esqueleto andante" y debajo representa una sofisticación cada vez mayor.
Mapa de viaje del usuario
Un mapa de viaje del usuario tiene la intención de mostrar el panorama general, pero para una sola categoría de usuario. Su línea narrativa se centra en la cronología de fases y acciones que debe realizar un único usuario para alcanzar sus objetivos.
Esto permite mapear la experiencia del usuario más allá de un conjunto de historias de usuario. Según los comentarios de los usuarios, las emociones positivas y negativas se pueden identificar a lo largo del viaje. Los puntos de fricción o las necesidades no satisfechas se pueden identificar en el mapa. Esta técnica se utiliza para mejorar el diseño de un producto, lo que permite involucrar a los usuarios en enfoques participativos.
Comparación con casos de uso
Un caso de uso se ha descrito como "una descripción generalizada de un conjunto de interacciones entre el sistema y uno o más actores, donde un actor es un usuario u otro sistema". Si bien las historias de usuario y los casos de uso tienen algunas similitudes, existen varias diferencias entre ellos.
| Historias de usuarios | Casos de uso | |
|---|---|---|
| Similitudes |
|
|
| Diferencias |
|
|
| Plantilla | Como <tipo de usuario>, puedo <algún objetivo> para que <algún motivo>. |
|
Kent Beck , Alistair Cockburn , Martin Fowler y otros discutieron este tema más en la wiki de c2.com (el hogar de la programación extrema ).
Ver también
Referencias
Otras lecturas
- Daniel H. Steinberg, Daniel W. Palmer, Ingeniería de software extrema , Pearson Education, Inc., ISBN 0-13-047381-2 .
- Mike Cohn, Historias de usuarios aplicadas , 2004, Addison Wesley, ISBN 0-321-20568-5 .
- Mike Cohn, Estimación y planificación ágiles , 2006, Prentice Hall, ISBN 0-13-147941-5 .
- Tiempo de analista de negocios
- Payton Consulting 'En qué se diferencian las historias de usuario de los requisitos de IEEE