Conceptos Esenciales de Metodologías Ágiles: Scrum, Lean y Kanban

1. Pilares del Empirismo con Scrum

El empirismo en Scrum se basa en la idea de que el conocimiento proviene de la experiencia y la toma de decisiones se fundamenta en la observación. Scrum utiliza un enfoque iterativo e incremental para optimizar la predictibilidad y controlar el riesgo, implementando los pilares empíricos de Transparencia, Inspección y Adaptación.

Transparencia: Implica que todos deben tener acceso claro a la información. El trabajo y el proceso deben ser visibles para que todos entiendan el estado del producto. La transparencia es fundamental porque permite la inspección.
Inspección: Consiste en revisar el progreso en ciclos cortos de retroalimentación (como las Daily Scrums o las Sprint Reviews) para detectar a tiempo cualquier desviación o problema y adaptarse rápidamente si algo no funciona como se espera.
Adaptación: Si algo no va bien, se deben realizar cambios rápidos. El equipo se ajusta según lo que aprendió durante la fase de inspección.

Estos pilares son cimientos de Scrum, junto con el control de proceso empírico, la autoorganización y colaboración, la priorización basada en el valor, el time-boxing, y el desarrollo iterativo e incremental.

2. INVEST: Características de las User Stories (US)

El modelo INVEST es un conjunto de criterios de calidad incluido en la Definition of Ready (DoR) que permite verificar la calidad de las Historias de Usuario. Una User Story debe cumplir con este modelo en su totalidad para ser considerada de alta calidad.

Las características de una buena User Story, según el modelo INVEST, son:

I – Independiente (*Independent*): Las Historias de Usuario deben ser independientes entre sí. Deben poder desarrollarse, probarse e implementarse sin depender de otras historias. Esto le da libertad al Product Owner para priorizarlas como quiera.
N – Negociable (*Negotiable*): Se negocia el «Qué» (la funcionalidad) con el cliente, no el «Cómo» (la implementación técnica).
V – Valiosa (*Valuable*): Las historias deben proporcionar un valor tangible o intangible al cliente o usuario final. El valor se asocia a la utilidad, beneficio o satisfacción que se ofrece a los usuarios finales por cada funcionalidad completa que se entrega.
E – Estimable (*Estimatable*): Deben ser lo suficientemente claras y detalladas como para permitir una estimación precisa del esfuerzo requerido para su implementación. Si una historia es demasiado incierta, puede convertirse en una Spike para obtener el conocimiento necesario.
S – Pequeña (*Small*): Las Historias de Usuario deben ser lo suficientemente pequeñas como para poder completarse en una iteración (Sprint); de lo contrario, no pueden proporcionar ningún valor o considerarse realizadas en ese momento.
T – Testeable (*Testable*): Deben ser específicas y claras en cuanto a los criterios de aceptación, de manera que sea posible probar y verificar que se han implementado correctamente.

3. Scrum

Scrum no es una metodología o un proceso, es un marco de trabajo (framework) liviano que ayuda a personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos. Se basa en el empirismo y el pensamiento Lean, empleando un enfoque iterativo e incremental para optimizar la predictibilidad y controlar el riesgo.

Valores de Scrum

Se espera que un equipo Scrum incorpore Coraje, Foco, Compromiso, Respeto y Apertura.

Principios de Scrum

Se fundamenta en el control de proceso empírico, la autoorganización y colaboración, la priorización basada en el valor, el time-boxing y el desarrollo iterativo e incremental.

Equipo Scrum

Es la unidad fundamental, pequeña y cohesionada de profesionales, compuesta por un Scrum Master, un Product Owner y Desarrolladores. No hay sub-equipos ni jerarquías, y se enfocan en un objetivo a la vez. Los Desarrolladores son responsables de crear un Incremento útil en cada Sprint, planificar el Sprint Backlog, inculcar la calidad (siguiendo la DoD), adaptar su plan diariamente y responsabilizarse mutuamente.

Eventos de Scrum

Los eventos principales, que son time-boxed (tienen una duración fija máxima), ocurren dentro del Sprint, que es un contenedor para todos ellos y tiene una duración fija de un mes o menos.

Sprint Planning: Se realiza al inicio del Sprint. El equipo decide qué se va a hacer (Objetivo del Sprint) y cómo lo van a hacer (plan de trabajo), seleccionando ítems del Product Backlog para crear el Sprint Backlog.
Daily Scrum (o Daily Stand Up): Reunión diaria de 15 minutos para los Desarrolladores, con el propósito de inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog si es necesario.
Sprint Review: Se realiza al finalizar el Sprint. El equipo presenta el Incremento del producto a los stakeholders y recibe feedback, discutiendo el progreso hacia el Objetivo de Producto.
Sprint Retrospective: Última ceremonia del Sprint, donde el equipo analiza qué fue bien, qué problemas encontró y cómo resolverlos para aumentar la calidad y la eficacia. Su objetivo es planificar mejoras para el próximo Sprint.

Actividad Continua

Product Backlog Refinement: Una actividad continua que permite mantener el Product Backlog actualizado, ordenado y con ítems claros. Se insertan, estiman, refinan, repriorizan y eliminan ítems.

Artefactos de Scrum

Product Backlog: La lista ordenada de todo lo que podría tener el producto (funcionalidades, mejoras, errores, requisitos técnicos). Lo gestiona el Product Owner y se prioriza por valor para el negocio. Su compromiso es el Objetivo del Producto.
Sprint Backlog: El conjunto de ítems seleccionados del Product Backlog que el equipo se compromete a completar durante el Sprint. Es propiedad de los Desarrolladores y su compromiso es el Objetivo del Sprint.
Incremento del Producto: La parte del producto completada al final del Sprint, que debe estar en condiciones de ser entregada y usada, y debe cumplir con la Definition of Done (DoD).

4. Ciclo de Vida Iterativo e Incremental

Un ciclo iterativo en un proyecto significa que se van generando entregables en forma parcial hasta obtener el producto final. Los métodos ágiles, incluido Scrum, son métodos de desarrollo incremental. Esto implica que el producto se construye en incrementos funcionales, entregados en iteraciones cortas y regulares llamadas Sprints. Cada iteración suma valor y permite mejorar el producto con base en el feedback recibido.

En el desarrollo ágil, se busca entregar valor de manera incremental y continua, priorizando la entrega de funcionalidades que proporcionen el mayor valor al cliente. Se generan releases sucesivos que entregan versiones funcionales del producto, limitadas en alcance, pero usables, e incorporan mejoras y extienden la funcionalidad.

5. Triple Restricción: Enfoque Tradicional y Ágil

La triple restricción se refiere a los tres factores clave que influyen en un proyecto: Alcance (qué se va a entregar), Tiempo (cuándo) y Costo/Recursos (con qué esfuerzo o equipo). El balance de estos tres factores afecta directamente la calidad del proyecto. Es responsabilidad del Líder de Proyecto balancear estos tres objetivos, que a menudo compiten entre sí.

La imagen que mencionas ilustra cómo se manejan estas variables en ambos enfoques:

Enfoques Tradicionales (gestión conducida por el plan):

En la gestión tradicional, se considera que los requisitos (Alcance) son fijos. Esto significa que se busca tener todo el producto especificado en su totalidad desde el inicio.
Las variables que se ajustan para cumplir con el Alcance son el Tiempo y los Recursos (Costo).
Este enfoque puede generar problemas si los requerimientos cambian o si no se entienden bien desde el comienzo, llevando a desperdicio de trabajo.

Enfoques Ágiles (gestión conducida por el valor):

En ágil, se considera que el Tiempo y los Recursos (equipo estable) son fijos. Esto se logra mediante el time-boxing de los Sprints y la asignación de un equipo de trabajo fijo.
La variable que se ajusta es el Alcance (requisitos). Se priorizan las funcionalidades que aportan más valor y se adaptan los requerimientos según sea necesario para lograr los objetivos del proyecto.
El énfasis está en entregar valor de manera incremental y continua, acordando con el cliente qué características del producto se pueden entregar en ese tiempo fijo y con esos recursos.

El cambio fundamental en ágil es construir un producto sin tener claras todas las características desde el inicio, adaptándose constantemente a los cambios.

6. DoD y DoR

En Scrum, se utilizan los conceptos de Definition of Ready (DoR) y Definition of Done (DoD) para asegurar la calidad y claridad del trabajo antes de empezar y al terminarlo.

Definition of Ready (DoR) – «Listo»:

Indica cuándo una historia de usuario o ítem del Product Backlog está suficientemente clara, detallada y estimada como para ser seleccionada e implementada en un Sprint.
Este criterio se aplica antes del Sprint Planning y garantiza que el equipo pueda comenzar a trabajar sin ambigüedades.
El modelo INVEST es parte del DoR.

Definition of Done (DoD) – «Hecho»:

Define cuándo un Incremento de producto se considera terminado y listo para ser entregado.
Se aplica al finalizar el Sprint y asegura que el trabajo cumpla con los estándares de calidad acordados por el equipo.
Cada nuevo Incremento se suma a los anteriores y el producto siempre está en un estado potencialmente entregable, cumpliendo con la DoD.
Los criterios de DONE pueden variar entre equipos Scrum, pero deben ser consistentes dentro de un mismo equipo. En el framework Nexus, debe existir un único criterio de hecho (DoD) entre todos los equipos.
La DoD para un ítem del Product Backlog puede incluir el código, las pruebas y toda la documentación necesaria.

7. Valores y Principios Ágiles

La cultura ágil se basa en un cambio de mentalidad que guía a los equipos y organizaciones a ser más flexibles, colaborativos y orientados al cliente.

Valores del Manifiesto Ágil (enfocándose en una cosa sobre la otra) son:

Individuos e interacciones sobre procesos y herramientas: Se valora más el vínculo entre las personas que el respeto a herramientas y procesos específicos. Esto se relaciona con principios como los equipos autoorganizados y la adaptación del comportamiento.
Software funcionando sobre documentación extensiva: Se valora la entrega de software funcional por encima de la cantidad de documentación, sin que esto signifique no documentar. Se relaciona con principios de entregar software frecuentemente y la simplicidad esencial.
Colaboración con el cliente sobre negociación contractual: Es crucial involucrar al cliente en el proyecto, haciéndolo parte del equipo y obteniendo retroalimentación constante. Se relaciona con la comunicación cara a cara como el método más eficiente y el trabajo conjunto de responsables de negocio, diseñadores y desarrolladores.
Responder al cambio sobre seguir un plan: Se acepta que los requerimientos y el contexto cambian constantemente, y la adaptación a estos cambios es más valiosa que adherirse rígidamente a un plan inicial. Se relaciona con la aceptación del cambio en cualquier etapa, la promoción del desarrollo sostenible y la atención continua a la excelencia técnica.

Principios del Manifiesto Ágil son:

Nuestra mayor prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software funcionando.
Aceptar que los requerimientos cambien, incluso en etapas finales del desarrollo.
Entregar frecuentemente software funcional (en periodos de semanas a un par de meses).
Los responsables de negocios, diseñadores y desarrolladores deben trabajar juntos día a día durante el proyecto.
Desarrollar proyectos en torno a individuos motivados, dándoles el entorno y el apoyo que necesitan y confiando en ellos para que hagan el trabajo.
El método más eficiente y efectivo para comunicar información es la conversación cara a cara.
El software funcionando es la principal medida de progreso.
Los procesos ágiles promueven el desarrollo sostenible, manteniendo un ritmo constante indefinidamente.
La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
La simplicidad (el arte de maximizar la cantidad de trabajo no hecho) es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo y ajusta su comportamiento en consecuencia.

8. Principios Lean

La filosofía Lean, originaria de la industria japonesa, se centra en mejorar el flujo de trabajo continuo y reducir el desperdicio. Su meta es reducir el tiempo entre que surge una necesidad y se entrega una solución de valor, eliminando obstáculos y demoras innecesarias.

Principios Lean son:

Eliminar desperdicios: Cualquier cosa que no genera valor para el cliente se considera desperdicio. Incluye características extra, trabajo a medias, procesos extra, movimiento, defectos, esperas y cambio de tareas. Se relaciona con la simplicidad del Manifiesto Ágil y el software funcionando.
Amplificar el aprendizaje: Convertir el conocimiento implícito en explícito, comunicándolo a todo el equipo y fomentando una cultura de mejora continua. Se asocia con los equipos autoorganizados y la inspección y adaptación de los principios ágiles.
Embeber la integridad conceptual: Construir con coherencia y consistencia, asegurando la calidad desde el principio. Se relaciona con la calidad que no se negocia en Ágil y la maximización de la simplicidad.
Diferir compromisos: Tomar decisiones en el «último momento responsable», cuando se tiene la mayor cantidad de información. Esto evita la «parálisis del análisis» y la creación de trabajo que no será utilizado. Se relaciona con la adaptabilidad al cambio.
Dar poder al equipo: Fomentar equipos autoorganizados y autogestionados, motivados para tomar decisiones y responsabilizarse del producto. Esto implica un liderazgo de servicio, donde el equipo puede estimar su propio trabajo. Se relaciona con los equipos autoorganizados de Ágil.
Ver el todo: Mantener una visión holística del producto, el valor agregado y el servicio, sin perder de vista el objetivo final del cliente. Es crucial al trabajar con entregas pequeñas y frecuentes.
Entregar rápido: Estabilizar ambientes de trabajo para una eficiencia máxima y acortar los ciclos de desarrollo. El objetivo es entregar incrementos pequeños de valor rápidamente, llegando al producto mínimo valioso y saliendo pronto al mercado.

9. Principios Kanban

Kanban es un sistema de trabajo y un método para definir, gestionar y mejorar servicios que entregan trabajo del conocimiento. Es una forma de aplicar los principios Lean, centrándose en el flujo del trabajo y la minimización de atascamientos.

Principios de Kanban son:

Visualizar el Flujo: Hacer el trabajo visible mediante el uso de un tablero Kanban. Esto permite que todo el equipo sea consciente del avance del trabajo y ayuda a «ver el todo».
Limitar el Trabajo en Progreso (*WIP – Work in Progress*): Establecer límites explícitos de cuántos ítems pueden estar en progreso en cada estado del flujo de trabajo. Esto evita los cuellos de botella y la saturación de las colas, ayudando a que el trabajo fluya.
Administrar el Flujo: Ayudar activamente a que el trabajo fluya, supervisando y midiendo su progreso. Kanban es un sistema de mejora continua que permite identificar y eliminar desperdicios y barreras.
Hacer Explícitas las Políticas: Las reglas y criterios para mover el trabajo a través del tablero deben ser claros y compartidos por todos los miembros del equipo. Esto promueve la transparencia y el respeto. Un ejemplo son las clases de servicio (Expreso, Fecha fija, Estándar, Intangible).
Mejorar Colaborativamente: Fomentar la colaboración y la evolución gradual de los procesos existentes. Kanban no busca una revolución, sino un cambio incremental y la mejora continua del proceso, basado en la experiencia del equipo.

Kanban utiliza métricas específicas para medir el flujo, como el Cycle Time (tiempo entre el inicio y el final del proceso para un ítem), Lead Time (tiempo desde la solicitud hasta la entrega) y Touch Time (tiempo que el ítem fue realmente trabajado). La relación entre ellas es: Touch Time ≤ Cycle Time ≤ Lead Time