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

Clasificado en Magisterio

Escrito el en español con un tamaño de 9,19 KB

Valores del Manifiesto Ágil

Se prioriza:

  • Valorar a los individuos y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
  • Desarrollar software que funciona más que conseguir una documentación exhaustiva.
  • La colaboración con el cliente más que la negociación de un contrato.
  • Responder a los cambios más que seguir estrictamente un plan.

Los Principios Ágiles

  1. Satisfacer al cliente mediante entregas tempranas y continuas de software con valor.
  2. Dar la bienvenida a los cambios en los requisitos, incluso si llegan tarde en el desarrollo. Los procesos ágiles aprovechan el cambio para obtener la ventaja competitiva del cliente.
  3. Entregar frecuentemente software que funcione, desde un par de semanas hasta un par de meses, con preferencia al periodo de tiempo más corto posible.
  4. La gente del negocio y los desarrolladores deben trabajar juntos de forma cotidiana durante todo el proyecto.
  5. Construir el proyecto en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
  6. El diálogo cara a cara es el método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros.
  7. El software que funciona es la medida fundamental de progreso.
  8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
  9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
  10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos organizados por sí mismos.
  12. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a continuación, ajustar y perfeccionar su comportamiento en consecuencia.

Malas Interpretaciones Comunes sobre el Manifiesto Ágil

  • Ausencia total de documentación: Ágil valora el software funcional sobre la documentación exhaustiva, no la elimina por completo. Se crea la documentación necesaria y útil.
  • Ausencia total de planificación: Ágil valora la respuesta al cambio sobre seguir un plan estricto, pero la planificación (inicial y continua) es fundamental.
  • El cliente debe hacer todo el trabajo y será el jefe de proyecto: Ágil valora la colaboración con el cliente, lo que implica una participación activa, pero no necesariamente que asuma roles del equipo de desarrollo o gestión.
  • El equipo puede modificar la metodología sin justificación: Si bien los equipos reflexionan y adaptan sus procesos, los cambios deben basarse en la mejora continua y no ser arbitrarios.

Elementos de una Historia de Usuario

Una historia de usuario típicamente incluye: ID (Identificador único), Título (Nombre corto y descriptivo), Valor (Importancia para el negocio/cliente), Estimación (Esfuerzo requerido), Descripción (Narrativa desde la perspectiva del usuario: "Como [rol], quiero [funcionalidad] para [beneficio]"), Dependencias (Otras historias o tareas necesarias) y Pruebas de Aceptación (Criterios para considerar la historia completada).

Beneficios de Scrum

  • Entrega periódica de resultados: Incrementos de producto funcionales en cada Sprint.
  • Entregas parciales de resultados: El cliente puede empezar a utilizar funcionalidades y recuperar su inversión antes de que el proyecto completo esté terminado.
  • Flexibilidad y adaptación: Capacidad para ajustar el producto según las necesidades cambiantes del cliente y del mercado.
  • Mejores adaptaciones: El feedback continuo permite refinar el producto y el proceso.

Principios Lean

  • Eliminar desperdicios (actividades que no añaden valor).
  • Amplificar el aprendizaje (mediante ciclos cortos y feedback).
  • Decidir lo más tarde posible (retrasar decisiones irreversibles).
  • Entregar lo más rápido posible (minimizar el tiempo del ciclo).
  • Capacitar y potenciar al equipo (dar autonomía y confianza).
  • Construir con calidad (integrar la calidad desde el principio).
  • Ver el todo (optimizar el flujo completo, no partes aisladas).

Principios de Kanban

  • Visualizar el flujo de trabajo: Usar tableros para ver las tareas y su estado.
  • Limitar el trabajo en progreso (WIP): Evitar cuellos de botella y mejorar el flujo.
  • Medir y gestionar el flujo de tareas: Optimizar la velocidad y predictibilidad de entrega.

Diferencias Clave entre Kanban y Scrum

  • Kanban es generalmente más adaptativo a cambios inmediatos en las prioridades.
  • Scrum utiliza iteraciones de tiempo fijo (Sprints) con un compromiso de alcance; Kanban no tiene iteraciones obligatorias y el flujo es continuo.
  • En Kanban, se pueden introducir nuevas tareas en el flujo si la capacidad lo permite, mientras que en Scrum, el alcance del Sprint suele estar bloqueado una vez iniciado.
  • Kanban no especifica roles ni tamaño del equipo de forma prescriptiva, y permite la especialización de roles; Scrum define roles específicos (Product Owner, Scrum Master, Development Team).

CMMI (Capability Maturity Model Integration)

CMMI es un modelo de referencia de mejores prácticas utilizado para evaluar la madurez de los procesos de una organización y guiar su mejora continua mediante una escala evolutiva.

Modelo de Procesos CMMI

  • CMMI-DEV (Development): Para organizaciones que construyen productos y servicios. Guía la construcción, control y gestión de procesos de desarrollo.
  • CMMI-SVC (Services): Enfocado a la gestión y entrega de servicios (alineado con estándares como ISO 20000).
  • CMMI-ACQ (Acquisition): Para gestionar la cadena de suministro y la subcontratación de productos y servicios.

Modelo de Evaluación (SCAMPI)

  • SCAMPI A (Standard CMMI Appraisal Method for Process Improvement): Realiza evaluaciones formales y en profundidad para determinar niveles de madurez y capacidad de la organización. Es la base para una calificación oficial.
  • SCAMPI B: Similar al tipo A pero simplificado, a menudo usado como preparación o para evaluar áreas específicas.
  • SCAMPI C: El método más rápido y económico, útil para diagnósticos rápidos o evaluación de riesgos.

Niveles de Madurez CMMI (Ejemplo para CMMI-DEV v1.3)

  • Nivel 5 (Optimizing): Mejora continua de procesos basada en análisis cuantitativo. Áreas de Proceso (PAs): CAR (Causal Analysis and Resolution), OPM (Organizational Performance Management).
  • Nivel 4 (Quantitatively Managed): Procesos gestionados usando técnicas estadísticas y cuantitativas. PAs: QPM (Quantitative Project Management), OPP (Organizational Process Performance).
  • Nivel 3 (Defined): Procesos estandarizados y definidos a nivel organizacional. PAs: TS (Technical Solution), PI (Product Integration), VER (Verification), VAL (Validation), OPD (Organizational Process Definition), OPF (Organizational Process Focus), OT (Organizational Training), IPM (Integrated Project Management), RSKM (Risk Management), DAR (Decision Analysis and Resolution), RD (Requirements Development).
  • Nivel 2 (Managed): Procesos gestionados a nivel de proyecto. PAs: REQM (Requirements Management), PP (Project Planning), PMC (Project Monitoring and Control), SAM (Supplier Agreement Management), CM (Configuration Management), PPQA (Process and Product Quality Assurance), MA (Measurement and Analysis).
  • Nivel 1 (Initial): Procesos impredecibles, pobremente controlados y reactivos.

Tipos de Evidencia (PII - Practice Implementation Indicators) en Evaluaciones CMMI

Durante una evaluación SCAMPI, se buscan indicadores para confirmar la implementación de las prácticas definidas en el modelo. Estos se clasifican en:

  • Artefactos Directos: Salidas tangibles que resultan directamente de la implementación de una práctica (ej. un plan de proyecto, un registro de riesgos, código fuente revisado).
  • Artefactos Indirectos: Evidencia que es consecuencia de la implementación de una práctica, aunque no sea el propósito principal de la misma (ej. actas de reunión donde se discutió un riesgo, métricas recopiladas).
  • Afirmaciones: Expresiones orales (ej. entrevistas con el personal) o escritas (ej. correos electrónicos, testimonios) que confirman cómo se implementa una práctica.

Entradas relacionadas: