Tema 1.2 - Aspectos de los enfoques ágiles

Enfoques de desarrollo de software ágil

En este apartado, veremos algunos de los enfoques ágiles más utilizados al día, que implementan los valores y principios del Manifiesto Ágil de diferentes formas, los cuales son: Extreme Programming (XP), Scrum y Kanban

Extreme Programming:

Este es un enfoque ágil de desarrollo de software descrito por ciertos valores, principios y prácticas de desarrollo, abarca cinco valores, la comunicación, la sencillez, la retroalimentación, el valor y el respeto, dentro de los principios contempla como directrices adicionales, la humanidad, economía, beneficio mutuo, autocontrol similitud, mejora, diversidad, reflexión, flujo, oportunidad, redundancia, falla, calidad, pequeños pasos, y aceptación de la responsabilidad; como prácticas se resaltan trece principales:  

1. sentarse juntos
2. todo el equipo
3. espacio de trabajo informativo
4. energizado trabajo
5. programación de pares
6.  historias
7. ciclo semanal
8. ciclo trimestral
9. holgura
10. construcción de diez minutos
11. continuo integración
12. prueba de primera programación 
13. diseño incremental.

 

Scrum:

Scrum es un marco de gestión ágil que está constituido por los siguientes instrumentos y prácticas:

o   Sprint: Scrum divide un proyecto en iteraciones (llamados sprints) de longitud fija, usualmente de dos a cuatro semanas

o   Incremento del producto: Cada sprint resulta en un producto potencialmente liberable/enviable, llamado incremento.

o   Product backlog: El product owner gestiona una lista priorizada de elementos del producto planificados (Product backlog). Este evoluciona de un sprint a otro (refinamiento del producto)

o   Sprint Backlog: Al inicio de cada sprint, el equipo scrum selecciona un conjunto de elementos altamente priorizados (llamados sprint backlog) desde el product backlog. Dado que el equipo Scrum, no el product owner o propietario del producto, selecciona los elementos que se realizarán dentro del sprint, esta es referenciada basado en el principio de extracción en lugar del principio de empuje.

o   Definición de hecho: Para asegurarse de que haya un producto potencialmente liberable al final de cada sprint, el equipo de Scrum analiza y define los criterios adecuados para la finalización del sprint. La discusión profundiza la comprensión del equipo sobre los elementos de backlog y los requisitos del producto.

o   Timeboxing: Solo aquellas tareas, requisitos o características que el equipo espera terminar dentro del sprint son parte del backlog del sprint. Si el equipo de desarrollo no puede finalizar una tarea dentro de un sprint, las características del producto asociadas se eliminan del sprint y la tarea se mueve de nuevo al backlog del producto. El timeboxing se aplica no solo a las tareas, sino en otras situaciones (por ejemplo, hacer cumplir las horas de inicio y finalización de la reunión).

o   Transparencia: el equipo de desarrollo informa y actualiza el estado del sprint a diario en una reunión llamada scrum diario. Esto hace que el contenido y el progreso del sprint actual, incluidos los resultados de las pruebas, sean visibles para el equipo, la gerencia y todas las partes interesadas. Por ejemplo, el equipo de desarrollo puede mostrar el estado del sprint en una pizarra.

 

 

 

Cuenta con tres roles principales:

o   Scrum Master: es el encargado de asegurar que las prácticas y reglas de scrum se implementen y se sigan; además, resuelve cualquier violación, problema de recursos u otros impedimentos que podrían impedir que el equipo siga con las prácticas y reglas. Es de resaltar que este no es un líder de equipo, sino un entrenador.

o   Product Owner: representa al cliente y genera, mantiene y prioriza el product baclog. No es el líder del equipo

o   Development Team: desarrolla y prueba el producto. El equipo es auto-organizado: No hay un líder del equipo, por lo que el equipo toma sus decisiones. El equipo es además, multifuncional.

Kanban:

Kanban es un enfoque de gestión que a veces se utiliza en proyectos Agile. El objetivo general es visualizar y optimizar el flujo de trabajo dentro de una cadena de valor agregado. Kanban utiliza tres instrumentos

o   Kanban board (Tablero de kanban): La cadena de valor a gestionar se visualiza mediante un tablero Kanban. Cada columna muestra una estación, que es un conjunto de actividades relacionadas, por ejemplo, desarrollo o prueba. Los artículos que se producirán o las tareas que se procesarán están simbolizados por boletos que se mueven de izquierda a derecha a través del tablero a través de las estaciones.

o   Límite de trabajo en curso: la cantidad de tareas activas paralelas está estrictamente limitada. Esto está controlado por la cantidad máxima de boletos permitidos para una estación y / o globalmente para el tablero. Siempre que una estación tiene capacidad libre, el trabajador saca un boleto de la estación predecesora.

o   Tiempo de entrega: Kanban se utiliza para optimizar el flujo continuo de tareas minimizando el tiempo de entrega (promedio) para el flujo de valor completo.

Kanban presenta algunas similitudes con Scrum. En ambos marcos, la visualización de las tareas activas (por ejemplo, en una pizarra pública) proporciona transparencia del contenido y el progreso de las tareas. Las tareas que aún no están programadas están a la espera de una acumulación y se trasladan al tablero Kanban tan pronto como hay nuevo espacio (capacidad de producción) disponible.

Las iteraciones o los sprints son opcionales en Kanban. El proceso Kanban permite publicar sus entregables, artículo por artículo, en lugar de parte de un lanzamiento. El timeboxing como mecanismo de sincronización, por lo tanto, es opcional, a diferencia de Scrum, que sincroniza todas las tareas dentro de un sprint.

 

 

Creación colaborativa de historias de usuario

Las especificaciones deficientes son a menudo una de las principales razones del fracaso del proyecto. Los problemas de especificación pueden deberse a la falta de conocimiento de los usuarios sobre sus verdaderas necesidades, la ausencia de una visión global del sistema, características redundantes o contradictorias y otros errores de comunicación. En el desarrollo ágil, las historias de usuario se escriben para capturar los requisitos desde las perspectivas de los desarrolladores, evaluadores y representantes comerciales. En el desarrollo secuencial, esta visión compartida de una característica se logra mediante revisiones formales después de que se redactan los requisitos

La autoría colaborativa de la historia del usuario puede utilizar técnicas como lluvia de ideas y mapas mentales. El probador puede utilizar la técnica INVEST, que ayuda asegurar la calidad en la escritura de historias de usuario, bajo el cumplimiento de unas características:

• Independent (Independiente): Es ventajoso que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello las historias deberían de ser totalmente independientes (lo cual facilita el trabajo posterior del equipo). Resaltar que las dependencias entre historias de usuario pueden reducirse combinándolas en una o dividiéndolas de manera diferente.
• Negotiable (Negociable): Una historia de usuario es una descripción corta de una necesidad que no incluye detalles. Las historias deben ser negociables ya que sus detalles serán acordados con el cliente o el usuario durante la fase de conversación. Por tanto, se debe evitar historias de usuario con demasiados detalles porque limitaría la conversación acerca de las mismas.
• Valuable (Valioso): Una historia de usuario tiene que ser valiosa para el cliente o el usuario. Una manera de hacer una historia valiosa es que la escriba él mismo
• Estimable (Estimable): Una buena historia de usuario debe de poder ser estimada con la precisión suficiente para ayudar al cliente, usuario o propietario del producto a priorizar y planificar su implementación. La estimación generalmente la realizará el equipo de trabajo y está directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño es más difícil de estimar) y con el conocimiento del equipo de la necesidad expresada (en el caso de falta de conocimiento, serán necesarias más fases de conversación acerca de la misma).
• Small (Pequeño): Las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una descripción corta ayuda a disminuir el tamaño de una historia de usuario facilitando así su estimación.
• Testable (Comprobable): La historia de usuario debería ser capaz de ser probada (fase confirmación de la historia de usuario). Si el cliente o usuario no sabe cómo probar la historia de usuario significa que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.

Según el concepto 3C, una historia de usuario es la conjunción de tres elementos:

• Tarjeta: la tarjeta es el medio físico que describe una historia de usuario. Identifica el requisito, su criticidad, desarrollo esperado y duración de la prueba, y los criterios de aceptación para esa historia. La descripción debe ser precisa, ya que se utilizará en la cartera de pedidos del producto.
• Conversación: la conversación explica cómo se utilizará el software. La conversación puede ser documentada o verbal. Los evaluadores, que tienen un punto de vista diferente al de los desarrolladores y representantes comerciales, aportan información valiosa al intercambio de pensamientos, opiniones y experiencias. La conversación comienza durante la fase de planificación del lanzamiento y continúa cuando se programa la historia.
• Confirmación: Los criterios de aceptación, discutidos en la conversación, se utilizan para confirmar que la historia está terminada. Estos criterios de aceptación pueden abarcar varias historias de usuarios. Deben utilizarse pruebas tanto positivas como negativas para cubrir los criterios. Durante la confirmación, varios participantes desempeñan el papel de probadores. Estos pueden incluir tanto a desarrolladores como a especialistas que se centren en el rendimiento, la seguridad, la interoperabilidad y otras características de calidad. Para confirmar que una historia está hecha, se deben probar los criterios de aceptación definidos y demostrar que se cumplen.

Los equipos ágiles varían en términos de cómo documentan las historias de los usuarios. Independientemente del enfoque adoptado para documentar las historias de los usuarios, la documentación debe ser concisa, suficiente y necesaria.

 

Retrospectivas

En el desarrollo ágil, una retrospectiva es una reunión que se lleva a cabo al final de cada iteración para discutir qué fue exitoso, qué se podría mejorar y cómo incorporar las mejoras y retener los éxitos en iteraciones futuras. Las retrospectivas cubren temas como el proceso, las personas, las organizaciones, las relaciones y las herramientas. Las reuniones retrospectivas realizadas con regularidad, cuando se realizan las actividades de seguimiento adecuadas, son fundamentales para la auto-organización y la mejora continua del desarrollo y las pruebas.

Las retrospectivas pueden dar lugar a decisiones de mejora relacionadas con las pruebas que se centran en la eficacia de las pruebas, la productividad de las pruebas, la calidad de los casos de prueba y la satisfacción del equipo. También pueden abordar la capacidad de prueba de las aplicaciones, historias de usuario, funciones o interfaces del sistema. El análisis de la causa raíz de los defectos puede generar mejoras en las pruebas y el desarrollo. En general, los equipos deben implementar solo algunas mejoras por iteración. Esto permite una mejora continua a un ritmo sostenido.

El momento y la organización de la retrospectiva dependen del método ágil particular que se siga. Los representantes comerciales y el equipo asisten a cada retrospectiva como participantes mientras el facilitador organiza y dirige la reunión. En algunos casos, los equipos pueden invitar a otros participantes a la reunión.

Los probadores deben jugar un papel importante en las retrospectivas. Los evaluadores son parte del equipo y aportan su perspectiva única. Las pruebas ocurren en cada sprint y contribuyen de manera vital al éxito. Todos los miembros del equipo, probadores y no probadores, pueden aportar información tanto sobre las actividades de prueba como para las que no lo son.

Las retrospectivas deben producirse en un entorno profesional caracterizado por la confianza mutua. Los atributos de una retrospectiva exitosa son los mismos que los de cualquier otra revisión, como se analiza en el programa de estudios de nivel básico.

 

Integración continúa

La entrega de un incremento de producto requiere un software integrado, confiable y funcional al final de cada sprint. La integración continua aborda este desafío fusionando todos los cambios realizados en el software e integrando todos los componentes modificados con regularidad, al menos una vez al día. La gestión de la configuración, la compilación, la creación, la implementación y las pruebas de software están integradas en un proceso único, automatizado y repetible. Dado que los desarrolladores integran su trabajo constantemente, compilan constantemente y prueban constantemente, los defectos en el código se detectan más rápidamente.

Después de la codificación, depuración y registro del código por parte de los desarrolladores en un repositorio de código fuente compartido, un proceso de integración continuo consta de las siguientes actividades automatizadas:

• Análisis de código estático: ejecución de análisis de código estático e informes de resultados.
• Compilar: compilar y vincular el código, generar los archivos ejecutables
• Prueba unitaria: ejecutar las pruebas unitarias, verificar la cobertura del código e informar los resultados de las pruebas
• Implementar: instalar la compilación en un entorno de prueba
• Prueba de integración: ejecutar las pruebas de integración y reportar los resultados
• Informe (panel de control): publicar el estado de todas estas actividades en una ubicación públicamente visible o el estado de envío de correo electrónico al equipo

Un proceso de construcción y prueba automatizado se lleva a cabo a diario y detecta los errores de integración de manera temprana y rápida. La integración continua permite a los probadores ágiles ejecutar pruebas automatizadas con regularidad, en algunos casos como parte del proceso de integración continua en sí, y enviar comentarios rápidos al equipo sobre la calidad del código. Los resultados de estas pruebas son visibles para todos los miembros del equipo, especialmente cuando se integran informes automatizados en el proceso. Las pruebas de regresión automatizadas pueden ser continuas a lo largo de la iteración. Las buenas pruebas de regresión automatizadas cubren tanta funcionalidad como sea posible, incluidas las historias de usuario entregadas en las iteraciones anteriores. Una buena cobertura en las pruebas de regresión automatizada ayuda a respaldar la construcción (y prueba) de grandes sistemas integrados. Cuando se automatizan las pruebas de regresión, los probadores ágiles tienen la libertad de concentrar sus pruebas manuales en nuevas funciones, cambios implementados y pruebas de confirmación de corrección de defectos.

Además de las pruebas automatizadas, las organizaciones que utilizan la integración continua suelen utilizar herramientas de creación para implementar un control de calidad continuo. Además de ejecutar pruebas unitarias y de integración, estas herramientas pueden ejecutar pruebas estáticas y dinámicas adicionales, medir y perfilar el rendimiento, extraer y dar formato a la documentación del código fuente y facilitar los procesos manuales de garantía de calidad. Esta aplicación continua de control de calidad tiene como objetivo mejorar la calidad del producto, así como reducir el tiempo necesario para entregarlo, reemplazando la práctica tradicional de aplicar el control de calidad después de completar todo el desarrollo.

Las herramientas de compilación se pueden vincular a las herramientas de implementación automática, que pueden obtener la compilación adecuada del servidor de compilación o integración continua y desplegarla en uno o más entornos de desarrollo, prueba, preparación o incluso producción. Esto reduce los errores y retrasos asociados con la dependencia de personal especializado o programadores para instalar versiones en estos entornos.

La integración continua puede proporcionar los siguientes beneficios:

• Permite una detección más temprana y un análisis más sencillo de la causa raíz de los problemas de integración y cambios conflictivos
• Da al equipo de desarrollo comentarios regulares sobre si el código está funcionando
• Mantiene la versión del software que se está probando un día después de la versión que se está desarrollando
• Reduce el riesgo de regresión asociado con la refactorización del código del desarrollador debido a la rápida repetición de pruebas de la base del código después de cada pequeño conjunto de cambios.
• Brinda confianza en que el trabajo de desarrollo de cada día se basa en una base sólida
• Hace visible el progreso hacia la finalización del incremento de producto, alentando a los desarrolladores y probadores
• Elimina los riesgos de programación asociados con la integración Big-Bang
• Proporciona disponibilidad constante de software ejecutable a lo largo del sprint con fines educativos, de prueba o de demostración.
• Reduce las actividades de prueba manuales repetitivas
• Proporciona comentarios rápidos sobre las decisiones tomadas para mejorar la calidad y las pruebas.

Sin embargo, la integración continua no está exenta de riesgos y desafíos:

• Deben introducirse y mantenerse herramientas de integración continua
• Se debe definir y establecer el proceso de integración continua
• La automatización de pruebas requiere recursos adicionales y puede ser complejo de establecer
• Una cobertura de prueba completa es esencial para lograr las ventajas de las pruebas automatizadas
• Los equipos a veces confían demasiado en las pruebas unitarias y realizan muy pocas pruebas de aceptación y del sistema.

La integración continua requiere el uso de herramientas, incluidas herramientas de prueba, herramientas para automatizar el proceso de compilación y herramientas para el control de versiones.

 

Planificación de lanzamiento iteración

Como se menciona en el programa de estudios de nivel básico, la planificación es una actividad continua, y este es también el caso de los ciclos de vida ágiles. Para los ciclos de vida ágiles, se producen dos tipos de planificación, planificación de versiones y planificación de iteraciones.

La planificación del lanzamiento anticipa el lanzamiento de un producto, a menudo unos meses antes del inicio de un proyecto. La planificación del lanzamiento define y redefine la acumulación del producto y puede implicar refinar historias de usuarios más grandes en una colección de historias más pequeñas. La planificación de la versión proporciona la base para un enfoque de prueba y un plan de prueba que abarca todas las iteraciones. Los planes de lanzamiento son de alto nivel.

En la planificación del lanzamiento, los representantes comerciales establecen y priorizan las historias de usuario para el lanzamiento, en colaboración con el equipo. A partir de estas historias de usuarios, se identifican los riesgos del proyecto y de la calidad y se realiza una estimación del esfuerzo de alto nivel

Los probadores están involucrados en la planificación de versiones y, especialmente, agregan valor en las siguientes actividades:

• Definición de historias de usuario comprobables, incluidas los criterios de aceptación
• Participar en análisis de riesgos de proyectos y calidad
• Estimar el esfuerzo de prueba asociado con las historias de usuario.
• Definición de los niveles de prueba necesarios
• Planificación de las pruebas para el lanzamiento

Una vez realizada la planificación del lanzamiento, comienza la planificación de iteraciones para la primera iteración. La planificación de la iteración mira hacia el final de una única iteración y se ocupa de la acumulación de iteraciones.

En la planificación de la iteración, el equipo selecciona historias de usuarios de la lista de trabajos pendientes de publicación priorizada, elabora las historias de usuarios, realiza un análisis de riesgo para las historias de usuarios y estima el trabajo necesario para cada historia de usuario. Si una historia de usuario es demasiado vaga y los intentos de aclararla han fallado, el equipo puede negarse a aceptarla y usar la siguiente historia de usuario según la prioridad. Los representantes comerciales deben responder las preguntas del equipo sobre cada historia para que el equipo pueda comprender qué deben implementar y cómo probar cada historia.

El número de historias seleccionadas se basa en la velocidad del equipo establecido y el tamaño estimado de las historias de usuario seleccionadas. Una vez finalizado el contenido de la iteración, las historias de usuario se dividen en tareas, que serán llevadas a cabo por los miembros del equipo correspondientes.

Los probadores están involucrados en la planificación de la iteración y, especialmente, agregan valor en las siguientes actividades:

• Participar en el análisis detallado de riesgos de las historias de usuarios.
• Determinación de la capacidad de prueba de las historias de usuario.
• Creación de pruebas de aceptación para las historias de usuario.
• Desglosar historias de usuarios en tareas (particularmente tareas de prueba)
• Estimar el esfuerzo de prueba para todas las tareas de prueba.
• Identificar aspectos funcionales y no funcionales del sistema que se probará.
• Apoyar y participar en la automatización de pruebas en múltiples niveles de pruebas.

Los planes de lanzamiento pueden cambiar a medida que avanza el proyecto, incluidos los cambios en las historias de usuarios individuales en la cartera de pedidos del producto. Estos cambios pueden ser provocados por factores internos o externos. Los factores internos incluyen capacidades de entrega, velocidad y problemas técnicos. Los factores externos incluyen el descubrimiento de nuevos mercados y oportunidades, nuevos competidores o amenazas comerciales que pueden cambiar los objetivos de lanzamiento y / o las fechas previstas. Además, los planes de iteración pueden cambiar durante una iteración. Por ejemplo, una historia de usuario particular que se consideró relativamente simple durante la estimación podría resultar más compleja de lo esperado.

Estos cambios pueden ser un desafío para los evaluadores. Los evaluadores deben comprender el panorama general de la versión para fines de planificación de pruebas, y deben tener una base de prueba adecuada y un oráculo de prueba en cada iteración para fines de desarrollo de pruebas, como se explica en el programa de estudios de nivel básico. La información requerida debe estar disponible para el evaluador con anticipación y, sin embargo, el cambio debe adoptarse de acuerdo con los principios ágiles. Este dilema requiere decisiones cuidadosas sobre las estrategias de prueba y la documentación de prueba. Para obtener más información sobre los desafíos de las pruebas ágiles.

La planificación de versiones e iteraciones debe abordar la planificación de pruebas así como la planificación de las actividades de desarrollo. Los problemas particulares relacionados con las pruebas que se deben abordar incluyen:

• El alcance de las pruebas, el alcance de las pruebas para esas áreas en el alcance, los objetivos de las pruebas y las razones de estas decisiones.
• Los miembros del equipo que realizarán las actividades de prueba.
• El entorno de prueba y los datos de prueba necesarios, cuándo se necesitan y si se producirán adiciones o cambios en el entorno de prueba y / o datos antes o durante el proyecto.
• El tiempo, la secuenciación, las dependencias y los requisitos previos para las actividades de prueba funcionales y no funcionales (por ejemplo, con qué frecuencia ejecutar pruebas de regresión, qué características dependen de otras características o datos de prueba, etc.), incluida la forma en que las actividades de prueba se relacionan con y dependen de las actividades de desarrollo.
• El proyecto y los riesgos de calidad que se deben abordar

Además, el esfuerzo de estimación del equipo más grande debe incluir la consideración del tiempo y el esfuerzo necesarios para completar las actividades de prueba requeridas.