En 1982 el Departamento de Defensa de EE.UU. formó un grupo para analizar los problemas relacionados con el software y su desarrollo. Esto derivó en el establecimiento, en 1984, del Software Engineering Institute(SEI) en la Universidad de Carnegie Mellon. A inicios de 1986, el SEI y la Mitre Corporation, liderada por Watts Humphrey, comenzaron a desarrollar un esquema de madurez de procesos, CMM. "Un modelo para juzgar la madurez de los procesos de software de una organización y para identificar las prácticas claves que son requeridas para incrementar la madurez de esos procesos.", según el sitio web del SEI.
En resumen, consiste de un grupo de prácticas claves, que son divididas en 5 niveles representando las etapas que las organizaciones deben cumplir para ser "maduras". Los niveles son:
1. Inicial (caótico, ad hoc, heroico)
2. Repetible (gestión de proyectos, disciplina de procesos)
3. Definido (institucionalizado)
4. Gestionado (cuantificado)
5. Optimizado (mejora de proceso)
La idea que CMM es "el" camino a seguir para salir del code and fix está bastante difundida y aceptada. Aunque muchos no tienen en sus planes obtener una certificación CMM o aplicar las prácticas recomendadas por este modelo, siempre existe una sensación de culpa por no hacerlo. Sobretodo cuando uno ve tan bien retratada la actualidad de su organización en la descripción del nivel 1 del modelo.
Creo que esta buena recepción de CMM tiene que ver con la relación que se establece entre su aplicación y la obtención de predecibilidad, control y eficiencia en el proceso de desarrollo. Esta asociación a veces es tan fuerte que se entienden como incuestionables las bondades del modelo y como innecesario el análisis sobre la conveniencia de seguirlo.
De todas formas, existen personas que no comparten esta visión de CMM y su impacto en el proceso de desarrollo.
Opiniones sobre CMM
James Bach
. . . CMM es una mitología particular de evolución de procesos de software que no puede alegar legítimamente ser una representación natural o esencial de los procesos de desarrollo de software.
"CMM fue entendido originalmente como una herramienta para evaluar la aptitud de los proveedores del gobierno [de EE.UU] para llevar adelante un proyecto de software contratado. Tal vez sea adecuado para este propósito; no lo sé. Mi preocupación es que también es pregonado como un modelo general para la mejora de procesos de desarrollo de software. En esa aplicación, CMM tiene serias falencias. Entre las empresas de desarrollo de software empaquetado, se encuentran Borland, Claris, Apple, Symantec, Microsoft, y Lotus, entre otras. Muchas empresas de este tipo raramente, por no decir nunca, administran sus documentos de requerimientos tan formalmente como describe CMM. Este es un requerimiento para alcanzar el nivel 2, por lo que todas estas empresas probablemente entrarían en el nivel 1 del modelo."
"CMM venera los procesos, pero ignora las personas... Humphrey y CMM mencionan las personas brevemente, pero también las condenan como no fiables y asumen que los procesos definidos pueden de alguna manera convertir la excelencia individual en algo menos importante. La idea que los procesos pueden compensar la mediocridad es un pilar de CMM, en donde las personas son aparentemente subordinadas a procesos definidos . . .
Para convertir la excelencia en algo menos importante las tareas para resolver problemas deberían de alguna manera estar contenidas en el proceso en sí. Nunca he visto un proceso de estas características, pero si existiera uno, sería extremadamente complejo."
The Immaturity of CMM, James Bach
James Bach es fundador y consultor principal de Satisfice, Inc. Ha sido desarrollador, tester y SQA manager en Apple, Borland y otras empresas. Ha sido investigador principal en STLabs, un laboratorio independiente de pruebas de software. Tambien fue parte del equipo que definió el cuerpo de conocimiento cubierto por el programa de certificación de Ingeniero en Calidad de Software para la Sociedad Americada para la Calidad.
Tom DeMarco
Una de las justificaciones más fuertes de CMM es que permite aumentar la calidad y productividad mientras disminuye el riesgo...sugiere que el mismo trabajo puede ser emprendido con menos riesgo en los niveles más altos. Pero existe otra interpretación que nos parece más probable: las organizaciones se convierten cada vez más adversas al riesgo mientras 'maduran'.
Una organización presionada para demostrar un incremento en su nivel CMM no buscará desafíos reales.
Mientras usted se convence más de la significación de la evaluación [positiva], más se siente inclinado a afrontar trabajo más complicado. Sube la apuesta. Puede poner a trabajar su gente en software que otras empresas de más bajo nivel no podrían construir. Si tiene la organización de desarrollo de software más refinada conocida hasta el momento por el genero humano, no tiene el más mínimo sentido darle a su gente el mismo trabajo que cualquier empresa mediocre puede hacer. Mucho mejor es torturar a la competencia tomando sólo grandes desafíos...
Subir la apuesta significa que el riesgo aumentará. Mientras usted es más competente, más riesgos toma. Estaría loco si no lo hiciera...
Si usted ya tiene una organización de nivel 2 o mayor de CMM recuerde esto: Los proyectos que más valen la pena son aquellos que lo hacen BAJAR un nivel completo en su escala de proceso. Tal vez esos sean los únicos que usted se puede permitir hacer.
Peopleware: Productive Projects And Teams, Tom DeMarco y Timothy Lister
Tom DeMarco es uno de los directores de Atlantic Systems Guild, un grupo de especialistas sobre sistemas con oficinas en EE.UU. y Gran Bretaña. En 1986, ganó el premio Warnier por la contribución durante su carrera al campo de la computación.
La carrera de DeMarco comenzó en Bell Telephone Laboratories donde formó parte del ahora legendario proyecto ESS-1. Años despues gestionó proyectos real-time para La CEGOS Informatique en Francia, y fue responsable de sistemas bancarios en línea distribuidos en Suecia, Holanda, Francia y Finlandia.
Ha dictado conferencias y consultorias en America, Europa, Africa, Australia y Medio Oriente, y ha escrito varios libros reconocidos, entre ellos Why does software cost so much? y Peopleware.
James Highsmith
"En el mundo del desarrollo de software, parece que el Capability Maturity Model del Software Engineering Institute es el Santo Grial. Aún los incredulos se preguntan si no hay algo mágico que se están perdiendo ... ¿Qué les da animo a los defensores de CMM para aplicar el modelo a todo el desarrollo de software?
Si yo estuviese caminando hacia un cohete a punto de ser lanzado al espacio, el hecho de que el equipo de software Orbiter Avionics de Lockheed Martin fue calificado con el nivel 5 de CMM calmaría algo de mi ansiedad. Un defecto trivial en 420.000 líneas de código es un alcance Monumental.
Sin embargo, si yo fuese un gerente en Netscape o Microsoft, y el equipo Orbiter Avionics anunciara que comienza a participar en la competencia de los navegadores web, el anuncio me causaría gracia. Un grupo en el nivel 5 de CMM no sobreviviría mucho tiempo en el agitado y cambiante mundo de la velocidad de Internet. En este mundo, la optimización es necesaria, pero insuficiente para el éxito."
"Hay practicantes de iniciativas de mejora de procesos cuya filosofia fundamental parece ser, 'si mejoramos el proceso, obtendremos mejores resultados automáticamente'. Por ejemplo, CMM mide los procesos establecidos, no los resultados. La 'madurez' de una organización es evaluada verificando una lista de procesos requeridos para cada nivel... Desde la perspectiva de CMM, el nivel 5 es mejor que el nivel 4 - más procesos significan más madurez. No obstante, no parece existir una evaluación sobre si un nivel especifico es apropiado para el desarrollo de un tipo particular de producto o si las empresas en el nivel 5 producen mejores resultados (según los clientes) que las empresas en el nivel 3 o 4."
Adaptive Software Development: A Collaborative Approach To Managing Complex Systems , James Highsmith
James Highsmith comenzó su carrera trabajando en el desarrollo del software para el programa espacial Apollo y desde entonces se ha desenvuelto como programador, project manager, consultor, y escritor.
Como director de Information Architects, Inc., Highsmith enseña y brinda consultoria sobre mejora de procesos para la calidad del software, gestión de proyectos y técnicas de desarrollo acelerado.
Es un destacado conferencista conocido a nivel internacional y en los últimos diez años ha trabajado en organizaciones de IT y de desarrollo de software en EE.UU, Europa, Australia y Nueva Zelanda.
CMM no es la "bala de plata"
Más allá de compartir o no las opiniones de estos autores, creo que el valor de conocerlas reside en desterrar la visión de CMM como "bala de plata" y comenzar a aceptar la necesidad de un analisis más profundo del modelo y la filosofía subyacente para decidir si representa el camino optimo para mejorar nuestra manera de trabajar.
Como personas relacionadas al desarrollo de software y conocedores de las dificultades existentes en esta actividad, siempre albergamos consciente o inconscientemente la ilusión que en algun lugar existe una definición detallada de la solución a nuestros problemas, una receta mágica infalible que otros conocen y que es aplicable a nuestro contexto.
De todos modos, las mejores decisiones para mejorar los resultados de nuestro trabajo no pueden basarse sólo en esa ilusión.
