Craig Larman y su opinión sobre CMMI

Desconozco si Craig Larman, que a alguno os sonará por “Applying UML & Patterns” (libro que en su tiempo fue famosillo en el sector), ha tenido algún problema con el SEI (organización propietaria de CMMI), pero en su último libro (Practices for Scaling Lean & Agile Development, 2010) no se corta nada. Os dejo algunas frases, traducción literal:
– Una buena certificación implica buen código  – “Not true”
– El SEI certifica las evaluaciones y los niveles – “Not true”. ¿Certifica el SEI o hace seguimiento de las evaluaciones? No. [De esto hablamos en su día]

– Las evaluaciones CMMI son fiables y el “número” significativo – “Not true”
– CMMI está asociado con una mejora con éxito – “Not true”
Eso sí, tampoco a él, como a tantos otros, incluido este humilde blog, se le pasa decir que:
– “CMMI and agile methods or lean thinking are fundamentally Incompatible” – “Not true” (traducido, que CMMI y los métodos ágiles no son incompatibles).
Otra cosa son los “auditores tradicionales”, pero eso no es culpa del CMMI, en todo caso del SEI. Aunque alguno por ahí aún siga con que si CMMI es incompatible con las metodologías ágiles, que si CMMI o ágil, que si CMMI vs ágil, procesos o ágil y rollos similares.
Y respecto a todo esto, por mi parte, volver a decir que CMMI es un magnifico modelo (siempre que se interprete bien), pero que el modelo de evaluación, appraisal o concesión oficial de un nivel de madurez es muy muy mejorable.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “Craig Larman y su opinión sobre CMMI”

  1. Colegas:
    No puede reprimirme de vovler a puntualizar (aunque los que leáis esto seguro que lo tenéis claro) la diferencia entre Control de Calidad (ej. testing) y Aseguramiento de Calidad que desde la 2ª Guerra Mundial se hace en base a Definición de Procesos de Trabajo, por medio de los cuales se fabrican los items que vendemos. Tanto tornillos como coches o software.
    Claro que unos procesos definidos y claros, en base a SPICE, CMMI, o el modelo que sea, no GARANTIZA que los productos van a ser buenos, pero sí que pone los medios para que si hay errores éstos se detecten a tiempo, a no ser que nos saltemos los procesos, claro.
    Pero el consenso mundial es que los procesos llevan a buenos productos, y si alguien no está de acuerdo que hable con Deming, Juran, Humphries, etc (en sentido figurado, claro, o bien a través de medium 😉
    Y cierto también que todo es mejorable. Sin embargo sí que me gustaría preguntar qué podríamos sugerir para mejorar ese «appraisal o concesión oficial de un nivel de madurez CMMI que es muy muy mejorable»

  2. Mikel, me niego a meter en el mismo saco la fabricación de tornillos o coches y el software. Pensaba que eso ya estaba superado en la mentalidad de la gente relacionada con el mundo del software.
    Crear software es como diseñar un coche, no como fabricarlo!

  3. @Mikel:
    Hola,
    Las críticas, y lo que comenta Larman, no creo que apunten en este texto hacia el debate de si «buenos procesos implican buenos productos», aqui se está refiriendo mas a si «evaluaciones de procesos implican buenos productos».
    Saludos

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *