Aquí quiero contar los defectos de CMMI per-se, y por sus malas implementaciones en metodologías apresuradas o porque el único interés era conseguir "el sello de calidad".
Si has leído otros post, verás que no estoy a favor de defender metodologías porque estén de moda (como Scrum), sino solamente porque demuestren razonadamente beneficios. Para mi desgracia, sí que me gustan las metodologías ágiles, a pesar de mi resistencia a defenderlas “porque sí”. Eso me hace, por convicción, tener que evitar la tentación de venderlas constantemente y a ciegas. De hecho, suelo "darles caña", simplemente porque creo que en ellas está el futuro, pero requieren de disciplina y sentido común a la hora de implantarse, y sobre todo no olvidar que hay más cosas que "picar código" y que la empresa y el cliente necesitan que se lleven a cabo.
Vamos a razonar los defectos (que los tiene) que se suelen alegar en contra de CMMi.
Alcance.
Efectivamente, no se obtiene normalmente el CMMi para una empresa. Se obtiene con un alcance determinado (un departamento o unidad de negocio), varios de ellos, o un conjunto de proyectos relacionados de alguna forma. Ojo con esto, porque seguramente las empresas que afirman que son CMMi nivel X, en realidad suelen tener un alcance inferior al 100% de su personal y proyectos. Basta que vayáis a la base de datos de empresas que han obtenido el nivel X de CMMi, y leáis los detalles del alcance. No es que se mienta, es la gente quien al desconocer estos detalles, se hace una idea equivocada. Es interesante decir también que en los resultados de la evaluación se hace mención explícita de los proyectos y personas evaluados. De esta forma, se da una idea porcentual del alcance de la certificación CMMi en la empresa.
CMMi no cubre todo
CMMi deja de lado diversas áreas de la empresa, como pueden ser las contrataciones, motivaciones, y en general todos los temas relacionados con las personas. Bien, al respecto hay que decir que CMMi-DEV es un modelo de madurez del desarrollo de software, no de la gestión de personas. Para eso, existe un People CMMi. Si alguien quiere tener en cuenta a las personas, puede certificarse en ambos. O si sólo quiere certificarse en la gestión de personas…pues ahí está. De todas formas, en mi empresa, lo que se evalúa es la metodología, y en nuestro caso incluía gestión de recursos, formación a nivel corporativo, etc. Vamos, los típicos procesos de training, staffing y recruiting. Y esos procesos fueron revisados durante el SCAMPI, como parte de la metodología. De hecho, al final del SCAMPI, se obtienen “puntos fuertes” que son buenas prácticas más allá del mínimo que exige el modelo.
Es una foto parcial de la empresa en un momento, pero el título es para siempre.
Bueno, los resultados de un SCAMPI tienen validez de 3 años. Si ANTES de ese tiempo no se ha hecho una nueva evaluación igual o superior, se pierde ese nivel de madurez. Lo que sí es cierto es que es una foto parcial de la empresa. Los proyectos pasado el SCAMPI, pueden descontrolarse, y perder todas esas buenas prácticas, pero claro, si es así, ya se pasará factura si se trata luego de renovar el nivel de madurez. Mi experiencia es que si las metodologías implantadas son ligeras, y se hace contando con la gente, su uso es suficientemente beneficioso para que los proyectos lo mantengan por sí mismos.
CMMi no reconoce ciclos de vida (SDLC) como parte del modelo.
A ver, CMMi es un modelo. Recopila paquetes de actividades que se consideran básicas, y dentro de cada una, se puede tener un nivel u otro de madurez. Los ciclos de vida son parte de las metodologías, pero CMMi deja libertad a ciclos en cascada, iterativos, ágiles, etc. Yo comprendo que hay gente que quiere que CMMi les resuelva la vida. Y no lo va a hacer. CMMi dice lo que se necesita hacer en todo proyecto, pero es el buen juicio y el sentido común de los creadores de las metodologías, los responsables de que se haga trabajo de más, o de que a un proyecto de 3 personas acabemos pidiendo documentación fuera de lugar.
Burocracia.
Bueno, de esto ya hablé en el mito de la burocracia. No le daré más vueltas. Puede efectivamente convertirse en un grave defecto si no sabemos adaptar y aligerar las metodologías a los proyectos. Sin embargo, lo veo más una excusa para evitar involucrarse en CMMi, con la errónea creencia de que va en contra de los métodos ágiles.
Proyectos de distinto tipo a los que han pasado la evaluación de madurez CMMi.
Efectivamente, puede ser que todos los proyectos que pasen CMMi fueran Oracle, de desarrollo, y con ciclo de vida iterativo. ¿Qué pasa ahora? Pues nada, los proyectos que no sean así, dependerán de si la metodología también se adapta a ellos, y de un montón de cosas más. ¿Qué cómo contempla esto CMMi? Pues no lo contempla. Por eso existe un alcance.
CMMi no es una certificación.
A pesar de que llevo ya varias frases utilizándolo aposta (a ver si alguien dice algo), en realidad no puede decirse “la empresa X está certificada CMMi nivel…”. Lo que se hace es una evaluación de madurez, pero en ningún momento el SEI (Software Engineering Institute) proporciona certificado de ningún tipo, al contrario de por ejemplo ISO-9001 que sí emite certificados que pueden enmarcarse o presentarse. Podemos leer en las páginas del SEI:
- SEI no certifica los resultados de niveles de madurez de ninguna evaluación
- SEI no certifica organizaciones. SEI solo licencia a consultores asociados para realizar evaluaciones. Ni SEI ni ninguna otra organización es una autoridad de certificación de los resultados de estas evaluaciones.
CMMi es responsabilidad del SEI, y no emite certificaciones. Lo que sí es posible es que se emita un informe por parte del consultor evaluador o de la empresa certificadora, justificando el alcance y resultados. Pero nada más.
CMMi no asegura la calidad.
Siguiendo el hilo del anterior, el haber pasado un SCAMPI y obtener el nivel de madurez tal o cual, no asegura nada. Por eso no pueden publicarse como “certificados”. La evaluación CMMi es para la empresa, para que sea consciente de su estado de madurez en las condiciones establecidas. Pero no garantiza nada, ni el SEI ni la consultura que hace la evaluación, se hacen responsables de la calidad de los productos (salvo la propia empresa evaluada).
