uno de los mayores desafíos en el desarrollo de software es la tarea casi imposible de reunir requisitos claros y luego lograr que esos requisitos permanezcan sin cambios durante el desarrollo de código. En el enfoque de cascada para el desarrollo de software, a pesar de los esfuerzos para definir, documentar y aprobar todas las contingencias posibles antes de que comience el desarrollo, el producto entregado rara vez es lo que el cliente quiere.
¿la alternativa ágil? Creación de historias de usuario.,
una de las mayores ventajas de utilizar un enfoque ágil para el desarrollo de software es que los requisitos no están establecidos en piedra, sino que se espera que cambien, con la retroalimentación constante de las partes interesadas y el negocio. Las metodologías ágiles como Scrum y extreme programming (XP) reemplazan los documentos de requisitos tradicionales y largos con un backlog de productos priorizado compuesto por historias de usuario concisas, cuyos detalles emergen más cerca de cuando la historia está lista para implementarse.,
aunque la creación de historias de usuario es más arte que ciencia, este tutorial le dará la información, ejemplos y pasos que necesitará para crear historias de usuario de alta calidad.
el historial de historias de usuario
XP introdujo por primera vez el concepto de historias de usuario en 1998, comparándolas con casos de uso. En Object-Oriented Software Engineering: A Use Case Driven Approach, Ivar Jacobson introdujo los casos de uso como una forma de documentar los requisitos mediante la definición de interacciones entre un rol (una persona que usa el sistema) y el propio sistema para lograr un objetivo utilizando el Unified Modeling Language (UML).,
este enfoque fue popular en el desarrollo orientado a objetos y todavía se usa como un proceso clave en marcos de desarrollo de software, como el Proceso Unificado (UP), el Proceso Unificado racional de IBM (RUP) y el método Unificado de Oracle (Oum). El uso de casos de uso, en lugar de historias de usuario, permite un desarrollo iterativo e incremental y se considera un enfoque ágil para la definición de requisitos.,
con la introducción de las historias de usuario mucho más cortas y la popularidad de XP y Scrum, un backlog de productos compuesto por historias de usuario se convirtió en el enfoque más comúnmente conocido para la definición de requisitos ágiles. Muchos profesionales todavía piensan que las historias de usuario son el único enfoque ágil aceptable. Sin embargo, Alistair Cockburn, uno de los firmantes del Manifiesto Ágil, prefiere los casos de uso a las historias de usuario.
aunque hay muchas opiniones sólidas sobre el significado de «ágil», tanto los casos de uso como las historias de usuario son compatibles con ese enfoque., Algunos dicen que las historias de usuario eventualmente se vuelven similares a los casos de uso una vez que el equipo está de acuerdo con los detalles de la implementación. En las primeras etapas, la historia del Usuario es simplemente una frase corta, pero no está completa hasta que se definen los detalles y los criterios de aceptación.
crear historias de usuario
hay diferentes opiniones sobre la definición de una historia de usuario y la mejor manera de crear una., Algunas pautas para una buena historia de usuario incluyen lo siguiente:
- Debe ser escrito por alguien que represente a los usuarios de negocios (generalmente el propietario del producto)
- inicialmente debe incluir descripciones breves del «quién, qué y por qué», pero no Del «cómo»
- debe producir una porción vertical de código de trabajo
- Debe ser lo suficientemente pequeño como para que pueda ser codificado y probado en una iteración (generalmente un período de una a cuatro semanas)
se utilizan varias plantillas, técnicas y acrónimos para ayudar a los propietarios de productos a escribir historias de usuario., Tres de las técnicas más comunes son la plantilla rol-función-razón, las tres C (tarjeta, conversación, confirmación) e invertir (independiente, negociable, valioso, estimable, pequeño, comprobable).
los ejemplos
dicen que estás desarrollando una aplicación que permitiría a los entrenadores cargar material didáctico y atraer a los estudiantes que están interesados en tomar una clase. Así es como aplicarías técnicas de historia de usuario.,
Role-Feature-Reason
como Mike Cohn de Mountain Goat Software explica, la plantilla role-feature-reason, o RGB (role, goal, benefit), se ve algo como esto:
«como un quiero para eso .»
aunque hay variaciones, esta estructura de oración corta mantiene el enfoque en el quién, qué y por qué. Esto evita que el propietario del producto proporcione al equipo de desarrollo demasiada información sobre cómo deben implementar una solución. Al centrarse en quién, qué y por qué, el equipo de desarrollo está capacitado para encontrar la mejor solución técnica.,
Ejemplo 1: Proporcionar a un entrenador la capacidad de agregar un curso
como entrenador, me gustaría poder agregar un nuevo curso, para tener el potencial de atraer nuevos estudiantes.
Ejemplo 2: Proporcionar a un estudiante la capacidad de buscar un curso
como estudiante, me gustaría poder buscar las ofertas de cursos, para poder encontrar una oferta que más me interese.
el rol (quién)
el rol describe quién se beneficiará de esta función. Observe que el rol no es simplemente » el usuario.,»Hay diferentes tipos de usuarios, por lo que queremos que el rol sea más específico que «Usuario» pero describa el tipo de usuario que se beneficiará de la historia. Los propietarios de productos a menudo tienen la tarea de entrar en la mente de sus usuarios con el fin de entender lo que sería más valioso para ellos.
Ejemplo 1 Role = trainer
Ejemplo 2 Role = student
la característica (what)
Este paso describe muy brevemente lo que el usuario quiere. Esto representa más de cerca el requisito que usted describe en el desarrollo de software tradicional., Sin embargo, debe tener cuidado de no ser demasiado específico o describir cómo escribir el código. Eso se determinará eventualmente, pero no cuando cree la historia de usuario por primera vez. La historia del Usuario debe escribirse desde la perspectiva del usuario que se beneficiará de la función, no desde la perspectiva del desarrollador que la codificará.
característica de ejemplo 1 = Agregar un nuevo curso
característica de Ejemplo 2 = buscar las ofertas del curso
la razón (por qué)
finalmente, queremos indicar por qué el usuario desea esta característica. ¿Qué valor obtendrá el usuario?, Esto ayuda al propietario del producto a evaluar cómo priorizar la historia del usuario en el backlog. Si el valor o el beneficio no se pueden articular, podría ser algo que no es necesario. Comprender el valor a menudo ayuda al equipo de desarrollo a encontrar formas innovadoras de implementar el código para resolver el objetivo, formas que pueden ser diferentes de lo que el propietario del producto tiene en mente.,
Ejemplo 1 razón = atraer nuevos estudiantes
Ejemplo 2 razón = encontrar una oferta que más me interese
las tres C: Tarjeta, conversación, confirmación
la fórmula de las tres C, desarrollada por Ron Jeffries, ayuda a llegar a un acuerdo entre la empresa y el equipo técnico sobre el significado de la historia del usuario. Las tres C los guían a través de la elaboración progresiva de una historia, desde una breve declaración hasta una historia de usuario completamente desarrollada.,
Tarjeta
La historia del usuario comienza deliberadamente breve, con una declaración simple que podría caber en una tarjeta de índice 3×5, por lo general siguiendo el formato de función-función-beneficio que acabo de cubrir. Por ejemplo:
como formador, me gustaría poder agregar un nuevo curso, para tener el potencial de atraer nuevos estudiantes.
conversación
aunque la historia del usuario comienza como una simple declaración, los detalles deben surgir antes de que el equipo comience a trabajar en la historia., En lugar de describir lo que se necesita en la documentación, el equipo incluirá 1) la representación de la empresa (generalmente el propietario del producto) y 2) el equipo de desarrollo en sí, incluidos los desarrolladores, probadores, analistas de negocios o cualquier otra persona en el equipo.
esta conversación permite al equipo de Desarrollo hacer preguntas para asegurarse de tener una comprensión clara de lo que se está pidiendo y el valor que se proporciona. Por ejemplo:
desarrollador: ¿tendrá que cargar el curso el entrenador en un sitio web?,
Propietario del producto: No, el entrenador solo agregará información sobre el curso que se ofrecerá, y la función debe incluir una forma para que el estudiante se inscriba en una lista de intereses. Esta historia le da al entrenador la capacidad de anunciar un curso.
desarrollador: ¿qué campos deben incluirse?
Propietario del producto: título del curso, resumen, fechas y horas, ubicación.
desarrollador: ¿será solo para clases cara a cara de publicidad?
Propietario del producto: Sí., Podemos agregar una opción de clase virtual más adelante, pero esta historia solo cubrirá la adición de información del curso para ofertas de clases cara a cara.
desarrollador: ¿qué información se debe recopilar cuando un estudiante potencial pide entrar en una lista de intereses?
Propietario del producto: Nombre, Número de teléfono y dirección de correo electrónico.
el equipo actualizará la historia del usuario con la información que han recopilado de la conversación, y discutirán la implementación, o el «CÓMO», que a menudo crea tareas específicas que deben realizarse para completar la historia., Aunque la historia del usuario está escrita desde la perspectiva del usuario, el equipo de desarrollo escribe las tareas para los desarrolladores e incluye los detalles técnicos de implementación.
confirmación
el equipo de desarrollo necesita tener una comprensión clara de cómo funcionará la función en diferentes situaciones, incluidas las condiciones de error. Necesitan obtener confirmación con respecto a los criterios de aceptación del propietario del producto. Estos son los criterios que deben cumplirse para que la historia se considere hecha y aceptada., Aquí hay un ejemplo de criterios de aceptación:
- Un entrenador puede agregar un curso nuevo ingresando el título del curso, el resumen, las fechas y horas y la ubicación en un formulario y presionando el botón «Agregar curso».
- Si falta algún campo o las fechas u horas no son válidas, aparecerán mensajes de error.
- Una vez que el curso se haya agregado correctamente, se mostrará públicamente en el sitio web del curso y habrá un botón para que el estudiante exprese su interés.,
- el botón de interés le permitirá al usuario ingresar su nombre, dirección de correo electrónico y número de teléfono, y estos datos se almacenarán y se asociarán con el nuevo curso.
INVEST: los atributos de una historia de usuario sólida
INVEST es un acrónimo que ayuda a evaluar si tiene una historia de usuario de alta calidad. Así es como los atributos en el acrónimo se aplican a la historia en la que hemos estado trabajando.
I = independiente – ¿puede esta historia ser completada por el equipo? Queremos que el equipo sea capaz de completar toda la historia en lugar de depender de un equipo diferente para hacer la GUI, por ejemplo.,
N = Negociable-la historia no es tan detallada como para describir exactamente la longitud de los campos o dar detalles sobre los formatos de fecha y similares. Lo más probable es que haya rutinas o bibliotecas comunes que permitan al equipo de desarrollo implementarlas de la manera que tenga más sentido para ellos.
V = valioso-el propietario del producto describe que el valor que se busca es la capacidad para que el entrenador pueda anunciar las próximas clases. Esto está claro en el «por qué» de la declaración original y se vuelve a enfatizar en la conversación.,
e = Estimable – el equipo hará suficientes preguntas y recopilará los detalles para sentirse seguro de su capacidad para estimar la historia.
S = pequeño-el equipo necesita estar seguro de que será capaz de completar la historia dentro de un sprint. Si no lo hacen, podrían dividir la historia. Por ejemplo, en nuestra historia de ejemplo, pueden decidir hacer que la capacidad de recopilar la información del estudiante sea una historia diferente y simplemente mostrar información sobre la clase para esta historia.
T = comprobable-con criterios de aceptación claros, se pueden probar tanto el camino feliz como las condiciones de error.,
alinearse con una visión
he cubierto los aspectos básicos de la creación de una historia de usuario, pero todavía necesita comprender el panorama general antes de crear sus propias historias de usuario. Hay mucho trabajo que debe hacer por adelantado, a un nivel superior, para determinar cuáles son las características de mayor valor que deben entregarse a los clientes. En última instancia, se descomponen en historias de usuarios.
es importante que el equipo comprenda primero la visión de alto nivel y se asegure de que las características y, en última instancia, las historias de usuario se alineen con esa visión de alto nivel.,
normalmente, se divide el producto en grupos que van por nombres como «temas» o «características».»Aunque el etiquetado de estos elementos de backlog puede variar según el método ágil y las herramientas que utilice para describirlos, la idea es asegurarse de que estén alineados para que el trabajo se pueda rastrear hasta su visión, lo que garantizará que esté cumpliendo con los objetivos y valores de la visión del producto.
de nuevo, no inicie un proyecto creando historias de usuario; comience creando una visión., Para nuestro ejemplo, simplemente muestro una declaración de visión de muestra, que conduce a algunas características de muestra, que se pueden descomponer aún más en historias de usuario.
visión
proporcionar un sitio web de alta calidad que permitirá a los entrenadores anunciar cursos y permitir a los estudiantes tomar esos cursos.
características
- proporciona una página de oferta de cursos que permitirá a los estudiantes inscribirse en los cursos.
- Proporcionar una página de inicio que le dirá a los usuarios de qué se trata nuestro sitio.
- Proporcionar un proceso de registro que permite a los usuarios iniciar sesión, Crear un perfil y realizar un seguimiento de sus clases.,
- Proporcionar un blog que ayudará a publicitar nuestras ofertas y ganar publicidad para nuestro sitio web.
las historias de usuario
- proporcionan al entrenador la capacidad de agregar un curso en la página de oferta del curso.
- Proporcionar a los estudiantes la capacidad de buscar un curso.
en el ejemplo anterior, puede ver cómo se originaron las historias de usuario. Las historias de usuario eran parte de una función para «proporcionar una página de oferta de cursos» que se alinea con la visión de alto nivel.,
mapeo de impacto
aunque la alineación con una visión le ayudará a completar su backlog inicial, no es la única manera de hacerlo. Hay muchas herramientas y técnicas que los gerentes de producto pueden usar para crear las historias que van en un nuevo backlog y que se alinean con la visión.
una técnica de planificación estratégica utilizada para ayudar a comprender el panorama general, el mapeo de impacto, fue popularizada por Gojko Adzic, autor de Fifty quick Ideas to Improve Your User Stories and Impact Mapping: Making a big impact with software products and projects., El mapeo de impacto es un mapa mental que comienza con el objetivo, que debe abordar la cuestión del valor y por qué está construyendo el producto.
el siguiente nivel enumera los «actores» o personas que ayudarán a lograr la meta. A continuación, el mapa enumera los comportamientos, o «impactos», que los actores realizarán para ayudar a lograr ese objetivo. El nivel final del mapa presenta los «entregables» que el equipo puede implementar. Estos Permiten y apoyan a los actores para crear los impactos deseados. Es a partir de estos entregables que se derivan las características del software y las historias.,
- Objetivo: hacer ampliamente disponibles los cursos que los estudiantes querrán tomar
- actores: entrenadores, estudiantes
- impactos: los entrenadores proporcionarán clases de alta calidad que son de interés para los estudiantes; los estudiantes proporcionarán referencias y recomendaciones
- entregables: clases de alta calidad que son accesibles para los estudiantes
- historias potenciales:
- «Como entrenador, quiero anunciar clases, para que pueda obtener estudiantes.
- «como formadora, quiero recibir comentarios de los estudiantes, para poder mejorar continuamente.,»
- » como formador, quiero saber qué quieren los estudiantes, para poder agregar a mi plan de estudios.»
- «Como estudiante, quiero encontrar las clases que más me interesan.»
- » Como estudiante, quiero encontrar clases que pueda tomar en línea, para que no tenga que viajar.»
- » Como estudiante, quiero leer los comentarios de otros, para que pueda decidir qué clases se adaptan mejor a mí.»
mapear las historias de los usuarios de esta manera permite la trazabilidad en el proceso de pensamiento de cómo las historias en última instancia crean valor y cómo las usas para lograr el objetivo final., La idea no es implementar todo, sino encontrar el camino más corto a través del mapa para lograr su objetivo.
dividir historias
uno de los problemas más comunes que encuentran los equipos ágiles es cuando las historias son demasiado grandes y no se pueden completar en una iteración. Cuando el equipo crea las tareas asociadas con la historia, se dan cuenta de que hay demasiadas incógnitas, o que las tareas involucradas tomarán más tiempo del que el equipo tiene disponible en una sola iteración. Los equipos a veces abordan esto dividiendo una historia más grande en historias más pequeñas.,
recuerde, sin embargo, que desea una historia de usuario para ofrecer software de trabajo que agregará valor para el usuario. En lugar de crear una historia de usuario que solo completará parcialmente una función, divida las historias en «secciones verticales» que ofrecerán una funcionalidad de extremo a extremo.
recurra a la comunidad para un aprendizaje más profundo
Las soluciones detalladas sobre cómo resolver los problemas más difíciles relacionados con los requisitos y las historias de usuario son únicas para cada situación. Sin embargo, un rasgo común de los profesionales ágiles exitosos es que están ansiosos por ayudar a los demás y compartir lo que saben.,
el sitio web Userstories de Cohn permite a aquellos que trabajan con backlogs de productos e historias de usuarios compartir productos, recursos y conocimientos. La página de productos incluye una impresionante lista de herramientas, muchas disponibles de forma gratuita, con oportunidades para comentarios y comentarios de los usuarios. Cohn señala en el sitio que espera expandir el sitio para que se puedan compartir los retrasos de productos.
nunca habrá una respuesta única para todos sobre cómo escribir historias de usuario perfectas., Sin embargo, con el tiempo, con una mezcla saludable de experiencia, consejos de los expertos y experimentación con herramientas y técnicas sugeridas, puede mejorar continuamente.