Desde hace tiempo se escucha, y lee, con frecuencia, en conversaciones, en proyectos, en algún correo que alguien envía con alguna duda, en alguna Web, blog, etc., la pregunta… ¿CMMI o Métodos Ágiles (SCRUM)? o la respuesta en sus múltiples variantes: “la empresa tal utilizó CMMI y le funciona mejor que SCRUM”, o “SCRUM es nuestra metodología, CMMI no se adapta a nuestra organización”, etc. Por desgracia, parece haber calado en el día a día la percepción de que los métodos Ágiles y CMMI son polos opuestos.

Como se cita en CMMI or Agile: Why Not Embrace Both!, pueden ser muchas las razones de porqué se perciben los métodos Ágiles y CMMI como elementos opuestos. Quizás porque las primeras implantaciones de CMMI fueron en organizaciones muy grandes, y las primeras implantaciones ágiles fueron en empresas pequeñas, pequeños equipos, con requisitos volátiles. Quizás por la frecuente, mala aplicación, interpretación y evaluación de CMMI en empresas, donde los implantadores y/o evaluadores olvidan el negocio de la empresa, y la ingeniería del software que más se adapta a la organización, elaborando cantidades inútiles de sobre-documentación para justificar “físicamente” la implantación del modelo. Quizás por la terminología, “institucionalizar”, “repetible”, etc., frente a “integración continua”, “refactoring”, “iterativo e incremental”, etc. O quizás porque CMMI se ve antiguo y los métodos ágiles algo moderno, aunque piezas clave en los métodos ágiles como el ciclo de vida iterativo e incremental (de los 60), o la refactorización (de los 90), son anteriores a la aparición de CMMI.

En cualquier caso, aunque exista la percepción de que los métodos Ágiles y CMMI son polos opuestos hay numerosos los estudios (como, por ejemplo, el del propio Jeff Sutherland, uno de los creadores de Scrum, Scrum and CMMI Level 5: The Magic Potion for Code Warriors) y casos reales, que muestran que no sólo no son opuestos, si no que además pueden ser complementarios y pueden potenciar el uno al otro. Algunas claves:

- CMMI es un modelo no una metodología. CMMI se centra en el qué se espera encontrar en una organización, mientras que metodologías y métodos ágiles se centran en el cómo elaborar productos del ciclo de vida del software. En algunos puntos CMMI muestra productos de trabajo típicos, pero son recomendaciones, ejemplos, no obligaciones.

- CMMI no establece orden en la ejecución de los procesos, ni determina un ciclo de vida, son las metodologías quienes determinan este punto, recomendando, por ejemplo, el ciclo de vida iterativo e incremental.

- CMMI muestra áreas de proceso, no procesos en sí. Muestra tipologías de proceso, que luego en cada organización pueden instanciarse de diferente manera, y pueden existir numerosas correspondencias entre “áreas de proceso” y “procesos” de la organización, etc. Y las evaluaciones de CMMI tienen (o debieran tener) el objetivo de interpretar el modelo en la organización concreta, y no el buscar una relación uno a uno entre áreas de proceso y procesos de la organización.

Eso sí, todo esto sin quitar, como comentábamos antes, la frecuente mala aplicación, interpretación, implantación, justificación basada en sobre-documentación y evaluación de CMMI en empresas; pero esto ya no es cosa de CMMI, es de quien lo mal interpreta.

Otras entradas relacionadas con esta:

1. Curso calidad software: procesos y métodos ágiles. Te llevas un libro y media matricula te puede salir gratis
2. Nos vemos en la segunda edición del curso calidad software (procesos y métodos ágiles)
3. Experiencia en la implantación de CMMI-DEV v1.2 en una micropyme con metodologías ágiles y software libre
4. Si que se puede implantar ISO 15504 / ISO 12207 con prácticas ágiles
5. Usando Scrum para evitar malas implementaciones de CMMI