De Wikipedia, la enciclopedia libre
Ir a navegaciónSaltar a buscar

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. [1] Dependiendo del proyecto, las historias de usuarios 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 construcción de sentidos ; y puede ayudar a los equipos de software a documentar su comprensión del sistema y su contexto. [2]

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". [3]
  • 1999: Kent Beck publicó la primera edición del libro Extreme Programming Explained , presentando Extreme Programming (XP), [4] y el uso de historias de usuarios en el juego de planificación .
  • 2001: Ron Jeffries propuso una fórmula de "Tres C" para la creación de historias de usuario: [5]
    • 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 [6] en Londres ideó el formato de la historia del 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 [7] que ahora se considera la referencia estándar para el tema según Martin Fowler . [8] Cohn nombra a Rachel Davies como la inventora de las historias de usuarios. [ cita requerida ] Mientras Davies era un miembro del equipo en Connextra, ella le da crédito al equipo en su conjunto con la invención. [ cita requerida ]
  • 2014: Después de un primer artículo en 2005 [9] y una entrada de blog en 2008, [10] 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 la historias para dar mejor visibilidad a su interdependencia. [11]

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. [12] [7] [13] Mike Cohn sugirió que la cláusula "para que" sea opcional, aunque a menudo resulta útil. [14]

Como <función> puedo <capacidad>, para que <reciba beneficio>

Chris Matts sugirió que "buscar el valor" era el primer paso para entregar software con éxito y propuso esta alternativa: [15]

Para <recibir beneficio> como <rol>, puedo <objetivo / deseo>

Otra plantilla basada en las Cinco W especifica: [16]

Como <quién> <cuando> <donde>, <quiero> porque <porque>

Ejemplos

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. [17]

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. [17]

Copia de seguridad limitada

Como usuario, puedo indicar las carpetas que no se deben respaldar para que mi unidad de respaldo no se llene con cosas que no necesito guardar. [18]

Uso

Como parte central de muchas metodologías de desarrollo ágiles, como en el juego de planificación de XP , las historias de los usuarios 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 expandir 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". [19] 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". [ Esta cita necesita una cita ] Algunos pueden escribir los criterios de aceptación en un formato ágil típico, Dado-Cuando-Entonces . Otros pueden simplemente usar viñetas tomadas de los requisitos originales recopilados de los clientes o partes interesadas. [ cita requerida ]

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 usuario facilitan la construcción de sentido sin una estructuración indebida de problemas, que está vinculada al éxito. [20]

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. [21]
  • 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.

Un story map en acción, con epopeyas en la parte superior para estructurar historias.

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 .[22] [23]

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. [24] [25] [26] [27] [28] [29]

É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. [30]

Tema

Múltiples epopeyas o historias agrupadas por un tema común o una relación semántica.

Mapa de la historia

Mapeo de historias de usuario

Un story map [31] 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. [ cita requerida ]

El mapeo de historias de usuario [32] utiliza talleres con 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 [33] ) 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" [34] y por debajo representa una sofisticación cada vez mayor. [35] [ aclaración necesaria ]

Mapa de viaje del usuario

Un mapa de viaje del usuario [36] pretende 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 un único usuario debe realizar 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, [37] permitiendo involucrar a los usuarios en enfoques participativos. [38]

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". [39] Si bien las historias de usuario y los casos de uso tienen algunas similitudes, existen varias diferencias entre ellos.

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 ). [41]

Ver también

  • Tablero Kanban
  • Persona (experiencia de usuario)
  • Escenario (informática)
  • Caso de uso

Referencias

  1. Dimitrijević, Sonja; Jovanović, Jelena; Devedžić, Vladan (2015). "Un estudio comparativo de herramientas de software para la gestión de historias de usuario". Tecnología de la información y el software . 57 : 352–368. doi : 10.1016 / j.infsof.2014.05.012 . En los últimos años ha surgido una gran cantidad de herramientas de software que brindan, entre otras cosas, soporte para prácticas basadas en historias de usuarios.
  2. ^ Ralph, Paul (2015). "La teoría de la implementación de la coevolución-creación de sentido del diseño de software". Ciencia de la Programación de Computadores . 101 : 21–41. arXiv : 1302.4061 . doi : 10.1016 / j.scico.2014.11.007 . S2CID 6154223 . 
  3. ^ "El origen de la carta de la historia es una promesa para una conversación: Alistair.Cockburn.us" . alistair.cockburn.us . Consultado el 16 de agosto de 2017 .[ enlace muerto ]
  4. ^ Beck, Kent (1999). Explicación de la programación extrema: Acepte el cambio . Addison-Wesley. ISBN 9780201616415. OCLC  41834882 .
  5. ^ Jeffries, Ron (30 de agosto de 2001). "XP esencial: tarjeta, conversación, confirmación" . Archivado desde el original el 12 de mayo de 2017 . Consultado el 14 de abril de 2017 .
  6. ^ "Plantilla de historia de usuario" . agilealliance.org . Archivado desde el original el 6 de junio de 2020 . Consultado el 18 de abril de 2020 .
  7. ↑ a b Cohn, Mike (2004). Historias de usuarios aplicadas: para el desarrollo de software ágil . Addison-Wesley. ISBN 0321205685. OCLC  54365622 .
  8. ^ Fowler, Martin (22 de abril de 2013). "Historia de usuario" . martinfowler.com . Archivado desde el original el 14 de julio de 2019 . Consultado el 14 de julio de 2019 .
  9. ^ Patton, Jeff (enero de 2005). "Todo depende de cómo lo cortes" . Better Software Magazine : 16–22, 40. Archivado desde el original el 16 de julio de 2019 . Consultado el 16 de julio de 2019 .
  10. ^ Patton, Jeff (8 de octubre de 2008). "El Backlog de historias de nuevos usuarios es un mapa" . Jeff Patton y asociados . Archivado desde el original el 18 de julio de 2019 . Consultado el 16 de julio de 2019 .
  11. ^ Patton, Jeff (2014). Mapeo de historias de usuario . Economía, Peter, Fowler, Martin, Cooper, Alan, Cagan, Marty (Primera ed.). Beijing. ISBN 9781491904909. OCLC  880566740 .
  12. ^ Lucassen, Garm; Dalpiaz, Fabiano; Werf, Jan Martijn EM van der; Brinkkemper, Sjaak (2016), Daneva, Maya; Pastor, Oscar (eds.), "El uso y la eficacia de las historias de usuarios en la práctica", Ingeniería de requisitos: Fundación para la calidad del software , Springer International Publishing, 9619 , págs. 205–222, doi : 10.1007 / 978-3-319- 30282-9_14 , ISBN 978-3-319-30281-2, La plantilla de historia de usuario más común es la 'original' propuesta por Connextra
  13. ^ "Glosario: plantilla de historia de usuario" . agilealliance.org . Alianza ágil . 17 de diciembre de 2015. Archivado desde el original el 3 de febrero de 2020 . Consultado el 3 de febrero de 2020 . Otro nombre es el "formato Connextra", en reconocimiento a sus orígenes
  14. ^ Cohn, Mike (25 de abril de 2008). "Ventajas de" Como usuario, quiero "plantilla de historia de usuario" . Mountaingoatsoftware.com . Archivado desde el original el 18 de diciembre de 2016 . Consultado el 18 de diciembre de 2016 . Si bien considero que la cláusula so-that es opcional, realmente me gusta esta plantilla.
  15. ^ Marcano, Antony (24 de marzo de 2011). "Antiguo favorito: historias de usuarios de inyección de características sobre un tema de valor empresarial" . Antonymarcano.com . Archivado desde el original el 2 de julio de 2012 . Consultado el 23 de febrero de 2017 .
  16. ^ "Historia de usuario" . t2informatik GmbH . Archivado desde el original el 3 de febrero de 2020 . Consultado el 3 de febrero de 2020 . "Como (quién) (cuándo) (dónde), yo (quiero) porque (por qué)". - esta frase se basa en preguntas típicas de W: quién, cuándo, dónde, qué y por qué.
  17. ^ a b Cowan, Alexander. "Tu mejor historia de usuario ágil" . Cowan + . Archivado desde el original el 25 de marzo de 2016 . Consultado el 29 de abril de 2016 .
  18. ^ a b Cohn, Mike. "Historias de usuarios" . Software Mountain Goat . Archivado desde el original el 30 de abril de 2016 . Consultado el 27 de abril de 2016 .
  19. ^ Cohn, Mike. "Las dos formas de agregar detalles a las historias de usuario" . Blog de Mountain Goat Software . Archivado desde el original el 8 de abril de 2019 . Consultado el 8 de abril de 2019 .
  20. ^ Ralph, Paul; Mohanani, Rahul (2015). "¿Es la ingeniería de requisitos intrínsecamente contraproducente?" . 2015 IEEE / ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture . IEEE. págs. 20–23. doi : 10.1109 / TwinPeaks.2015.12 . ISBN 978-1-4673-7100-1. S2CID  2873385 . Archivado desde el original el 22 de junio de 2021 . Consultado el 4 de febrero de 2020 .
  21. ^ "Limitaciones de las historias de usuario" . Ferolen.com. 15 de abril de 2008. Archivado desde el original el 13 de abril de 2014 . Consultado el 9 de abril de 2014 .
  22. ^ "Epopeyas, historias, temas e iniciativas" . Atlassian . Archivado desde el original el 30 de enero de 2019 . Consultado el 8 de febrero de 2019 .
  23. ^ "Historias de usuarios" . Atlassian . Archivado desde el original el 5 de febrero de 2019 . Consultado el 8 de febrero de 2019 .
  24. ^ Britsch, Marcel (5 de septiembre de 2017). "Lo básico: epopeyas, historias, temas y características" . El analista de negocios digitales . Archivado desde el original el 21 de septiembre de 2017 . Consultado el 8 de febrero de 2019 .
  25. ^ Cohn, Mike. "Historias de usuarios, epopeyas y temas" . Software Mountain Goat . Archivado desde el original el 4 de febrero de 2019 . Consultado el 8 de febrero de 2019 .
  26. ^ "Artículos informativos enviados por miembros de Scrum Alliance" . Archivado desde el original el 11 de septiembre de 2018 . Consultado el 11 de septiembre de 2018 .
  27. ^ Guay, Constantin (26 de enero de 2018). "Consejos de Scrum: Diferencias entre épicas, historias, temas y características" . Archivado desde el original el 19 de noviembre de 2018 . Consultado el 8 de febrero de 2019 .
  28. ^ "Historias de usuarios, epopeyas y temas" . 10 de mayo de 2016. Archivado desde el original el 9 de febrero de 2019 . Consultado el 8 de febrero de 2019 .
  29. ^ Cohn, Mike. "No necesitas una jerarquía de historia complicada" . Software Mountain Goat . Archivado desde el original el 10 de mayo de 2019 . Consultado el 8 de febrero de 2019 .
  30. ^ "Configuración de iniciativas y otros niveles de jerarquía - Documentación de Atlassian" . confluence.atlassian.com . Archivado desde el original el 5 de febrero de 2020 . Consultado el 5 de febrero de 2020 . Una 'iniciativa' es un cuerpo de trabajo muy grande, que abarca múltiples epopeyas y, a veces, múltiples equipos. [...] Una iniciativa también es un tipo de problema en Jira.
  31. ^ Patton, Jeff (8 de octubre de 2008). "La nueva acumulación de historias de usuario es un mapa" . Archivado desde el original el 14 de mayo de 2017 . Consultado el 17 de mayo de 2017 .
  32. ^ Patton, Jeff (desarrollador de software) (2014). Mapeo de historias de usuario . Economía, Peter ,, Fowler, Martin, 1963-, Cooper, Alan, 1952-, Cagan, Marty (Primera ed.). Beijing. ISBN 978-1-4919-0490-9. OCLC  880566740 .
  33. ^ Cohn, Mike. "Historias de usuarios, epopeyas y temas" . Mountaingoatsoftware.com . Archivado desde el original el 27 de septiembre de 2017 . Consultado el 26 de septiembre de 2017 .
  34. ^ Cockburn, Alistair. "Walking Skeleton" . Archivado desde el original el 24 de septiembre de 2013 . Consultado el 4 de marzo de 2013 .
  35. ^ "Mapeo de historias" . Alianza ágil. 17 de diciembre de 2015. Archivado desde el original el 23 de junio de 2016 . Consultado el 1 de mayo de 2016 .
  36. ^ Experiencia, líderes mundiales en usuarios basados ​​en investigaciones. "Mapeo de viajes 101" . Nielsen Norman Group . Archivado desde el original el 19 de marzo de 2020 . Consultado el 15 de marzo de 2020 .
  37. ^ Richardson, Adam (15 de noviembre de 2010). "Uso de mapas de viaje del cliente para mejorar la experiencia del cliente" . Harvard Business Review . ISSN 0017-8012 . Archivado desde el original el 22 de marzo de 2020 . Consultado el 15 de marzo de 2020 . 
  38. ^ "Diseño participativo subversivo | Actas de la 14ª Conferencia de diseño participativo: artículos breves, exposiciones interactivas, talleres - volumen 2". doi : 10.1145 / 2948076.2948085 . hdl : 11572/167104 . S2CID 15915593 .  Cite journal requiere |journal=( ayuda )
  39. ^ Cohn, Mike. "Ventajas del proyecto de las historias de usuario como requisitos" . Mountaingoatsoftware.com . Archivado desde el original el 18 de abril de 2012 . Consultado el 26 de septiembre de 2017 .
  40. ^ Fowler, Martin (18 de agosto de 2003). "UseCasesAndStories" . Archivado desde el original el 27 de septiembre de 2017 . Consultado el 26 de septiembre de 2017 .
  41. ^ "Historia de usuario y comparación de casos de uso" . C2.com . Archivado desde el original el 2 de septiembre de 2016 . Consultado el 26 de septiembre de 2017 .

Lectura adicional

  • 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