La caída de las evaluaciones CMMI (caída del 50%)

Dice un refrán que “una imagen vale más que mil palabras”, así que, para empezar el post, te dejo la siguiente:

 cmmi 2013

cmmi 2013 2 Fuente: CMMI Institute. Evaluaciones CMMI 2013 y posteriores

De 2012 a 2013 una caída del 50% en certificaciones (perdón, evaluaciones). Ojo, a fecha de finales de septiembre.
Y no será porque no se veía venir, al menos, en este blog, llevamos dando advertencias de ello desde hace años.
Y al final, como también dice el refrán, “entre todos la tenían y ella sola se moría”, el movimiento de responsables de CMMI, que pudo haber supuesto la reinvención, como comentamos en 2012 en comienza un nuevo, o incierto, futuro para CMMI. Si yo usase CMMI en mi empresa estaría muy atento, y que supuso el traspaso del modelo desde el potente SEI al nuevo CMMI Intitute, tampoco pudo enderezar la tendencia.
Más allá de que a toda tecnología que no se reinventa periódicamente… le llega, continuando el refranero, “su San Martín”, el caso CMMI, en mi opinión, además, adolecía desde hace años de profundas heridas que aún siendo bien conocidas por la comunidad, y aun transcurriendo muchos años con ellas, los responsables del modelo no quisieron, o supieron, atajarlas: un proceso de auditoría (perdón, evaluación) alejado de los tiempos que corren y demasiadas implantaciones erróneas (innecesarias y fruto del desconocimiento) del modelo.

Un proceso de auditoría (perdón, evaluación) alejado de los tiempos que corren

Ya en 2011, en la “Guía práctica de supervivencia en una auditoría CMMI”, y de nuevo en 2012, en aquel post de ¿Quieres saber dónde realmente está el problema de integrar CMMI con una metodología ágil?, alertaba del problema de las auditorías (perdón, evaluaciones) de CMMI…
“Preparar una auditoría de CMMI nivel 2 se requiere que la empresa presente al auditor entre 816 y 1224 evidencias. Haciendo una estimación, si registrar una evidencia lleva aproximadamente 10 minutos de media (tirando por lo bajo), registrarlas todas, para presentarlas al auditor, nos llevará entre 17 y 26 jornadas de trabajo, prácticamente un mes o mes y algo. Y esto no es ágil.”
No te digo más. Papel, papel, papel.
Si a eso le unes que aún hoy hay demasiado AUDITATOR TIC ahí fuera. No se puede razonar con él. Si estás a tiempo huye (o finge una baja de unos días), la cosa se pone difícil de digerir.
Y ojo, que en España tenemos excelentes auditores (perdón, evaluadores) CMMI, pero ello no quita que ellos tengan que seguir trabajando con un proceso de auditorá documental más típico del siglo pasado.

Demasiadas implantaciones erróneas (innecesarias y fruto del desconocimiento) del modelo

En 2011, en aquel post de  mitos del Desarrollo Software: Proceso es sinónimo de ciclo de vida en cascada comentaba que uno de los mitos arraigados en ciertos grupos y colectivos es aquel que habla de que “los procesos implican ciclos de vida en cascada”.
Mito que también podemos encontrar sustituyendo la palabra “procesos” por CMMI. Y con ello podemos encontrar miles de implantaciones de CMMI que han creído que debía ser en cascada. Y con ello un argumento para que aquellos que no conocían de verdad ni lo ágil ni en CMMI, pero que querían vender proyectos ágiles, añadieran el toque de «es que CMMI = Ciclo de vida en cascada».
Y todo ello vaya ud. a saber por qué, porque yo me fui al documento que describe CMMI e hice una búsqueda por la palabra “waterfall”, y aparece… una vez en las 482 páginas (y como ejemplo de ciclo de vida, y junto al iterativo y el incremental), y es más, yo me fui en persona a ver al tipo que creo el primer CMMI y me dijo que el trabajaba con Scrum y CMMI. Es más, es que también lo dijo el tipo que creo Scrum. Pero la vida es así de dura.

Un consejo antes de terminar

Volví a comentar el tema en aquella charla de  las jornadas calidad del producto: ITIL, Testing o CMMI no son suficientes .
CMMI no tenía necesidad de este varapalo, en el fondo, CMMI era una muy buena idea, que trabaja en multitud de sitios de manera ágil (Can Scrum help to improve the project management process?), pero que se había rodeado de malas amistades: una auditoría desfasada y un conjunto de malas implantaciones documentales y en cascada que acabaron dándole mala fama.
Ah, último refrán, “cuando las barbas de tu vecino veas cortar por las tuyas a remojar”, lo digo por si algún otro modelo, en desarrollo software o sistemas, está a tiempo remojarse las barbas.