Historia

Las historias actúan como un ‘lenguaje pidgin’, donde ambos lados (usuarios y desarrolladores) pueden ponerse de acuerdo lo suficiente para trabajar juntos de manera efectiva.

—Bill Wake, co-inventor de la programación extrema

Las historias son descripciones cortas de una pequeña pieza de funcionalidad deseada, escritas en el lenguaje del usuario. Los equipos ágiles implementan pequeñas secciones verticales de funcionalidad del sistema y se dimensionan para que puedan completarse en una sola iteración.,

Las historias son el artefacto principal utilizado para definir el comportamiento del sistema en Agile. Son descripciones cortas y simples de la funcionalidad generalmente contadas desde la perspectiva del usuario y escritas en su idioma. Cada uno está destinado a permitir la implementación de una pequeña porción vertical del comportamiento del sistema que soporta el desarrollo incremental.

Las historias proporcionan la información suficiente para que las personas de negocios y técnicas entiendan la intención. Los detalles se posponen hasta que la historia esté lista para ser implementada., A través de criterios de aceptación y pruebas de aceptación, las historias se vuelven más específicas, lo que ayuda a garantizar la calidad del sistema.

Las historias de usuario ofrecen funcionalidad directamente al usuario final. Las historias de habilitadores brindan visibilidad a los elementos de trabajo necesarios para respaldar la exploración, la arquitectura, la infraestructura y el cumplimiento.

el modelo de requisitos de SAFe describe una jerarquía de cuatro niveles de artefactos que describen el comportamiento funcional del sistema: Épico, capacidad, característica e historia. En conjunto, describen todo el trabajo para crear el comportamiento previsto de la solución., Pero el trabajo de implementación detallado se describe a través de historias, que constituyen el Backlog del equipo. La mayoría de las historias surgen de las características de negocios y habilitadores en el Backlog del programa, pero otras provienen del contexto local del equipo.

Cada historia es un comportamiento pequeño e independiente que se puede implementar de forma incremental y proporciona algún valor al usuario o a la solución. Es una porción vertical de funcionalidad para garantizar que cada iteración ofrezca un nuevo valor. Las historias son pequeñas y deben completarse en una sola iteración (consulte la sección dividir historias).,

a menudo, las historias se escriben primero en una tarjeta o nota adhesiva. La naturaleza física de la tarjeta crea una relación tangible entre el equipo, la historia y el Usuario: ayuda a involucrar a todo el equipo en la escritura de la historia. Las notas adhesivas también ofrecen otros beneficios: ayudan a visualizar el trabajo y se pueden colocar fácilmente en una pared o mesa, reorganizar en secuencia e incluso pasar cuando sea necesario., Las historias permiten una mejor comprensión del alcance y el progreso:

• «Wow, mira todas estas historias en las que estamos a punto de registrarnos» (alcance)
• «Mira todas las historias que logramos en esta iteración» (progreso)

mientras que cualquiera puede escribir historias, aprobarlas en el backlog del equipo y aceptarlas en la línea de base del sistema son responsabilidad del propietario del producto. Por supuesto, los stickies no se escalan bien en toda la empresa, por lo que las historias a menudo pasan rápidamente a las herramientas de gestión del ciclo de vida ágil (Alm).,

Hay dos tipos de historias en SAFe, user stories e enabler stories, como se describe a continuación.

las fuentes de historias

Las historias suelen estar impulsadas por la división de las características de negocio y habilitador, como ilustra la Figura 1.

historias de usuario

Las historias de usuario son el medio principal de expresar la funcionalidad necesaria. Reemplazan en gran medida la especificación de requisitos tradicionales., (En algunos casos, sin embargo, sirven para explicar y desarrollar el comportamiento del sistema que luego se registra para respaldar el cumplimiento, la trazabilidad u otras necesidades.)

debido a que se centran en el usuario como el sujeto de interés, y no en el sistema, las historias de usuario se centran en el valor. Para apoyar esto, la forma de expresión recomendada es la forma de voz de usuario, de la siguiente manera:

como (rol de usuario), quiero (actividad), de modo que (valor de negocio)

mediante el uso de este formato, los equipos son guiados para entender quién está utilizando el sistema, lo que están haciendo con él, y por qué lo están haciendo., La aplicación del formato de’ voz del usuario ‘ tiende rutinariamente a aumentar la competencia del dominio del equipo; llegan a comprender mejor las necesidades reales del negocio de su usuario. La figura 2 proporciona un ejemplo.

Las’Personas’ describen características específicas de los usuarios representativos que ayudan a los equipos a comprender mejor a su usuario final. Las personas de ejemplo para el jinete en la Figura 2 podrían ser un buscador de emociones ‘Jane’ y un jinete tímido ‘Bob’., Las descripciones de las historias hacen referencia a estas personas (como Jane I want want).

mientras que la voz de la historia del Usuario es el caso común, no todos los sistemas interactúan con un usuario final. A veces el ‘Usuario’ es un dispositivo (por ejemplo, una impresora) o un sistema (por ejemplo, un servidor de transacciones). En estos casos, la historia puede tomar la forma ilustrada en la Figura 3.

Enabler Stories

Los equipos pueden necesitar desarrollar la arquitectura o infraestructura para implementar algunas historias de usuario o componentes de soporte del sistema. En este caso, es posible que la historia no toque directamente a ningún usuario final. Estas son historias habilitadoras y admiten la exploración, la arquitectura o la infraestructura. Las historias de habilitadores se pueden expresar en lenguaje técnico en lugar de centrado en el usuario, como ilustra la Figura 4.

hay muchos otros tipos de historias del habilitador que incluyen:

• refactorización y Picos (como se define tradicionalmente en XP)
• Creación o mejora de infraestructura de desarrollo/implementación
• ejecución de trabajos que requieren interacción humana (por ejemplo, indexar 1 millón de páginas web)
• Creación de las configuraciones de producto o componente necesarias para diferentes propósitos
• verificación de las cualidades del sistema (p. ej.,

Las historias del habilitador se muestran al igual que las historias de usuario, generalmente mostrando el conocimiento adquirido, los artefactos producidos o la interfaz de usuario, el stub o la maqueta.

Escribir Buenas Historias

Buenas historias requieren múltiples perspectivas. En agile, todo el equipo (propietario del producto, desarrolladores y evaluadores) crea una comprensión compartida de qué crear para reducir la repetición de trabajos y aumentar el rendimiento. Los equipos colaboran utilizando el desarrollo basado en el comportamiento (BDD) para definir pruebas de aceptación detalladas que describan definitivamente cada historia., Las buenas historias requieren múltiples perspectivas:

• Los propietarios de productos proporcionan el pensamiento del cliente para la viabilidad y la conveniencia
• Los desarrolladores proporcionan viabilidad técnica
• Los Probadores proporcionan un pensamiento amplio para las excepciones, los casos extremos y otras formas inesperadas en que los usuarios pueden interactuar con el sistema

La escritura colaborativa de historias garantiza que se aborden todas las perspectivas y que todos estén de acuerdo con el comportamiento de la historia con los resultados representados en la descripción, los criterios de aceptación y las pruebas de aceptación de la historia., Las pruebas de aceptación se escriben utilizando el lenguaje de dominio del sistema con desarrollo impulsado por el comportamiento (BDD). Las pruebas de BDD se automatizan y se ejecutan continuamente para mantener la calidad incorporada. Las pruebas BDD se escriben contra los requisitos del sistema (historias) y, por lo tanto, se pueden usar como la declaración definitiva para el comportamiento del sistema, reemplazando las especificaciones basadas en documentos.,

the 3Cs: Card, Conversation, Confirmation

Ron Jeffries, uno de los inventores de XP, se le atribuye la descripción de los 3Cs de una historia:

• Card – captura la declaración de intención de la historia del usuario utilizando una tarjeta de índice, nota adhesiva o herramienta. Las fichas proporcionan una relación física entre el equipo y la historia. El tamaño de la tarjeta limita físicamente la longitud de la historia y las sugerencias prematuras para la especificidad del comportamiento del sistema., Las cartas también ayudan al equipo a «sentir» el alcance próximo, ya que hay algo materialmente diferente en tener diez cartas en la mano en lugar de mirar diez líneas en una hoja de cálculo.
• conversación: representa una «promesa para una conversación» sobre la historia entre el equipo, el cliente (o el representante del cliente), el PO (que puede representar al cliente) y otras partes interesadas. La discusión es necesaria para determinar el comportamiento más detallado requerido para implementar la intención., La conversación puede generar especificidad adicional en forma de criterios de aceptación (la confirmación a continuación) o archivos adjuntos a la historia del usuario. La conversación abarca todos los pasos del ciclo de vida de la historia:
  • refinamiento del Backlog
  • Planificación
  • implementación
  • Demo

estas discusiones justo a tiempo crean una comprensión compartida del alcance que la documentación formal no puede proporcionar. La especificación por ejemplo reemplaza la documentación detallada. Las conversaciones también ayudan a descubrir brechas en escenarios de usuario y NFRs.,

• Confirmación: los criterios de aceptación proporcionan la información necesaria para garantizar que la historia se implementa correctamente y cubre las funciones y NFR relevantes. La figura 5 proporciona un ejemplo. Algunos equipos a menudo usan la sección de confirmación de la tarjeta de historia para anotar lo que demostrarán.

Los equipos ágiles automatizan las pruebas de aceptación siempre que sea posible, a menudo en un lenguaje legible para el negocio y específico del dominio., Automation crea una especificación ejecutable para validar y verificar la solución. La automatización también proporciona la capacidad de probar rápidamente el sistema de regresión, mejorando la integración continua, la refactorización y el mantenimiento.,>Invest in Good Stories

el modelo INVEST, desarrollado por Bill Wake , describe las características de las buenas historias de usuario:

• I – independiente (entre otras historias)
• N – negociable (una declaración de intenciones flexible, no un contrato)
• V – Valuable (proporcionando un segmento vertical valioso al cliente)
• E – Estimable (pequeño y negociable)
• S – pequeño (encaja dentro de una iteración)
• T – testable (lo suficientemente entendido como para saber cómo probarlo)

estimating stories

los equipos ágiles usan story points y ‘estimating poker’ para valorar su trabajo ., Un punto de historia es un número singular que representa una combinación de cualidades:

• volumen – ¿cuánto hay?
• Complejidad – ¿qué tan difícil es?
• Conocimiento – ¿qué se sabe?
• incertidumbre – ¿qué es Desconocido?

Los puntos de la historia son relativos, sin conexión a ninguna unidad de medida específica. El tamaño (esfuerzo) de cada historia se estima en relación con la historia más pequeña, que se asigna un tamaño de ‘uno.’Una secuencia de Fibonacci modificada(1, 2, 3, 5, 8, 13, 20, 40, 100) se aplica que refleja la incertidumbre inherente en la estimación, especialmente grandes números (e.,g., 20, 40, 100).

Estimating Poker

Los equipos ágiles a menudo usan ‘estimating poker’, que combina la opinión de expertos, la analogía y la desagregación para crear estimaciones rápidas pero confiables. La desagregación se refiere a dividir una historia o características en piezas más pequeñas y fáciles de estimar.

(tenga en cuenta que hay una serie de otros métodos utilizados también.) Las reglas de estimating poker son:

• Los participantes incluyen a todos los miembros del equipo.
• a cada estimador se le da una baraja de cartas con 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ¿y,?
• El PO participa pero no estima.,
• El Scrum Master participa pero no estima, a menos que esté haciendo un trabajo de desarrollo real.
• para cada elemento de backlog a estimar, el PO lee la descripción de la historia.
• Las preguntas se hacen y responden.
• Cada estimador selecciona de forma privada una carta de estimación que representa su estimación.
• Todas las cartas se dan la vuelta al mismo tiempo para evitar sesgos y hacer visibles todas las estimaciones.
• los estimadores altos y bajos explican sus estimaciones.
• después de una discusión, cada estimador vuelve a estimar seleccionando una tarjeta.,
• Las estimaciones probablemente convergerán. Si no, el proceso se repite.

cierta cantidad de discusión preliminar sobre el diseño es apropiada. Sin embargo, gastar demasiado tiempo en discusiones de diseño a menudo es un esfuerzo desperdiciado. El verdadero valor de estimar el poker es llegar a un acuerdo sobre el alcance de una historia. También es divertido!

velocidad

La velocidad del equipo para una iteración es igual a la suma de los puntos para todas las historias completadas que cumplan con su definición de hecho (DoD)., A medida que el equipo trabaja en conjunto con el tiempo, su velocidad promedio (puntos de historia completados por iteración) se vuelve confiable y predecible. Predictable velocity ayuda con la planificación y ayuda a limitar el trabajo en proceso (WIP), ya que los equipos no asumen más historias de las que su velocidad histórica permitiría. Esta medida también se utiliza para estimar cuánto tiempo se tarda en entregar epics, características, capacidades y habilitadores, que también se pronostican utilizando puntos de historia.

capacidad

La capacidad es la parte de la velocidad del equipo que está realmente disponible para cualquier iteración dada., Las vacaciones, la capacitación y otros eventos pueden hacer que los miembros del equipo no estén disponibles para contribuir a los objetivos de una iteración para alguna parte de la iteración. Esto disminuye la velocidad potencial máxima para ese equipo para esa iteración. Por ejemplo, un equipo que promedia 40 puntos entregados por iteración ajustaría su velocidad máxima a 36 si un miembro del equipo está de vacaciones durante una semana. Sabiendo esto de antemano, el equipo solo se compromete a un máximo de 36 puntos de historia durante la planificación de la iteración., Esto también ayuda durante la planificación de PI a pronosticar la capacidad disponible real para cada iteración en el PI para que el equipo no se comprometa demasiado en la construcción de sus objetivos de PI.

línea de base inicial para la estimación

en Scrum estándar, la estimación del punto de la historia de cada equipo—y la velocidad resultante—es una preocupación local e independiente. A escala, se hace difícil predecir el tamaño del punto de la historia para épicas y características más grandes cuando las velocidades del equipo pueden variar enormemente., Para superar esto, los equipos seguros inicialmente calibran una línea de base de punto de partida de la historia donde un punto de historia se define aproximadamente igual en todos los equipos. No hay necesidad de recalibrar la estimación del equipo o la velocidad. La calibración se realiza una sola vez al lanzar nuevos trenes de liberación ágil.

los puntos de historia normalizados proporcionan un método para llegar a una línea de base inicial acordada para las historias y la velocidad de la siguiente manera:

• dé a cada desarrollador-probador en el equipo ocho puntos por una iteración de dos semanas (un punto por cada día de trabajo ideal, restando 2 días para gastos generales).,
• reste un punto por cada día de vacaciones y vacaciones de los miembros del equipo.
• encontrar una pequeña historia que tomaría alrededor de medio día para codificar y medio día para probar y validar. Llámalo uno.’
• estimar cada otra historia relativa a ese ‘ uno.’

ejemplo: suponiendo un equipo de seis personas compuesto por tres desarrolladores, dos probadores y un PO, sin vacaciones o días festivos, entonces la velocidad inicial estimada = 5 × 8 puntos = 40 puntos/iteración. (Nota: ajustar un poco más bajo puede ser necesario si uno de los desarrolladores y probadores es también el Scrum Master.,)

de esta manera, los puntos de historia son algo comparables entre equipos. La administración puede comprender mejor el costo de un punto de la historia y determinar con mayor precisión el costo de una próxima función o épica.

mientras que los equipos tienden a aumentar su velocidad con el tiempo—y eso es algo bueno— en realidad, el número tiende a permanecer estable. La velocidad de un equipo se ve mucho más afectada por el cambio de tamaño del equipo y el contexto técnico que por las variaciones de productividad.,

dividir historias

Las historias más pequeñas permiten una implementación más rápida y confiable, ya que los elementos pequeños fluyen a través de cualquier sistema más rápido, con menos variabilidad y menor riesgo. Por lo tanto, dividir historias más grandes en historias más pequeñas es una habilidad obligatoria para cada equipo ágil. Es tanto el arte como la ciencia del desarrollo incremental. Diez formas de dividir historias se describen en los requisitos de software ágil de Leffingwell ., A continuación se presenta un resumen de estas técnicas:

• pasos del flujo de trabajo
• variaciones de reglas de Negocio
• esfuerzo mayor
• simple/complejo
• variaciones en los datos
• Métodos de entrada de datos
• Crear, leer, actualizar, eliminar )
• escenarios de casos de uso
• Punto de ruptura

La Figura 6 ilustra un ejemplo de división por escenarios de casos de uso.

historias en el modelo de requisitos seguros

como se describe en el artículo del modelo de requisitos Seguros, El marco aplica un amplio conjunto de artefactos y relaciones para administrar la definición y las pruebas de sistemas complejos de manera ágil y ágil. La figura 7 ilustra el papel de las historias en este panorama más amplio.

a escala, las historias son a menudo (pero no siempre) creadas por nuevas características. Y cada historia tiene pruebas de aceptación y probables pruebas unitarias. Las pruebas unitarias sirven principalmente para asegurar que la implementación técnica de la historia es correcta. Además, este es un punto de partida crítico para la automatización de pruebas, ya que las pruebas unitarias se automatizan fácilmente, como se describe en el artículo Desarrollo impulsado por pruebas (TDD).

más información

Leffingwell, Dean., Requisitos de software ágil: prácticas de requisitos ajustados para equipos, programas y la empresa. Addison-Wesley, 2011. Cohn, Mike. Historias De Usuario Aplicadas: Para El Desarrollo Ágil De Software. Addison-Wesley, 2004.

Última actualización: 17 de diciembre de 2019