Historia de usuario

Descripción informal de una o más características de un sistema 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. Se escriben desde la perspectiva de un usuario final o de un usuario de un sistema , y ​​pueden registrarse en fichas, notas adhesivas o digitalmente en un software de gestión específico. ^[1] Dependiendo del producto, 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 límite . Facilitan la comprensión y la comunicación, y pueden ayudar a los equipos de software a documentar su comprensión del sistema y su contexto. ^[2]

Historia

• 1997: Kent Beck presenta historias de usuarios en el proyecto Chrysler C3 en Detroit.
• 1998: Alistair Cockburn visitó el proyecto C3 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 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: ^[5]
  • La tarjeta (o a menudo una nota adhesiva ) es un elemento físico tangible que contiene los conceptos;
  • La conversación se lleva a cabo entre las partes interesadas (clientes, usuarios, desarrolladores, evaluadores, etc.). Es verbal y a menudo se complementa con documentación;
  • La Confirmación asegura que se han alcanzado los objetivos de la conversación.
• 2001: El equipo XP de Connextra ^[6] en Londres ideó el formato de la 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 ^[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 usuario. ^{[ cita requerida ]} Si bien Davies era miembro del equipo de Connextra, le atribuye la invención al equipo en su conjunto. ^{[ 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 usuario y estructurar las historias para dar mejor visibilidad a su interdependencia. ^[11]

Principio

Las historias de usuario son escritas por o para usuarios o clientes con el fin de influir en la funcionalidad del sistema que se está desarrollando. En algunos equipos, el gerente de producto (o el propietario del producto en Scrum ) es el principal responsable de formular historias de usuario y organizarlas en un backlog de producto . En otros equipos, cualquiera puede escribir una historia de usuario. Las historias de usuario se pueden desarrollar mediante debates con las partes interesadas, en función de personas o simplemente inventadas.

Plantillas comunes

Las historias de usuario pueden seguir uno de varios formatos o plantillas.

La plantilla más común es la de Connextra , que se indica a continuación. ^{[12] [7] [13]} Mike Cohn sugirió que la cláusula "para que" sea opcional, aunque a menudo sigue siendo útil. ^[14]

Como <rol> puedo <capacidad>, de modo 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> <cuándo> <dónde>, quiero <qué> porque <por qué>

Una plantilla que se utiliza habitualmente para mejorar la seguridad se denomina "Historia de usuario malvado" o "Historia de usuario abusivo" y se utiliza como una forma de pensar como un hacker para considerar escenarios que podrían ocurrir en un ciberataque. Estas historias se escriben desde la perspectiva de un atacante que intenta comprometer o dañar la aplicación, en lugar de los personajes típicos que se encuentran en una historia de usuario: ^[17]

Como empleado descontento, quiero borrar la base de datos de usuarios para perjudicar a la empresa.

Ejemplos

Cuestionario de selección (historia épica)

Como gerente de recursos humanos, quiero crear un cuestionario de selección para poder entender si quiero enviar posibles reclutas al gerente funcional. ^[18]

Recordatorio de la prueba

Como gerente, quiero explorar mis cuestionarios existentes para poder recordar lo que tengo implementado y determinar si puedo reutilizar o actualizar un cuestionario existente para el puesto que necesito ahora. ^[18]

Copia de seguridad limitada

Como usuario, puedo indicar carpetas que no quiero respaldar para que mi unidad de respaldo no se llene con cosas que no necesito guardar. ^[19]

Uso

Una parte central de muchas metodologías de desarrollo ágil, como en el juego de planificación de la programación extrema , las historias de usuario describen lo que se puede construir en el producto 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 se desglosarán en tareas y serán estimadas por los desarrolladores. Una forma de estimar es a través de una escala de Fibonacci.

Cuando se van a implementar las historias de usuario, los desarrolladores deben tener la posibilidad de hablar con el cliente al respecto. Las historias breves pueden ser difíciles de interpretar, pueden requerir ciertos 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". ^[20] Definen los límites de una historia de usuario y se utilizan para confirmar cuándo una historia está completa y funciona según lo previsto.

La cantidad adecuada de información que se debe 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 el formato ágil típico, Dado-Cuando-Entonces . Otros pueden simplemente usar viñetas tomadas de los requisitos originales recopilados de los clientes o las partes interesadas. ^[20] Para que una historia se considere terminada o completa, se deben cumplir todos los criterios de aceptación.

Beneficios

No hay pruebas concluyentes de que el uso de historias de usuario aumente el éxito del software o la productividad de los desarrolladores. Sin embargo, las historias de usuario facilitan la comprensión sin estructurar excesivamente los problemas, lo que está vinculado al éxito. ^[21]

Limitaciones

Las limitaciones de las historias de usuario incluyen:

• Problema de escalabilidad : las historias de usuario escritas en tarjetas físicas pequeñas son difíciles de mantener, difíciles de escalar a proyectos grandes y problemáticas para equipos distribuidos geográficamente.
• Vagas, informales e incompletas : las tarjetas de historias de usuario se consideran un punto de partida para una conversación. Al ser informales, están abiertas a muchas interpretaciones. Al ser breves, no indican todos los detalles necesarios para implementar una característica. Por lo tanto, las historias no son adecuadas para alcanzar acuerdos formales o redactar contratos legales. ^[22]
• Falta de requisitos no funcionales : las historias de usuario rara vez incluyen detalles de rendimiento o requisitos no funcionales, por lo que es posible que se pasen por alto pruebas no funcionales (por ejemplo, tiempo de respuesta).
• No necesariamente representan cómo debe construirse la tecnología: dado que las historias de usuario suelen escribirse desde la perspectiva empresarial, una vez que un equipo técnico comienza a implementar, puede descubrir 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 esto. Otras veces, las historias "solo técnicas" son las más adecuadas. Las partes interesadas comerciales pueden cuestionar estas historias "solo técnicas" por no brindar valor que se pueda demostrar a los clientes/partes interesadas.

Relación con epopeyas, temas e iniciativas/programas

En muchos contextos, las historias de usuario se utilizan y también se resumen en grupos por razones ontológicas, semánticas y organizativas. En ciertos marcos ágiles escalables, también se hace referencia a la iniciativa como programa. Los diferentes usos dependen del punto de vista, por ejemplo, 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 mapa de historias en acción, con epopeyas en la parte superior para estructurar las historias.

Mientras que algunos sugieren usar "épica" y "tema" como etiquetas para cualquier tipo de agrupación de historias de usuario, la gestió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 pendientes organizada jerárquicamente , en la que denominaron al primer nivel de tareas pendientes "historia de usuario", al segundo nivel "épicas" (agrupación de historias de usuario) y al tercer nivel "iniciativas" (agrupación de épicas). Sin embargo, las iniciativas no siempre están presentes en el desarrollo de la gestión de productos y solo agregan otro nivel de granularidad. En Jira, existen "temas" (para fines de seguimiento) que permiten relacionar y agrupar elementos de diferentes partes de la jerarquía fija . ^{[23] [24]}

En este uso, Jira cambia el significado de los temas desde una perspectiva organizacional: por ejemplo, ¿cuánto tiempo dedicamos a desarrollar el tema "xyz"? Pero otra definición de temas es: un conjunto de historias, epopeyas, características, etc. para un usuario que forman una unidad semántica o un 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 grupos y jerarquías rígidas. ^{[25] [26] [27] [28] [29] [30]}

Tema

Varias epopeyas o muchas historias muy extensas que están estrechamente relacionadas se resumen como temas. Una explicación común de las epopeyas es también: tanto trabajo que requiere muchos sprints, o en marcos escalables: un tren de lanzamiento o un tren de soluciones.

Iniciativa

Múltiples temas, epopeyas o historias agrupadas jerárquicamente. ^[31]

Épico

Múltiples temas o historias agrupadas por ontología y/o relación semántica.

Mapa de la historia

Mapeo de historias de usuario

Un mapa de historias ^[32] organiza las historias de los usuarios según un flujo narrativo que presenta el panorama general del producto. La técnica fue desarrollada por Jeff Patton entre 2005 y 2014 para abordar el riesgo de que los proyectos se llenen de historias de usuarios muy detalladas que distraen de la consecución de los objetivos principales del producto. ^{[ cita requerida ]}

El mapeo de historias de usuario ^[33] utiliza talleres con usuarios para identificar en primer lugar las principales actividades comerciales. Cada una de estas actividades principales puede involucrar varios tipos de usuarios o personajes.

A continuación, se traza la línea narrativa transversal horizontal identificando las tareas principales de cada usuario involucrado en estas actividades comerciales. Esta línea se mantiene durante todo el proyecto. Se recopilan y recopilan historias de usuario más detalladas, como es habitual en la práctica de las historias de usuario. Sin embargo, 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 la visión general.

Los mapas de historias pueden proporcionar fácilmente una visualización gráfica bidimensional del backlog del producto : en la parte superior del mapa se encuentran los encabezados bajo los cuales se agrupan las historias, generalmente denominadas "épicas" (grandes historias de usuario de grano grueso), "temas" (colecciones de historias de usuario relacionadas ^[34] ) o "actividades". Estas se identifican orientándose al flujo de trabajo del usuario o "el orden en que explicarías el comportamiento del sistema". Verticalmente, debajo de las epopeyas, las tarjetas de historia reales se asignan y ordenan por prioridad. La primera fila horizontal es un "esqueleto andante" ^[35] y debajo de eso representa una sofisticación creciente. ^{[36] [ aclaración necesaria ]}

Mapa del recorrido del usuario

Un mapa de recorrido del usuario ^[37] pretende mostrar el panorama general pero para una única categoría de usuarios. Su línea narrativa se centra en la cronología de fases y acciones que un único usuario debe llevar a cabo para alcanzar sus objetivos.

Esto permite mapear la experiencia del usuario más allá de un conjunto de historias de usuario. Con base en los comentarios de los usuarios, se pueden identificar las emociones positivas y negativas a lo largo del recorrido. Se pueden identificar en el mapa los puntos de fricción o las necesidades no satisfechas. Esta técnica se utiliza para mejorar el diseño de un producto, ^[38] lo que permite involucrar a los usuarios en enfoques participativos. ^[39]

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". ^[40] 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 a fondo en el wiki c2.com (el hogar de la programación extrema ). ^[42]

Véase 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 han surgido un gran número de herramientas de software que proporcionan, entre otras cosas, soporte para prácticas basadas en historias de usuario.
2. Ralph, Paul (2015). "La teoría de la implementación, coevolución y creación de sentido del diseño de software". Ciencia de la programación informática . 101 : 21–41. arXiv : 1302.4061 . doi :10.1016/j.scico.2014.11.007. S2CID  6154223.
3. "El origen de la tarjeta de historia es una promesa de conversación: Alistair.Cockburn.us". alistair.cockburn.us . Archivado desde el original el 22 de junio de 2021 . Consultado el 16 de agosto de 2017 .
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). «Essential XP: Card, Conversation, Confirmation». 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 . 17 de diciembre de 2015. Archivado desde el original el 6 de junio de 2020 . Consultado el 18 de abril de 2020 .
7. Cohn, Mike (2004). Historias de usuario aplicadas: para el desarrollo ágil de software . Addison-Wesley. ISBN 0321205685.OCLC 54365622  .
8. Fowler, Martin (22 de abril de 2013). «User Story». 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 mires". 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 nuevo backlog de historias de usuario es un mapa". Jeff Patton & Associates . 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 edición). Pekín. ISBN 9781491904909.OCLC 880566740  .{{cite book}}: CS1 maint: location missing publisher (link)
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 usuario en la práctica", Ingeniería de requisitos: fundamentos para la calidad del software , Lecture Notes in Computer Science, vol. 9619, Springer International Publishing, págs. 205–222, doi :10.1007/978-3-319-30282-9_14, ISBN 978-3-319-30281-2, S2CID  26458219, La plantilla de historia de usuario más frecuente es la 'original' propuesta por Connextra
13. "Glosario: Plantilla de historia de usuario". agilealliance.org . Agile Alliance . 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 "formato Connextra", en reconocimiento a sus orígenes
14. Cohn, Mike (25 de abril de 2008). "Ventajas de la plantilla de historia de usuario "Como usuario, quiero". 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). «Old Favourite: Feature Injection User Stories on a Business Value Theme». 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 . 25 de septiembre de 2019. 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 las típicas preguntas W: quién, cuándo, dónde, qué y por qué.
17. Van der Veer, Rob (18 de mayo de 2020). "Orientación ágil de SAMM". GitHub .
18. Cowan, Alexander. "Su mejor historia de usuario ágil". Cowan+ . Archivado desde el original el 25 de marzo de 2016 . Consultado el 29 de abril de 2016 .
19. Cohn, Mike. "Historias de usuarios". Mountain Goat Software . Archivado desde el original el 30 de abril de 2016. Consultado el 27 de abril de 2016 .
20. 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 .
21. Ralph, Paul; Mohanani, Rahul (2015). "¿La ingeniería de requisitos es inherentemente 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. Número de identificación del sujeto  2873385.
22. "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 .
23. "Épicas, temas, historias e iniciativas". Atlassian . Archivado desde el original el 30 de enero de 2019 . Consultado el 8 de febrero de 2019 .
24. "Historias de usuario". Atlassian . Archivado desde el original el 5 de febrero de 2019 . Consultado el 8 de febrero de 2019 .
25. Britsch, Marcel (5 de septiembre de 2017). "Lo básico: epopeyas, historias, temas y características". The Digital Business Analyst . Archivado desde el original el 21 de septiembre de 2017. Consultado el 8 de febrero de 2019 .
26. Cohn, Mike. «Historias de usuario, epopeyas y temas». Mountain Goat Software . Archivado desde el original el 4 de febrero de 2019. Consultado el 8 de febrero de 2019 .
27. "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 .
28. Guay, Constantin (26 de enero de 2018). «Scrum tips: Differences between epics, stories, themes and features». Archivado desde el original el 19 de noviembre de 2018. Consultado el 8 de febrero de 2019 .
29. "Historias de usuario, epopeyas y temas". 8 de diciembre de 2021. Archivado desde el original el 9 de febrero de 2019. Consultado el 8 de diciembre de 2021 .
30. Cohn, Mike. "No necesitas una jerarquía de historias complicada". Mountain Goat Software . Archivado desde el original el 10 de mayo de 2019. Consultado el 8 de febrero de 2019 .
31. "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 conjunto de trabajos muy grande, que abarca varias epopeyas y, a veces, varios equipos. [...] Una iniciativa también es un tipo de problema en Jira.
32. Patton, Jeff (8 de octubre de 2008). "El nuevo backlog de historias de usuario es un mapa". Archivado desde el original el 14 de mayo de 2017. Consultado el 17 de mayo de 2017 .
33. Patton, Jeff (desarrollador de software) (2014). Mapeo de historias de usuario . Economía, Peter, Fowler, Martin, 1963-, Cooper, Alan, 1952-, Cagan, Marty (primera edición). Pekín. ISBN 978-1-4919-0490-9.OCLC 880566740  .{{cite book}}: CS1 maint: location missing publisher (link)
34. Cohn, Mike. "Historias de usuario, epopeyas y temas". Mountaingoatsoftware.com . Archivado desde el original el 27 de septiembre de 2017. Consultado el 26 de septiembre de 2017 .
35. Cockburn, Alistair. "Walking Skeleton". Archivado desde el original el 24 de septiembre de 2013. Consultado el 4 de marzo de 2013 .
36. "Story Mapping". Agile Alliance. 17 de diciembre de 2015. Archivado desde el original el 23 de junio de 2016 . Consultado el 1 de mayo de 2016 .
37. Experiencia, líderes mundiales en investigación basada en el usuario. "Journey Mapping 101". Nielsen Norman Group . Archivado desde el original el 19 de marzo de 2020. Consultado el 15 de marzo de 2020 . {{cite web}}: |first=tiene nombre genérico ( ayuda )
38. Richardson, Adam (15 de noviembre de 2010). «Uso de mapas de recorrido 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 .
39. "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 citar revista |journal=( ayuda )
40. Cohn, Mike. "Ventajas de las historias de usuario como requisitos en los proyectos". Mountaingoatsoftware.com . Archivado desde el original el 18 de abril de 2012. Consultado el 26 de septiembre de 2017 .
41. 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 .
42. "Comparación de casos de uso e historias de usuario". 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 usuario 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 IEEE'