Metodologías Ágiles Esenciales: Scrum, Lean y Kanban para Desarrollo de Software

Pilares del Empirismo en Scrum

El empirismo en Scrum basa el conocimiento en la experiencia y las decisiones en lo observado. Utiliza un enfoque iterativo e incremental para optimizar la predictibilidad y controlar el riesgo, a través de los pilares de:

• Transparencia: Información clara y trabajo visible para todos, permitiendo la inspección.

• Inspección: Revisar el progreso en ciclos cortos (Daily Scrum, Sprint Reviews) para detectar desviaciones y problemas a tiempo.

• Adaptación: Realizar cambios rápidos según lo aprendido en la inspección si algo no funciona. Estos pilares son fundamentales en Scrum, junto con el control de proceso empírico, la autoorganización y colaboración, la priorización por valor, el time-boxing y el desarrollo iterativo e incremental.

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

El modelo INVEST define criterios de calidad para las Historias de Usuario (US), siendo parte de la Definition of Ready (DoR). Una buena US debe cumplir:

• I – Independiente: Desarrollarse, probarse e implementarse sin depender de otras historias, dando libertad de priorización al Product Owner.

• N – Negociable: Negociar el «Qué» (funcionalidad) con el cliente, no el «Cómo» (implementación).

• V – Valiosa: Proporcionar valor tangible o intangible al cliente/usuario final (utilidad, beneficio, satisfacción).

• E – Estimable: Ser lo suficientemente clara para estimar el esfuerzo. Si hay incertidumbre, puede requerir una spike.

• S – Pequeña (Small): Ser lo suficientemente pequeña para completarse en un Sprint y así entregar valor.

• T – Testeable: Tener criterios de aceptación claros que permitan verificar su correcta implementación.

Scrum

Scrum es un marco de trabajo liviano que ayuda a generar valor con soluciones adaptativas para problemas complejos. Se basa en el empirismo y el pensamiento Lean, con un enfoque iterativo e incremental.

Valores

Coraje, Foco, Compromiso, Respeto y Apertura.

Principios

Control de proceso empírico, autoorganización y colaboración, priorización por valor, time-boxing y desarrollo iterativo e incremental.

Equipo Scrum

Unidad fundamental pequeña y cohesionada: Scrum Master, Product Owner y Desarrolladores. No hay sub-equipos ni jerarquías; se enfocan en un objetivo. Los Desarrolladores crean el Incremento, planifican el Sprint Backlog, aseguran calidad (DoD), adaptan el plan diario y se responsabilizan mutuamente.

Eventos de Scrum

(Time-boxed y dentro del Sprint, de máximo un mes):

• Sprint Planning: Al inicio, el equipo decide qué y cómo se hará (Objetivo del Sprint, Sprint Backlog).
• Daily Scrum (Daily Stand Up): 15 minutos diarios para Desarrolladores para inspeccionar progreso y adaptar el Sprint Backlog.
• Sprint Review: Al finalizar, el equipo presenta el Incremento a stakeholders y recibe feedback.
• Sprint Retrospective: Última ceremonia, el equipo analiza su desempeño para planificar mejoras en el próximo Sprint.
• Product Backlog Refinement: Actividad continua (10% del Sprint) para mantener el Product Backlog actualizado, ordenado y detallado (cumpliendo DoR).

Artefactos de Scrum

Product Backlog: Lista ordenada de todo lo que podría tener el producto (compromiso: Objetivo del Producto).

Sprint Backlog: Ítems seleccionados del Product Backlog para el Sprint (compromiso: Objetivo del Sprint). Es propiedad de los Desarrolladores.

Incremento del Producto: Parte del producto completada al final del Sprint, potencialmente entregable y utilizable. Debe cumplir con la Definition of Done (DoD).

Ciclo de Vida Iterativo e Incremental

Un ciclo iterativo genera entregables parciales hasta el producto final. Los métodos ágiles, como Scrum, son incrementales: el producto se construye en incrementos funcionales entregados en iteraciones cortas (Sprints). Cada iteración suma valor y permite mejoras con feedback. El desarrollo ágil busca entregar valor incremental y continuo, priorizando funcionalidades de mayor valor. Genera releases sucesivas que son versiones funcionales, usables y con mejoras.

Triple Restricción: Enfoque Tradicional y Ágil

La triple restricción se refiere a Alcance (qué), Tiempo (cuándo) y Costo/Recursos (con qué), cuyo balance afecta la Calidad del proyecto. El líder de proyecto balancea estos objetivos.

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

  • Alcance: Fijo (todo especificado al inicio).

  • Variables: Tiempo y Costo/Recursos (se ajustan para cumplir el alcance).

  • Problema: Poco adaptable a cambios de requisitos.

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

  • Tiempo y Costo/Recursos: Fijos (time-boxing, equipo estable).

  • Variable: Alcance (se priorizan funcionalidades de mayor valor y se adaptan los requisitos).

  • Énfasis: Entregar valor incremental y continuo, adaptándose constantemente a los cambios sin tener todas las características claras al inicio.

DoD y DoR en Scrum

En Scrum, aseguran la calidad y claridad del trabajo:

• Definition of Ready (DoR) – «Listo»: Indica cuándo una historia o ítem del Product Backlog está clara, detallada y estimada para ser seleccionada en un Sprint (antes del Sprint Planning). 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 entregar. Asegura estándares de calidad acordados por el equipo. Cada Incremento suma a los anteriores y el producto es siempre potencialmente entregable. La DoD puede variar entre equipos, pero debe ser consistente dentro del mismo equipo. En Nexus, hay un único DoD. El Scrum Team es responsable de definirla y puede incluir código, pruebas y documentación.

Valores y Principios Ágiles

La cultura ágil es un cambio de mentalidad hacia la flexibilidad, colaboración y orientación al cliente.

Valores del Manifiesto Ágil

(priorizan):

• Individuos e interacciones sobre procesos y herramientas (valor del vínculo humano).
• Software funcionando sobre documentación extensiva (valor de la entrega funcional, no la cantidad de documentos).
• Colaboración con el cliente sobre negociación contractual (cliente involucrado, feedback constante).
• Responder al cambio sobre seguir un plan (aceptar el cambio y adaptarse es más valioso que la rigidez).

Principios del Manifiesto Ágil

(guías):

• Satisfacer al cliente con entregas tempranas y continuas de software funcional.
• Aceptar cambios en requisitos, incluso tardíos.
• Entregar software funcional frecuentemente (semanas a meses).
• Negocio, diseñadores y desarrolladores trabajan juntos diariamente.
• Construir proyectos alrededor de individuos motivados, darles apoyo y confiar en ellos.
• La conversación cara a cara es el método de comunicación más eficiente.
• El software funcionando es la principal medida de progreso.
• Promover desarrollo sostenible, manteniendo un ritmo constante.
• La excelencia técnica y el buen diseño mejoran la Agilidad.
• La simplicidad (maximizar el trabajo no hecho) es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
• El equipo reflexiona y ajusta su comportamiento regularmente para ser más efectivo.

Principios Lean

Filosofía japonesa que busca mejorar el flujo de trabajo continuo, reducir el tiempo entre necesidad y entrega de valor, eliminando desperdicios.

• Principios

  1. Eliminar desperdicios: Todo lo que no genera valor (características extra, trabajo a medias, defectos, esperas, etc.).

  2. Amplificar el aprendizaje: Hacer el conocimiento explícito, fomentar mejora continua.

  3. Embeber la integridad conceptual: Construir con coherencia y calidad desde el principio.

  4. Diferir compromisos: Tomar decisiones en el «último momento responsable» (más información, flexibilidad).

  5. Dar poder al equipo: Fomentar equipos autoorganizados y autogestionados.

  6. Ver el todo: Visión holística del producto y valor, sin perder el objetivo final.

  7. Entregar rápido: Estabilizar ambientes, acortar ciclos de desarrollo, entregar incrementos pequeños de valor.

Principios Kanban

Sistema de trabajo y método para gestionar/mejorar servicios de conocimiento, aplicando principios Lean. Centrado en el flujo del trabajo y minimizar atascamientos.

• Principios de Kanban

  • Visualizar el Flujo: Usar un tablero Kanban para hacer el trabajo visible («ver el todo»).

  • Limitar el Trabajo en Progreso (WIP): Establecer límites explícitos en cada estado para evitar cuellos de botella y saturación.

  • Administrar el Flujo: Supervisar y medir el progreso para mejorar el flujo (mejora continua, eliminar desperdicios).

  • Hacer Explícitas las Políticas: Reglas y criterios claros para mover el trabajo (ej., clases de servicio).

  • Mejorar Colaborativamente: Fomentar la evolución gradual de los procesos existentes, basada en la experiencia.

• Métricas en Kanban

  • Cycle Time: Tiempo inicio a fin para un ítem.

  • Lead Time: Tiempo desde solicitud hasta entrega.

  • Touch Time: Tiempo real de trabajo en un ítem.

  • Relación: Touch Time ≤ Cycle Time ≤ Lead Time.

  • Eficiencia del Ciclo de Proceso: Touch Time / Elapsed Time.

Práctico

1. Roles

• Usuario (Guest): Registrar usuario, Realizar reserva, Confirmar reserva.
• Recepcionista: Registrar check-in, Modificar reserva, Registrar check-out.
• Administrador de la Empresa: Registrar espacios para alquilar.

Descripción MVP

El objetivo del MVP es validar el funcionamiento básico de la aplicación, permitiendo que los clientes se registren para reservar espacios y que la recepcionista confirme, modifique, y registre check-in/check-out de esas reservas.

El MVP incluye:

• Registro de usuarios (ingreso de datos).
• Registro y confirmación de reserva por usuario.
• Registro de espacios por la empresa para alquiler.
• Modificación de reserva por recepcionista.
• Registro de check-in y check-out por recepcionista.

No se incluye:

• Métodos de pago virtuales/tarjetas de crédito.
• Cancelación de reserva por usuario.
• Realización de reserva vía plano interactivo.
• Visualización de todas las reservas de la empresa.
• Marcar espacios favoritos.
• Visualización de todos sus datos.
• Realizar calificaciones.
• Suscripciones a empresas.
• App Mobile (se asume que es la plataforma, no una funcionalidad a desarrollar).

Criterio MVP:

Se consideró como MVP el core funcional del producto: registro y gestión de la reserva, dejando fuera funcionalidades no críticas para validar el uso principal de la aplicación.

2. a) User Story Canónica:

Registrar check-in

Estimación: 4 SP

Justificación:

• Complejidad: Baja. Funcionalidad simple, implica registrar la llegada del cliente a una reserva activa (ej. botón de check-in). No requiere lógica compleja.
• Esfuerzo: Bajo. Operación básica de actualización de estado.
• Incertidumbre: Muy poca. Requisitos claros, sin duda técnica.

Realizar Reserva

• Estimación: 8 SP
• Descripción: Como usuario, quiero poder realizar la reserva de un espacio para tener un lugar donde pueda realizar mi trabajo.
• Criterios de aceptación:
  • Seleccionar cantidad de personas que asistirán.
  • Ingresar una observación (Opcional).
  • El sistema debe mostrar el precio por persona/hora y el importe total.
  • El sistema debe permitir seleccionar el espacio a alquilar.
  • El sistema debe mostrar los espacios para alquilar.
• Pruebas de aceptación:
  • Se selecciona cantidad de personas: 3 (Pasa)
  • Probar ingresar una observación (Pasa)
  • Probar que el sistema muestre precio por persona/hora (Pasa)
  • Probar que se muestren los espacios para alquiler (Pasa)
• Justificación:
  • Complejidad: Media. Funcionalidad medianamente simple (selección de campos, algunas validaciones). No requiere lógica compleja.
  • Esfuerzo: Medio. Requiere distintas validaciones, manejo de fechas, y selección única de campos.