¿Qué es Agile?

Completado

Hemos usado el término agile en el módulo anterior para describir uno de los elementos esenciales de la cultura de DevOps, que representa la capacidad de responder rápidamente a los comentarios y necesidades de los clientes. Este término también apareció varias veces en la unidad que describe la correlación entre DevOps y el ciclo de vida de la aplicación. Sin embargo, también hay otro significado más específico de Agile (en el formato en mayúsculas), que describe un enfoque para el desarrollo de software y la administración de proyectos. Este enfoque se asocia normalmente con las prácticas de DevOps. En nuestro escenario de ejemplo, la transición desde el enfoque tradicional de Cascada a Agile ayudaría a la organización a obtener una variedad de ventajas de DevOps. En esta unidad, explore las características principales de Agile y examine su correlación con DevOps.

Principios y valores ágiles

Agile es un enfoque para el desarrollo de software que promueve la colaboración en equipo, la mejora continua y la automatización, con el objetivo final de la entrega de software más rápida, confiable y centrada en el cliente. El término se originó en agile Manifesto, creado en 2001 por un grupo de desarrolladores de software, proporcionando un conjunto de principios rectores para el desarrollo de software moderno. El manifiesto incluía cuatro afirmaciones fundamentales que priorizaban a individuos e interacciones, soluciones de trabajo y colaboración de clientes sobre procesos y herramientas rígidos. En concreto, estas instrucciones asignaban más valor a:

• Individuos e interacciones sobre procesos y herramientas.
• Software de trabajo sobre documentación general.
• Colaboración con el cliente en lugar de negociación de contratos.
• Respuesta al cambio sobre seguimiento de un plan.

Procedimientos y métodos ágiles

El Manifiesto Ágil y los principios ágiles proporcionan un conjunto de valores y directrices, pero intencionadamente no son prescriptivos en términos de métodos y prácticas específicas. En su lugar, Agile está diseñado para ser flexible y fácilmente adaptable, lo que permite a las organizaciones y equipos elegir un enfoque más detallado según sus preferencias y necesidades.

Estos enfoques detallados y completos se conocen normalmente como marcos. Su propósito es cubrir todas las fases del ciclo de vida de DevOps, incluido el planeamiento, el desarrollo, la entrega y las operaciones. Algunos de los marcos agile más populares incluyen Scrum y Kanban.

¿Qué es Scrum?

Scrum es un marco utilizado por los equipos para administrar el trabajo y resolver problemas de forma colaborativa en breves (normalmente entre una y cuatro semanas) iteraciones denominadas sprints. Para facilitar la colaboración y el progreso, los sprints se estructuran en función de eventos, artefactos y roles.

• Los eventos, comúnmente conocidos como ceremonias, incluyen reuniones que tienen lugar diariamente (Daily Scrum, normalmente limitado a 15 minutos, también conocido como standup diario) y al principio y al final de cada sprint (Planeamiento de sprint, Revisión de sprint y Retrospectiva de sprint).
• Los artefactos definen una lista prioritaria de características, mejoras y correcciones que se van a desarrollar. Estos artefactos pueden abarcar el intervalo de un proyecto o un sprint (Trabajo pendiente de producto o Trabajo pendiente de sprint, respectivamente), o podrían ayudar en reuniones diarias de Scrum (paneles de tareas y gráficos de evolución de sprint). Un panel de tareas proporciona una manera visual de realizar un seguimiento del progreso de cada elemento de trabajo pendiente. Muestra los elementos de trabajo pendiente divididos en las tareas necesarias para completarlo. Las tareas se colocan en columnas independientes (etiquetadas Como hacer, En curso y Listo) en función de su estado. El gráfico de evolución de sprint sirve como indicador visual de si el equipo va por buen camino para completar el trabajo asignado al final del sprint. Consta de un gráfico que muestra el total diario del trabajo restante, que normalmente se muestra en horas.
• Los roles incluyen el propietario del producto, el maestro de Scrum y el equipo de Scrum, cada uno con sus responsabilidades claramente definidas. El propietario del producto representa a las partes interesadas del proyecto y es responsable de definir, mantener y priorizar el trabajo pendiente del producto. El maestro de Scrum supervisa el proceso de Scrum, busca áreas para mejorar, resolver cualquier problema de bloqueo y asegurarse de que se siguen los principios de Scrum. El equipo de Scrum es responsable de construir el producto, asumiendo la responsabilidad de sus componentes de ingeniería y calidad.

En el evento Sprint Planning, el equipo elige los elementos pendientes en los que trabajar durante el próximo sprint. La selección se realiza en función de la prioridad y de una cantidad estimada de trabajo necesaria para completar un elemento. La métrica denominada velocidad se usa para medir la cantidad de trabajo que un equipo puede completar en un sprint determinado. Una vez iniciada la ejecución del sprint, el equipo decide cómo trabajar en los elementos de trabajo pendiente de Sprint. Durante la revisión de Sprint, el equipo demuestra sus logros a las partes interesadas. La fase Retrospectiva de sprint forma parte del aprendizaje continuo. Sirve como la oportunidad de revisar el sprint completado más recientemente, identificar áreas para mejorar y ayudar a determinar la lista de acciones para el siguiente sprint.

¿Qué es Kanban?

Kanban es la palabra japonesa para un cartel o una cartelera. En el contexto de Agile, el concepto de Kanban se ha concebido como un medio para mejorar la eficiencia de los procesos de fabricación, pero, en los últimos años, se convirtió en frecuente en los proyectos de desarrollo de software.

El principio clave de este enfoque es la visualización del trabajo relacionado con el proyecto en forma de paneles Kanban. Pueden ser paneles físicos o aplicaciones de software que muestran tarjetas organizadas en columnas que representan el estado de los elementos de proyecto individuales. Los nombres de columna usados habitualmente incluyen Tareas pendientes, Hacer y Listo, aunque los equipos pueden personalizarlos para reflejar con precisión todas las fases pertinentes en un flujo de trabajo de entrega de proyectos (como desarrollo y pruebas). La visualización del trabajo como tarjetas en diferentes estados en un panel simplifica la evaluación del estado del proyecto y la identificación de posibles problemas de productividad.

Estas tarjetas se corresponden a los elementos de trabajo pendiente del producto en el marco de Scrum. Las tarjetas se pueden personalizar para incluir referencias a otros elementos en el proceso de entrega del producto, como tareas y casos de prueba.

Aunque el concepto de trabajo pendiente es común en Kanban y Scrum, es importante tener en cuenta que Kanban es más flexible y no implica iteraciones. Los elementos de trabajo se pueden agregar, reprioritizar o quitar del backlog según la capacidad del equipo y las necesidades cambiantes del proyecto o servicio que se administra con Kanban.

En concreto, Kanban promueve el uso de un modelo de extracción, en el que las partes interesadas agregan solicitudes a la lista de tareas, elementos o trabajo pendientes que deben completarse. El equipo de desarrollo selecciona los elementos del trabajo pendiente y los agrega al proceso de trabajo activo en función de su prioridad y de la disponibilidad de los recursos del equipo. Esto minimiza los problemas de calidad asociados al modelo de extracción, en el que las partes interesadas asignan arbitrariamente trabajo a los equipos de desarrollo, con frecuencia con fechas límite poco realistas. Además, para optimizar la productividad, Kanban admite la imposición de límites en el número de elementos en los que el equipo de desarrollo está trabajando actualmente, denominado trabajo en curso o simplemente WIP.

El marco Kanban también se basa en métricas de tiempo de ejecución y tiempo de ciclo para medir la eficacia y el rendimiento de su flujo de trabajo. El tiempo de espera es el tiempo total que tarda un elemento de trabajo en realizar la transición desde su inicio hasta su entrega al cliente. El tiempo de ciclo representa la duración del trabajo real en una tarea cuando ingresa en el estado de trabajo activo.

Otro componente usado habitualmente de Kanban es un diagrama de flujo acumulativo (CFD). Se trata de un gráfico que muestra el número de elementos de cada estado a lo largo del tiempo, normalmente en varias semanas. Se parece a un gráfico de series temporales apiladas, con el eje horizontal que representa la escala de tiempo y el eje vertical que representa el número acumulado de elementos de trabajo. Cada estado se muestra como un área de color diferente, lo que facilita la identificación de tendencias en el procesamiento de elementos de trabajo pendiente. Un aumento del tamaño de una o más áreas coloreadas suele indicar un problema en el flujo de trabajo, como un cuello de botella o una ineficacia.

¿Cuáles son las diferencias entre Scrum y Kanban?

Tanto Scrum como Kanban se consideran marcos ágiles con el objetivo común de mejorar la eficiencia y la eficacia del desarrollo de software. Sin embargo, cada uno de ellos ofrece un enfoque diferente para alcanzar este objetivo, incluidos sus respectivos principios y prácticas. En particular:

• Cadencia de trabajo: Scrum usa sprints de longitud fija, mientras que Kanban funciona en función de un modelo de flujo continuo, con el trabajo que los equipos de desarrollo extraen según la disponibilidad de sus recursos.
• Roles y ceremonias: Scrum ha definido claramente roles y ceremonias, mientras que Kanban no prescribe ninguno, sino que permite a los equipos adaptarlos según sus necesidades específicas.
• Planificación del trabajo: Scrum usa un trabajo pendiente priorizado con trabajo comprometido durante la planificación del sprint. Kanban usa un trabajo pendiente dinámico, sin compromisos durante un período específico. Además, Kanban admite el concepto de límites de WIP.
• Capacidad de adaptación para cambiar: Scrum desaconseja los cambios en el trabajo confirmado durante el sprint. Kanban facilita la adaptación a los cambios en cualquier momento.
• Visualizaciones: Scrum usa tablas de sprint y gráficos de agotamiento. Kanban se basa en paneles Kanban.
• métricas: Scrum usa métricas relacionadas con sprint, como gráficos de velocidad y de agotamiento. Kanban hace hincapié en métricas como tiempo de ejecución y tiempo de ciclo.