Hispanopedia Wiki
Articulo de referencia

Historia de usuario

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 softwa...

Hispanopedia WikiContenido en espanolLectura gratuita

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 del usuario final o usuario del sistema y pueden registrarse en fichas, notas adhesivas o digitalmente en 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 frontera . 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 las historias de usuario 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 de conversación". [ 3 ]
  • 1999: Kent Beck publicó la primera edición del libro Extreme Programming Explained , que introduce la Programación Extrema (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 sirve para contener los conceptos;
    • La conversación se produce entre las partes interesadas (clientes, usuarios, desarrolladores, evaluadores, etc.). Es verbal y a menudo se complementa con documentación;
    • La confirmación garantiza 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 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 sobre el tema según Martin Fowler . [ 8 ] Cohn nombra a Rachel Davies como la inventora de las historias de usuario. [ 9 ] Si bien Davies era miembro del equipo de Connextra, atribuye la invención al equipo en su conjunto.
  • 2014: Después de un primer artículo en 2005 [ 10 ] y una entrada de blog en 2008, [ 11 ] 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 mayor visibilidad a su interdependencia. [ 12 ]

Principio

Las historias de usuario son escritas por o para usuarios o clientes con el fin de influir en la funcionalidad del sistema en desarrollo. En algunos equipos, el gerente de producto (o propietario del producto en Scrum ) es el principal responsable de formular las historias de usuario y organizarlas en el backlog del producto . En otros equipos, cualquier persona puede escribir una historia de usuario. Las historias de usuario pueden desarrollarse mediante conversaciones con las partes interesadas, basándose en perfiles de usuario o simplemente inventándose.

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. [ 13 ] [ 7 ] [ 14 ] Mike Cohn sugirió que la cláusula "para que" es opcional, aunque sigue siendo útil con frecuencia. [ 15 ]

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: [ 16 ]

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

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

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 malintencionada" 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 ciberataque. Estas historias se escriben 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: [ 18 ]

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

Ejemplos

Prueba de selección (historia épica)
Como gerente de recursos humanos, quiero crear un cuestionario de selección para poder determinar si debo enviar posibles candidatos al gerente funcional. [ 19 ]
Recordatorio del cuestionario
Como gerente, quiero revisar mis cuestionarios existentes para recordar lo que tengo implementado y determinar si puedo reutilizar o actualizar un cuestionario existente para el puesto que necesito ahora. [ 19 ]
Respaldo limitado
Como usuario, puedo indicar las carpetas que no quiero respaldar para que mi disco de respaldo no se llene con cosas que no necesito guardar. [ 20 ]

Uso

Las historias de usuario, un elemento central de muchas metodologías de desarrollo ágil, como el juego de planificación de la programación extrema , 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, las cuales se dividen en tareas y son estimadas por los desarrolladores. Una forma de estimar consiste en asignar a cada tarea una cantidad de puntos de historia seleccionados de la secuencia de Fibonacci : 1, 2, 3, 5, 8, 13, donde las tareas más simples reciben una puntuación de 1 y las más complejas, puntuaciones más altas.

Cuando se van a implementar historias de usuario, los desarrolladores deberían tener la posibilidad de hablar con el cliente al respecto. Las historias breves pueden ser difíciles de interpretar, pueden requerir conocimientos previos o los requisitos pueden haber cambiado desde que se escribieron.

Las historias de usuario se pueden ampliar para añadir 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 la historia debe hacer para que el propietario del producto la acepte como completa". [ 21 ] 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 apropiada de información que debe incluirse en los criterios de aceptación varía según el equipo, el programa y el proyecto. Algunos pueden incluir "criterios de precedencia", "El usuario ya ha iniciado sesión y ya ha editado su información una vez". Otros 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. [ 21 ] Para que una historia se considere terminada o completa, se deben cumplir todos los criterios de aceptación.

Beneficios

No existen pruebas sólidas 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 una estructuración excesiva del problema, lo cual está relacionado con el éxito. [ 22 ]

Limitaciones

Las limitaciones de las historias de usuario incluyen:

  • Problema de escalabilidad : Las historias de usuario escritas en pequeñas tarjetas físicas 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 puntos de partida para la conversación. Al ser informales, están abiertas a muchas interpretaciones. Al ser breves, no especifican todos los detalles necesarios para implementar una funcionalidad. Por lo tanto, las historias no son apropiadas para alcanzar acuerdos formales ni para redactar contratos legales. [ 23 ]
  • Falta de requisitos no funcionales : Las historias de usuario rara vez incluyen detalles sobre el rendimiento o los requisitos no funcionales, por lo que las pruebas no funcionales (por ejemplo, el tiempo de respuesta) pueden pasarse por alto.
  • No necesariamente representan cómo debe construirse la tecnología: dado que las historias de usuario suelen escribirse desde la perspectiva del negocio, una vez que un equipo técnico comienza la implementación, puede descubrir que las limitaciones técnicas requieren un esfuerzo mayor que el alcance de una historia individual. A veces, dividir las historias en otras más pequeñas puede ayudar a resolver esto. Otras veces, las historias exclusivamente técnicas son las más apropiadas. Estas historias exclusivamente técnicas pueden ser cuestionadas por los interesados ​​del negocio por no aportar un valor demostrable a los clientes o partes interesadas.

Relación con epopeyas, temas e iniciativas/programas

En muchos contextos, las historias de usuario se utilizan y se resumen en grupos por razones ontológicas, semánticas y organizativas. En ciertos marcos ágiles escalados, la iniciativa también se denomina 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 funcionalidades o desde la perspectiva de la empresa en relación con la organización de las tareas.

Un mapa de historias en acción, con epopeyas en la parte superior para estructurar las historias.

Si bien algunos sugieren usar «épica» y «tema» como etiquetas para cualquier tipo de agrupación imaginable de historias de usuario, la gestión de la organización tiende a utilizarlas para una estructuración sólida y la unificación de las cargas de trabajo. Por ejemplo, Jira parece utilizar una lista de tareas organizada jerárquicamente , en la que denominaron el primer nivel de tareas «historia de usuario», el segundo nivel «épicas» (agrupación de historias de usuario) y el 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 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 . [ 24 ] [ 25 ]

En este uso, Jira cambia el significado de los temas desde una perspectiva organizacional: por ejemplo, cuánto tiempo dedicamos al desarrollo del tema "xyz". Pero otra definición de temas es: un conjunto de historias, épicas, características, etc., para un usuario que forma una unidad semántica o un objetivo 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 rígidas. [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ]

Tema

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

Iniciativa

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

É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 [ 33 ] organiza las historias de usuario según un flujo narrativo que presenta la visión general del producto. Esta técnica fue desarrollada por Jeff Patton entre 2005 y 2014 para abordar el riesgo de que los proyectos se saturen de historias de usuario muy detalladas que desvíen la atención de los objetivos principales del producto.

El mapeo de historias de usuario [ 34 ] 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 identificando las tareas principales de cada usuario involucrado en estas actividades empresariales. Esta línea se mantiene a lo largo de todo el proyecto. Se recopilan historias de usuario más detalladas, como es habitual en la metodología de 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 forma, resulta posible describir incluso sistemas de gran tamaño sin perder de vista el panorama 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" (historias de usuario grandes y generales), "temas" (colecciones de historias de usuario relacionadas [ 35 ] ) o "actividades". Estas se identifican orientándose al flujo de trabajo del usuario o "el orden en que se explicaría el comportamiento del sistema". Verticalmente, debajo de las épicas, las tarjetas de historias propiamente dichas se asignan y ordenan por prioridad. La primera fila horizontal es un "esqueleto andante" [ 36 ] y debajo de este se representa una sofisticación creciente. [ 37 ]

Mapa del recorrido del usuario

Un mapa de recorrido del usuario [ 38 ] pretende mostrar una visión general, pero para una única categoría de usuario. Su narrativa se centra en la cronología de las fases y acciones que un usuario debe realizar para alcanzar sus objetivos.

Esto permite mapear la experiencia del usuario más allá de un conjunto de historias de usuario. A partir de los comentarios de los usuarios, se pueden identificar las emociones positivas y negativas a lo largo del recorrido. 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, [ 39 ] permitiendo involucrar a los usuarios en enfoques participativos. [ 40 ]

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". [ 41 ] 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 la wiki de c2.com (el hogar de la programación extrema ). [ 43 ]

Véase también

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". Information and Software Technology . 57 : 352–368 . doi : 10.1016/j.infsof.2014.05.012 . En los últimos años han surgido numerosas herramientas de software que ofrecen, entre otras cosas, soporte para prácticas basadas en historias de usuario.
  2. ↑ Ralph, Paul (2015). "La teoría de la coevolución e implementación de la construcción de significado en el diseño de software". Science of Computer Programming . 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 de conversación : Alistair.Cockburn.us" . alistair.cockburn.us . Archivado del original el 22 de junio de 2021. Recuperado el 16 de agosto de 2017 . 
  4. ↑ Beck, Kent (1999). Programación extrema explicada: Acepta el cambio . Addison-Wesley. ISBN 9780201616415OCLC 41834882​​ 
  5. ↑ Jeffries, Ron (30 de agosto de 2001). "XP esencial: tarjeta, conversación, confirmación" . Archivado del original el 12 de mayo de 2017. Recuperado el 14 de abril de 2017 .
  6. ↑ "Plantilla de historia de usuario" . agilealliance.org . 17 de diciembre de 2015. Archivado del original el 6 de junio de 2020. Consultado el 18 de abril de 2020 .
  7. 1 2 Cohn, Mike (2004). User Stories Applied: For Agile Software Development . Addison-Wesley. ISBN 0321205685OCLC 54365622​​ 
  8. ↑ Fowler, Martin (22 de abril de 2013). "Historia de usuario" . martinfowler.com . Archivado del original el 14 de julio de 2019. Recuperado el 14 de julio de 2019 .
  9. ↑ Cohn, Mike. "¿Qué es una plantilla de historia de usuario y por qué funciona tan bien?" . Mountain Goat Software . Consultado el 9 de enero de 2025 .
  10. ↑ Patton, Jeff (enero de 2005). "Todo está en cómo lo mires" . Better Software Magazine : 16–22 , 40. Archivado del original el 16 de julio de 2019. Recuperado el 16 de julio de 2019 .
  11. ↑ Patton, Jeff (8 de octubre de 2008). "El nuevo backlog de historias de usuario es un mapa" . Jeff Patton & Associates . Archivado del original el 18 de julio de 2019. Recuperado el 16 de julio de 2019 .
  12. ↑ Patton, Jeff (2014). Mapeo de historias de usuario . Economy, Peter, Fowler, Martin, Cooper, Alan, Cagan, Marty (Primera ed.). Pekín. ISBN  9781491904909OCLC 880566740​​ {{cite book}}: CS1 mantenimiento: falta el editor de ubicación ( enlace )
  13. ↑ Lucassen, Garm; Dalpiaz, Fabiano; Werf, Jan Martijn EM van der; Brinkkemper, Sjaak (2016), "El uso y la efectividad de las historias de usuario en la práctica", en Daneva, Maya; Pastor, Oscar (eds.), Ingeniería de requisitos: fundamentos para la calidad del software , Lecture Notes in Computer Science, vol. 9619, Springer International Publishing, pp. 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 
  14. ↑ "Glosario: Plantilla de historia de usuario" . agilealliance.org . Agile Alliance . 17 de diciembre de 2015. Archivado del 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 .
  15. ↑ Cohn, Mike (25 de abril de 2008). "Ventajas de la plantilla de historia de usuario "Como usuario, quiero"" . Mountaingoatsoftware.com . Archivado del original el 18 de diciembre de 2016. Recuperado el 18 de diciembre de 2016. Si bien considero que la cláusula "para que" es opcional, realmente me gusta esta plantilla.
  16. ↑ Marcano, Antony (24 de marzo de 2011). "Un clásico: historias de usuario de inyección de funcionalidades sobre un tema de valor empresarial" . Antonymarcano.com . Archivado del original el 2 de julio de 2012. Recuperado el 23 de febrero de 2017 .
  17. ↑ "Historia de usuario" . t2informatik GmbH . 25 de septiembre de 2019. Archivado del 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 con W: quién, cuándo, dónde, qué y por qué.
  18. ↑ Van der Veer, Rob (18 de mayo de 2020). "Guía ágil de SAMM" . GitHub .
  19. 1 2 Cowan, Alexander. "Tu mejor historia de usuario ágil" . Cowan+ . Archivado del original el 25 de marzo de 2016. Recuperado el 29 de abril de 2016 .
  20. 1 2 Cohn, Mike. "Historias de usuario" . Mountain Goat Software . Archivado del original el 30 de abril de 2016. Recuperado el 27 de abril de 2016 .
  21. 1 2 Cohn, Mike. "Las dos maneras de agregar detalles a las historias de usuario" . Blog de Mountain Goat Software . Archivado del original el 8 de abril de 2019. Recuperado el 8 de abril de 2019 .
  22. ↑ Ralph, Paul; Mohanani, Rahul (2015). "¿Es la ingeniería de requisitos inherentemente contraproducente?". 2015 IEEE/ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture . IEEE. pp. 20–23 . doi : 10.1109/TwinPeaks.2015.12 . ISBN  978-1-4673-7100-1. S2CID 2873385 . 
  23. ↑ "Limitaciones de las historias de usuario" . Ferolen.com. 15 de abril de 2008. Archivado del original el 13 de abril de 2014. Consultado el 9 de abril de 2014 .
  24. ↑ "Épicas, temas, historias e iniciativas" . Atlassian . Archivado del original el 30 de enero de 2019. Consultado el 8 de febrero de 2019 .
  25. ↑ "Historias de usuario" . Atlassian . Archivado del original el 5 de febrero de 2019. Consultado el 8 de febrero de 2019 .
  26. ↑ Britsch, Marcel (5 de septiembre de 2017). "Lo básico: épicas, historias, temas y características" . The Digital Business Analyst . Archivado del original el 21 de septiembre de 2017. Recuperado el 8 de febrero de 2019 .
  27. ↑ Cohn, Mike. "Historias de usuario, epopeyas y temas" . Mountain Goat Software . Archivado del original el 4 de febrero de 2019. Recuperado el 8 de febrero de 2019 .
  28. ↑ "Artículos informativos enviados por miembros de Scrum Alliance" . Archivado del original el 11 de septiembre de 2018. Consultado el 11 de septiembre de 2018 .
  29. ↑ Guay, Constantin (26 de enero de 2018). "Consejos de Scrum: Diferencias entre épicas, historias, temas y características" . Archivado del original el 19 de noviembre de 2018. Recuperado el 8 de febrero de 2019 .
  30. ↑ "Historias de usuario, épicas y temas" . 8 de diciembre de 2021. Archivado del original el 9 de febrero de 2019. Consultado el 8 de diciembre de 2021 .
  31. ↑ Cohn, Mike. "No necesitas una jerarquía de historias complicada" . Mountain Goat Software . Archivado del original el 10 de mayo de 2019. Recuperado el 8 de febrero de 2019 .
  32. ↑ "Configuración de iniciativas y otros niveles de jerarquía - Documentación de Atlassian" . confluence.atlassian.com . Archivado del original el 5 de febrero de 2020. Consultado el 5 de febrero de 2020. Una "iniciativa" es un conjunto de trabajo muy extenso que abarca múltiples epopeyas y, a veces, múltiples equipos. [...] Una iniciativa también es un tipo de incidencia en Jira.
  33. ↑ Patton, Jeff (8 de octubre de 2008). "El nuevo backlog de historias de usuario es un mapa" . Archivado del original el 14 de mayo de 2017. Recuperado el 17 de mayo de 2017 .
  34. ↑ Patton, Jeff (Desarrollador de software) (2014). Mapeo de historias de usuario . Economy, Peter, Fowler, Martin, 1963-, Cooper, Alan, 1952-, Cagan, Marty (Primera ed.). Pekín. ISBN  978-1-4919-0490-9OCLC 880566740​​ {{cite book}}: CS1 mantenimiento: falta el editor de ubicación ( enlace )
  35. ↑ Cohn, Mike. "Historias de usuario, épicas y temas" . Mountaingoatsoftware.com . Archivado del original el 27 de septiembre de 2017. Consultado el 26 de septiembre de 2017 .
  36. ↑ Cockburn, Alistair. "Walking Skeleton" . Archivado del original el 24 de septiembre de 2013. Recuperado el 4 de marzo de 2013 .
  37. ↑ "Mapeo de historias" . Agile Alliance. 17 de diciembre de 2015. Archivado del original el 23 de junio de 2016. Consultado el 1 de mayo de 2016 .
  38. ↑ Experiencia, líderes mundiales en investigación de usuarios. "Mapeo de la experiencia del usuario 101" . Nielsen Norman Group . Archivado del original el 19 de marzo de 2020. Recuperado el 15 de marzo de 2020 .{{cite web}}: |first=tiene nombre genérico ( ayuda )
  39. ↑ Richardson, Adam (15 de noviembre de 2010). "Uso de mapas del recorrido del cliente para mejorar la experiencia del cliente" . Harvard Business Review . ISSN 0017-8012 . Archivado del original el 22 de marzo de 2020. Consultado el 15 de marzo de 2020 . 
  40. ↑ "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}}: Para citar una revista se requiere |journal=( ayuda )
  41. ↑ Cohn, Mike. "Ventajas del proyecto de usar historias de usuario como requisitos" . Mountaingoatsoftware.com . Archivado del original el 18 de abril de 2012. Consultado el 26 de septiembre de 2017 .
  42. ↑ Fowler, Martin (18 de agosto de 2003). "UseCasesAndStories" . Archivado del original el 27 de septiembre de 2017. Recuperado el 26 de septiembre de 2017 .
  43. ↑ "Comparación de historias de usuario y casos de uso" . C2.com . Archivado del original el 2 de septiembre de 2016. Consultado el 26 de septiembre de 2017 .

Lecturas adicionales

  • 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 del analista de negocios
  • Payton Consulting 'En qué se diferencian las historias de usuario de los requisitos IEEE' Archivado el 14 de febrero de 2015 en Wayback Machine