Cuando hablamos de CMMI

Observo constantemente en blogs y comentarios frases como éstas:

  • “La metodología SCRUM es mucho más ágil que CMMI”
  • “CMMI es una metodología arcaica y excesivamente burocrática”
  • “No tengo claro qué metodología usar en mi proyecto: CMMI, SCRUM, xxx”

¿Nadie se da cuenta? El problema es que en todas las frases, se está hablando de CMMI como metodología, y no lo es. Por tanto, es absurdo compararla con cualquier otra (he usado por ejemplo SCRUM, pero podría haber puesto cualquiera).

CMMI es un modelo de referencia. Según wikipedia: “es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software“. Realmente, los que hayáis estudiado CMMI más o menos a fondo, veréis que en este modelo no se dice cómo se han de hacer las cosas, sino qué cosas deben hacerse.

Os preguntaréis…¿hacerse…para qué? Pues para tener una metodología (conjunto de procesos) que cubran todos los aspectos necesarios, que cubran todas las necesidades de la gestión y el desarrollo. Es por eso que es absurdo comparar a CMMI con cualquier metodología (ya que no lo es). Es como lo de las peras y las manzanas: no se pueden comparar.

Otra forma impropia de hablar de CMMI es cuando se usa para hablar de excesiva burocracia, métodos arcaicos, poco ágiles, o como cuando se vincula con metodologías en cascada (las famosas Waterfall Methods). Aquí hay varios problemas que provocan esto:

  • Excesiva burocracia: evidentemente, si algo no nos apetece hacerlo, pasará a segundo plano (ver mi reciente entrada sobre procrastinacion), aunque eso no signifique es es innecesario. Por desgracia, eso también ocurre si bajo nuestro punto de vista no es necesario. Por ejemplo, yo desarrollo software. No me gusta facturar al cliente, no me gusta hacer seguimiento de cobros…pero sin ello, ya puedo ser el mejor programador del mundo: no puedo vivir del aire. Yo, mi familia, todos necesitamos el dinero que cobramos. Luego el control de horas trabajadas, el control de pagos/cobros, y muchas otras actividades, son necesarias para la empresa. Cuando hablamos de burocracia, se nos olvida que no trabajamos para nosotros. Hay metodologías que por fin han involucrado a los clientes  (enhorabuena por el descubrimiento), pero siguen ignorando a la empresa en la que trabajan. Por desgracia, y es un mal endémico en nuestro sector, todavía hay quien cree que cobra por sus horas trabajadas, cuando en la mayoría de los casos, se cobra por cumplir un contrato.
  • Métodos arcaicos: algo es arcaico o antiguo en comparación o referencia a otra cosa. Resulta divertido ver cómo los defensores de ciertas metodologías, las consideran muy modernas para unas cosas, y luego para defender que están arraigadas y no son algo inmaduro, acreditan estar basadas en métodos, prácticas, y otras referencias de 10, 20, 30 años o más. Por desgracia, en nuestro sector se consigue que algo sea bueno o atractivo, en base a destruir la reputación de todo aquello que le pueda hacer competencia.
  • Agilidad: los métodos son tanto más ágiles, cuanto más rápidamente nos acercan a nuestros objetivos. Eso no significa que sean los más rápidos. Se nos olvida muchas veces, que para llegar antes, no es más importante correr mucho, sino tener claro hacia dónde debemos ir (y no desandar constantemente el camino). Esto me recuerda muchos proyectos en los que no se tienen claros los objetivos, ni qué hay que hacer, pero los jefes de proyecto insisten en “redoblar los esfuerzos”. Por eso, las técnicas, prácticas y metodologías, serán sólo ágiles, cuando en las condiciones favorables, nos acerquen a nuestros objetivos de forma que se aumente el rendimiento.
  • Desarrollo en cascada. Esto casi lo dejo para otro post, tan grande es la confusión que observo respecto a este término, y su vinculación con CMMI y muchos otros conceptos.

 CMMI es desde luego un método imperfecto a la hora de evaluar la madurez de las empresas y los procesos, pero tiene muchos puntos a su favor:

  • No hay muchos métodos de evaluación de la madurez
  • Es un método en constante evolución y mejora. Actualmente CMMI DEV está en su versión 1.3.
  • Se integra muy bien con prácticamente todas las metodologías de ciclo de vida.
  • Es un modelo extendido a nivel mundial, y está diseñado para comparar uniformemente a organizaciones de todo el mundo.
  • Para las empresas, es un modelo de evaluación ventajoso: proporciona prestigio, y el “sello” de calidad queda referido a la empresa, no a sus individuos. Los individuos se van o vienen, pero los beneficios se quedan en la empresa.

Bueno , hasta ahora hemos visto que usar CMMI en comparación con otras metodologías, no es adecuado, y que se desprestigia injustamente a este modelo (en la mayoría de los casos, por ignorancia o para crear prestigio por comparación), pero no pensemos que por ello, es perfecto, ni tiene defectos. Me guardo para un post el detallar los problemas y defectos de CMMI como modelo, y su mayor talón de aquiles: las pésimas implementaciones como metodología que se hacen a veces, cuando el único objetivo es “tener el sello de calidad”.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s