Historia del 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 y 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 Post-it 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 usuarios son un tipo de objeto límite . Facilitan la comprensión y la comunicación; y puede 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 ProgrammingExplicated , 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 adhesiva ) es una ficha física tangible que contiene los conceptos;
  • La conversación es 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 historia de usuario y compartió ejemplos con otros.
• 2004: Mike Cohn generalizó los principios de las historias de usuarios 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 necesaria ]} Si bien Davies era miembro del equipo en Connextra, le da crédito al equipo en su conjunto por la invención. ^{[ cita necesaria ]}
• 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 la historias para dar mayor 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 un trabajo pendiente del producto . En otros equipos, cualquiera puede escribir una historia de usuario. Las historias de usuario se pueden desarrollar a través de discusiones con las partes interesadas, basadas en personas o simplemente inventadas.

Plantillas comunes

Las historias de usuarios 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 sigue siendo útil. ^[14]

Como <rol> puedo <capacidad>, para que <recibir 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>

Otro modelo basado en las Cinco Preguntas especifica: ^[16]

Como <quién> <cuándo> <dónde>, quiero <qué> porque <por qué>

Una plantilla que se usa comúnmente para mejorar la seguridad se llama "Historia de usuario malvado" o "Historia de usuario de abuso" y se usa como una forma de pensar como un hacker para considerar escenarios que podrían ocurrir en un ataque cibernético. Estas historias están escritas desde la perspectiva de un atacante que intenta comprometer o dañar la aplicación, en lugar de las personas típicas 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

Prueba de detección (historia épica)

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

Recuerdo del cuestionario

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 las 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. ^[19]

Uso

Una parte central de muchas metodologías de desarrollo ágiles, como en el juego de planificación de programación extrema , las historias de usuarios describen lo que se puede construir en el producto de software. El cliente (o el propietario del producto en Scrum ) prioriza las historias de usuario para indicar cuáles son las más importantes para el sistema y los desarrolladores las dividirán en tareas y las estimarán. Una forma de estimar es mediante una escala de Fibonacci .

Cuando las historias de usuario están a punto de implementarse, los desarrolladores deberían tener la posibilidad de hablar con el cliente al respecto. Los cuentos pueden ser difíciles de interpretar, pueden requerir algunos conocimientos previos o los requisitos pueden haber cambiado desde que se escribió el cuento.

Las historias de usuarios 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 incluirá en los criterios de aceptación varía según el equipo, programa y proyecto. Algunos pueden incluir 'criterios predecesores', "El usuario ya inició sesión y ya editó 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-Cuándo-Entonces . Otros pueden simplemente utilizar viñetas tomadas de los requisitos originales recopilados de los clientes o 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 fehacientes 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 los problemas, lo que está vinculado al éxito. ^[21]

Limitaciones

Las limitaciones de las historias de usuarios incluyen:

• Problema de ampliación : 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.
• Vagos, informales e incompletos : las tarjetas de historias de usuario se consideran para iniciar una conversación. Al ser informales, están abiertos a muchas interpretaciones. Al ser breves, no indican todos los detalles necesarios para implementar una función. Por tanto, las historias son inapropiadas para llegar a acuerdos formales o redactar contratos legales. ^[22]
• Falta de requisitos no funcionales : las historias de usuarios rara vez incluyen detalles de rendimiento o requisitos no funcionales, por lo que las pruebas no funcionales (por ejemplo, el tiempo de respuesta) pueden pasarse por alto.
• No necesariamente represente cómo se debe construir la tecnología: dado que las historias de usuario a menudo se escriben desde la perspectiva empresarial, una vez que un equipo técnico comienza a implementarla, 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 otras más pequeñas puede ayudar a resolver este problema. Otras veces, las historias "sólo técnicas" son las más apropiadas. Estas historias 'únicamente técnicas' pueden ser cuestionadas por las partes interesadas del negocio por no ofrecer valor que pueda demostrarse a los clientes/partes interesadas.

Relación con epopeyas, temas e iniciativas/programas

En muchos contextos, las historias de usuarios se utilizan y también se resumen en grupos por razones ontológicas, semánticas y organizativas. La iniciativa también se conoce como Programa en ciertos marcos ágiles escalados. 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 story map en acción, con epopeyas en la parte superior para estructurar las historias.

Mientras que algunos sugieren utilizar "épico" y "tema" como etiquetas para cualquier tipo imaginable de agrupación de historias de usuarios, la gestión de organizaciones tiende a utilizarlas para estructurar y unir cargas de trabajo sólidas. Por ejemplo, Jira parece utilizar 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 usuarios) y al 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 simplemente añaden 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 en 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 forma una unidad u objetivo semántico común . Probablemente no exista 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 estrictas. ^{[25] [26] [27] [28] [29] [30]}

Tema

Múltiples 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 escalados: 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 story map ^[32] organiza historias de 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 de historias de usuarios muy detalladas que distraen la realización de los principales objetivos del producto. ^{[ cita necesaria ]}

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

A continuación, se traza la línea narrativa transversal horizontal identificando las principales tareas del usuario individual involucrado en estas actividades comerciales. La línea se mantiene durante todo el proyecto. Se recopilan y recopilan historias de usuarios más detalladas como es habitual en la práctica de historias de usuarios. 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 mapas de historias pueden proporcionar fácilmente una visualización gráfica bidimensional del trabajo pendiente del producto : en la parte superior del mapa están los encabezados bajo los cuales se agrupan las historias, normalmente denominadas "épicas" (grandes historias de usuarios generales), "temas". (colecciones de historias de usuarios relacionadas ^[34] ) o 'actividades'. Estos se identifican orientándose al 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 historia reales se asignan y ordenan por prioridad. La primera fila horizontal es un "esqueleto andante" ^[35] y debajo representa una sofisticación cada vez mayor. ^{[36] [ se necesita aclaración ]}

Mapa de viaje del usuario

Un mapa de viaje del usuario ^[37] pretende mostrar el panorama general pero para una única 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 conseguir 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, se pueden identificar las emociones positivas y negativas a lo largo del viaje. En el mapa se pueden identificar puntos de fricción o necesidades insatisfechas. Esta técnica se utiliza para mejorar el diseño de un producto, ^[38] permitiendo involucrar a los usuarios en enfoques participativos. ^[39]

Comparando 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 usuarios 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 la wiki de c2.com (el hogar de la programación extrema ). ^[42]

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 software . 57 : 352–368. doi :10.1016/j.infsof.2014.05.012. En los últimos años ha surgido un gran número 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 del diseño de software de creación de sentido, coevolución e implementación". 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 la historia es una promesa para una 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). "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". alianzagilealliance.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 usuarios aplicadas: para el desarrollo de software ágil . Addison-Wesley. ISBN 0321205685. OCLC  54365622.
8. Fowler, Martin (22 de abril de 2013). "Historia del 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". Revista Better Software : 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). "La acumulación 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.{{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 usuarios en la práctica", Ingeniería de requisitos: base para la calidad del software , Apuntes de conferencias sobre informática, Springer International Publishing, vol. 9619, 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". alianzagilealliance.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 "formato Connextra", en reconocimiento a sus orígenes.
14. Cohn, Mike (25 de abril de 2008). "Ventajas de la plantilla "Como usuario, quiero" 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 "así que eso" es opcional, realmente me gusta esta plantilla.
15. Marcano, Antony (24 de marzo de 2011). "Viejo favorito: historias de usuarios de inyección de funciones 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 . 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, Alejandro. "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". Software de cabra montesa . 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 usuarios". Blog de software de cabra montesa . Archivado desde el original el 8 de abril de 2019 . Consultado el 8 de abril de 2019 .
21. Ralph, Paul; Mohanani, Rahul (2015). "¿Es la ingeniería de requisitos inherentemente contraproducente?". 2015 IEEE/ACM Quinto taller internacional sobre los picos gemelos de requisitos y arquitectura . IEEE. págs. 20-23. doi :10.1109/TwinPeaks.2015.12. ISBN 978-1-4673-7100-1. S2CID  2873385.
22. "Limitaciones de las historias de usuarios". 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. "Epopeyas, temas, historias e iniciativas". Atlassiano . Archivado desde el original el 30 de enero de 2019 . Consultado el 8 de febrero de 2019 .
24. "Historias de usuarios". Atlassiano . 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). "Conceptos básicos: 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 .
26. Cohn, Mike. "Historias de usuarios, epopeyas y temas". Software de cabra montesa . 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). "Consejos de Scrum: diferencias entre epopeyas, historias, temas y características". Archivado desde el original el 19 de noviembre de 2018 . Consultado el 8 de febrero de 2019 .
29. "Historias de usuarios, 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 necesita una jerarquía de historias complicada". Software de cabra montesa . 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 jerárquicos - 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 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.
32. Patton, Jeff (8 de octubre de 2008). "La acumulación de nuevas 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 ed.). Beijing. ISBN 978-1-4919-0490-9. OCLC  880566740.{{cite book}}: CS1 maint: location missing publisher (link)
34. 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 .
35. Cockburn, Alistair. "Esqueleto andante". Archivado desde el original el 24 de septiembre de 2013 . Consultado el 4 de marzo de 2013 .
36. "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 .
37. Experiencia, líderes mundiales en usuarios basados ​​en investigaciones. "Mapeo de viaje 101". Grupo Nielsen Norman . 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 viaje del cliente para mejorar la experiencia del cliente". Revisión de negocios de Harvard . 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}}: Citar diario requiere |journal=( ayuda )
40. Cohn, Mike. "Ventajas del proyecto de historias de usuarios como requisitos". 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). "Casos de uso e historias". Archivado desde el original el 27 de septiembre de 2017 . Consultado el 26 de septiembre de 2017 .
42. "Comparación de historias de usuario y casos de uso". C2.com . Archivado desde el original el 2 de septiembre de 2016 . Consultado el 26 de septiembre de 2017 .

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, Planificación y estimación ágil , 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