La historia de la caja fuerte
Las historias son el artefacto principal utilizado en Agile para definir el comportamiento del sistema. Son descripciones breves de funciones, normalmente escritas en el idioma del usuario desde la perspectiva del usuario. El propósito de cada historia es implementar una pequeña parte vertical del comportamiento del sistema para respaldar el desarrollo incremental.
Esta historia proporciona suficiente información para que los empresarios y técnicos comprendan sus intenciones. Los detalles de la historia se retrasarán hasta que esté lista para su implementación. A través de criterios de aceptación y pruebas de aceptación, la historia se vuelve más concreta y ayuda a garantizar la calidad del sistema.
Las historias de usuarios ofrecen funcionalidad directamente a los usuarios finales. Las historias facilitadoras brindan visibilidad de los elementos de trabajo necesarios para respaldar el descubrimiento, la arquitectura, la infraestructura y el cumplimiento.
El modelo de requisitos de SAFe describe la estructura de cuatro capas de los artefactos, que describe el comportamiento de un sistema funcional: epopeyas, capacidades, características e historias. Describen todo el trabajo necesario para crear el comportamiento esperado de la solución. Pero el trabajo de implementación detallado se describe con historias, y estas historias constituyen el Backlog del equipo. La mayoría de las historias provienen de funciones empresariales y habilitantes en el Planning Backlog, y algunas historias provienen del trabajo identificado por el equipo.
Cada historia es una pequeña acción independiente que se puede implementar gradualmente para aportar un valor determinado al usuario o solución. Es una característica de corte vertical que garantiza que cada iteración aporte un nuevo valor. Para dividir la historia en partes relativamente pequeñas, se debe hacer en una iteración (consulte la sección sobre cómo dividir la historia).
A menudo, las historias se escriben primero en fichas o notas adhesivas. La naturaleza física de las fichas crea una relación tangible entre el equipo, la historia y el usuario: ayuda a todo el equipo a participar en la escritura de la historia. Las notas post-it ofrecen otros beneficios: facilitan la visualización del trabajo y pueden colocarse fácilmente en una pared o mesa, reorganizarse en orden o incluso circular cuando sea necesario. Las historias brindan una mejor comprensión del alcance y el progreso del trabajo:
Si bien cualquiera puede escribir historias, es responsabilidad del propietario del producto aprobarlas en el trabajo pendiente del equipo y aceptarlas en la línea base del sistema. Por supuesto, las notas adhesivas no se adaptan bien a toda la empresa, por lo que las historias a menudo se trasladan rápidamente a herramientas ALM (Agile Lifecycle Management).
En SAFe, hay dos tipos de historias, historias de usuario e historias de autorización, como se describe a continuación.
Como se muestra en la Figura 1, las historias a menudo están impulsadas por la separación del negocio y las funciones habilitadoras.
Las historias de usuario son la forma principal de expresar la funcionalidad deseada. Han reemplazado en gran medida las especificaciones de requisitos tradicionales. (En algunos casos, sin embargo, se pueden utilizar para interpretar y desarrollar el comportamiento del sistema, que luego se puede documentar para respaldar el cumplimiento, la trazabilidad u otros requisitos).
Porque se centran en la percepción del usuario. interés, no el sistema, por lo que las historias de usuarios se centran en el valor. Para respaldar esto, se recomienda un formato de 'voz de usuario', como se muestra a continuación:
Al usar este formulario, guíe al equipo para que comprenda quién está usando el sistema, para qué lo está usando y por qué lo están usando Haga esto. El uso frecuente de la "voz del usuario" a menudo mejora las capacidades de dominio del equipo; comprenderán mejor las necesidades comerciales reales de los usuarios. La figura 2 proporciona un ejemplo.
Las personas describen las características específicas de los usuarios representativos y pueden ayudar a los equipos a comprender mejor a sus usuarios finales. Ejemplos de personajes jinetes en la Figura 2 podrían ser una emocionante "Jane" y un tímido jinete "Bob". La descripción de la historia luego hace referencia a estos personajes (como Jane, ojalá...).
Si bien la voz de las historias de usuario es común, no todos los sistemas interactúan con los usuarios finales. A veces, un "usuario" es un dispositivo (como una impresora) o un sistema (como un servidor comercial). En estos casos, la historia puede tomar la forma que se muestra en la Figura 3.
Es posible que el equipo necesite desarrollar una arquitectura o infraestructura del sistema para implementar algunas historias de usuario o componentes de soporte del sistema.
En este caso, es posible que la historia no llegue directamente a ningún usuario final. Estas son historias de éxito que respaldan la exploración, la arquitectura o la infraestructura. La historia de habilitación se puede expresar en un lenguaje técnico en lugar de centrado en el usuario, como se muestra en la Figura 4.
Existen muchos otros tipos de historias de habilitación, entre ellas:
Al igual que las historias de usuarios, las historias de habilitación suelen demostrar conocimientos adquiridos, artefactos o interfaces de usuario fabricados, pilas o simulaciones para mostrar.
Una buena historia requiere múltiples perspectivas. En Agile, todo el equipo (propietario del producto, desarrolladores y evaluadores) tiene un entendimiento común de lo que se está construyendo para reducir el retrabajo y aumentar el rendimiento. Los equipos utilizan el desarrollo impulsado por el comportamiento (BDD) para colaborar, definir pruebas de aceptación detalladas y describir claramente cada historia. Las buenas historias requieren pensar desde múltiples perspectivas:
Escribir una historia juntos garantiza que se consideren todos los puntos de vista y que todos tengan una * * * comprensión del comportamiento de la historia. Los resultados se reflejan en la descripción y la aceptación. de la historia. Bajo estándares y pruebas de aceptación. Las pruebas de aceptación se escriben utilizando el lenguaje de dominio del sistema y el desarrollo impulsado por el comportamiento (BDD). Luego, las pruebas BDD se ejecutan automáticamente y de forma continua para mantener la calidad incorporada. Las pruebas BDD se escriben en función de los requisitos del sistema (historias), por lo que sirven como una declaración determinista del comportamiento del sistema en lugar de una especificación basada en documentos.
Ron Jeffries, uno de los inventores de las pruebas de aceptación. La automatización crea una especificación ejecutable para verificar y validar la solución. La automatización también proporciona la capacidad de realizar pruebas rápidas de regresión del sistema, mejorando así las capacidades de integración, reconfiguración y mantenimiento continuos.
El modelo de inversión desarrollado por Bill Wake [1] describe las características de una buena historia de usuario:
Los equipos ágiles utilizan puntos de historia y "póker de evaluación" para evaluar su trabajo [1, 2]. Un punto de la historia es un número único que representa una combinación de las siguientes características:
Los puntos de la historia son relativos y no están vinculados a ninguna unidad de medida específica. El tamaño (esfuerzo) de cada piso se estima en relación con el piso más pequeño, al que se le asigna un tamaño de "1". Aplicar la secuencia de Fibonacci modificada (1, 2, 3, 5, 8, 13, 20, 40, 100) para reflejar la incertidumbre inherente a las estimaciones, especialmente para números grandes (como 20, 40, 100) [
Los equipos ágiles suelen utilizar el "póquer de evaluación", que combina opiniones de expertos, analogías y desgloses para crear estimaciones rápidas pero fiables. La descomposición se refiere a dividir una historia o artículo en partes más pequeñas para una evaluación más sencilla.
(Tenga en cuenta que existen otros métodos en uso). Las reglas de Estimation Poker son:
Sería apropiado tener algunas discusiones preliminares sobre el diseño. Sin embargo, dedicar demasiado tiempo a discusiones sobre diseño suele ser un desperdicio de energía. El valor real al evaluar el póquer está en ponerse de acuerdo sobre el alcance de una historia. ¡También es un placer!
La velocidad del equipo en una iteración es igual a la suma de puntos de historia de todas las historias completadas que cumplen con la Definición de Hecho (DoD). A medida que el equipo continúe trabajando en conjunto, su velocidad promedio (puntos de la historia completados por iteración) se volverá confiable y predecible. La velocidad predecible ayuda a planificar y limitar el WIP porque los equipos no asumen más historias de las que permite su velocidad histórica. Este enfoque también se utiliza para estimar el tiempo necesario para ofrecer epopeyas, características, capacidades y habilitadores, que también se pueden predecir mediante el uso de puntos de la historia.
La capacidad se refiere a la parte del ratio del equipo que realmente se puede utilizar en cualquier iteración particular. Las vacaciones, la formación y otros eventos impedirán que los miembros del equipo contribuyan a los objetivos de la iteración en determinadas partes. Esto reduce la velocidad potencial máxima del equipo para esa iteración. Por ejemplo, en un equipo que obtiene un promedio de 40 puntos por iteración, si un miembro del equipo se toma una semana libre, su puntuación máxima se ajustará a 36 puntos. Sabiendo esto de antemano, el equipo solo se comprometió con un máximo de 36 puntos de historia durante la planificación de la iteración.
Esto también ayuda a predecir la capacidad real disponible para cada iteración del PI durante la planificación del PI, de modo que el equipo no se comprometa demasiado al establecer los objetivos del PI.
En Scrum estándar, la estimación de puntos de la historia de cada equipo y la proporción resultante es un asunto independiente dentro del equipo. Desde una perspectiva de agilidad de escala, será difícil predecir el tamaño de los puntos de la historia para epopeyas y características más grandes cuando las líneas base de velocidad varían ampliamente entre equipos. Para superar este problema, el equipo SAFe primero calibrará una línea base de punto de historia inicial donde todos los equipos tienen aproximadamente la misma definición de punto de historia. No es necesario recalibrar las evaluaciones o proporciones del equipo. La calibración se realizará cuando se lance una nueva serie de versiones ágiles.
Los Story Points estandarizados proporcionan una manera para que las historias y las tarifas alcancen una base inicial acordada, como se muestra a continuación:
Ejemplo: supongamos que un equipo de 6 personas desarrollado por 3 consta de personal, 2 testers y 1 PO, sin licencias ni días festivos, entonces la tasa inicial estimada = 5 × 8 puntos = 40 puntos/iteración. (Nota: si uno de los desarrolladores y evaluadores trabaja a tiempo parcial, es posible que sea necesario reducirlo).
De esta forma, los puntos de historia de cada equipo serán comparables. La gerencia puede comprender mejor el costo de los puntos de la historia y determinar con mayor precisión el costo de las próximas funciones o epopeyas.
Si bien es bueno que los equipos tiendan a aumentar la velocidad con el tiempo, la realidad es que este número tiende a permanecer estable. La velocidad de un equipo se ve mucho más afectada por los cambios en el tamaño del equipo y el entorno técnico que por los cambios en la productividad.
Las historias más pequeñas conducirán a implementaciones más rápidas y confiables porque los proyectos pequeños son más rápidos, menos variables y menos riesgosos en cualquier sistema. Por lo tanto, dividir una historia más grande en historias más pequeñas es una habilidad esencial para todo equipo ágil. Este no es sólo el arte del desarrollo incremental, sino también una ciencia. Los requisitos de software ágiles de Leffingwell [1] presentan diez formas de dividir historias. El siguiente es un resumen de estas técnicas:
La Figura 6 muestra un ejemplo de segmentación de escenarios de casos de uso:
Como se describe en el artículo "Modelo de requisitos de seguridad", este marco aplica una serie de artefactos y conexiones para gestionar la definición y pruebas de sistemas complejos de una manera ágil y eficiente. La Figura 7 ilustra el papel de las historias en el panorama general de SAFE.
En la agilidad escalable, las historias a menudo (pero no siempre) se crean a partir de nuevas funciones. Y cada historia tiene pruebas de aceptación y posiblemente pruebas unitarias. Las pruebas unitarias tienen como objetivo principal garantizar que la implementación técnica de la historia sea correcta. Al mismo tiempo, también es un punto de partida clave para la automatización de pruebas, ya que las pruebas unitarias se pueden automatizar fácilmente, como se describe en el artículo Test-Driven Development (TDD).
Nota: La Figura 7 utiliza la notación del Lenguaje Unificado de Modelado (UML) para representar la relación entre objetos: cero a muchos (0...*), uno a muchos (1...*), uno a uno (1) y así sucesivamente.
Última actualización: 17 de diciembre de 2019