CMMI y la agilidad: el largo y sinuoso camino a la paz

Ya había escrito sobre el asunto, basado en lo que SEI había publicado alguna vez. Hace unos meses, el SEI publicó un artículo mucho más extenso sobre la relación de CMMI y Ágil, analizando la historia de CMMI y del enfoque ágil, los problemas de comunicación entre ambas comunidades, y de la posibilidad de coexistencia.

En el enfrentamiento (si es que se puede usar esta palabra) entre ambos paradigmas, es el SEI el que, desde hace un tiempo, se ha encaminado a mostrar que la confrontación es, no solo innecesaria, sino que perjudicial.

Por su parte, la comunidad ágil, en tanto comunidad, no tiene una voz unificada: las reacciones que he escuchado incluyen la declamación de victoria (el SEI se rinde ante la victoria de la agilidad y no quiere perder su base de cliente), la indiferencia, o el acuerdo con la visión del SEI. Yo tiendo a compartir esta última opinión.

En este artículo, que no es una excusa para no leer el documento original, recorro los puntos que me parecen más interesantes. El documento se defiende de las acusaciones que relacionan CMMI con cascada, diciendo algo que es cierto: CMMI es básicamente un conjunto de objetivos, y las prácticas no son más que puntos de partida que sirvan para guiar al que adopte CMMI en la forma de lograr esos objetivos.

CMMI no es un estándar, lo que hace que esas prácticas no sean obligatorias. CMMI está injustamente asociado con el desarrollo en cascada: las prácticas y los objetivos no son procesos, nada específica que se deban ejecutar en un determinado momento del proyecto. El documento desliza críticas a sus propios appraisals por no tener en cuenta que CMMI no establece requerimientos, sino un marco para organizar el análisis y las acciones de mejora, diciendo textualmente que:

"However, for people and organizations that do not have the skills or experience to understand, interpret, and implement the practices and goals to their specific contexts, the informative material takes on the mantle of requirements. This situation is also true for appraisal teams and lead appraisers. Thus, the over-emphasis on specific model examples, typical work products, and subpractices often results in prescriptive processes with little gain in quality or organizational performance. "

Salvando el hecho de que a pocos puede culpar el SEI más que sí mismo de este problema (tal vez debe revisar a quienes le da patente de appraiser) la frase me parece gran resumen: el problema es que se toma el marco de CMMI, pensado para guiar y ayudar a pensar, analizar y actuar como requerimientos que toman la fuerza de mandamientos.

Yo veo un problema adicional, e iría más lejos: veo valor en CMMI, pero no veo valor en la certificación de CMMI. El hecho de que el mismo SEI cuestione a sus appraisals en un documento público no mejora mi apreciación de la certificación precisamente. Pero el problema, emho, no es este (que es coyuntural) sino otro (más bien estructural): yo en mis procesos de desarrollo hago unas cuantas cosas, que tienen que ver con algunas áreas de proceso de CMMI (como por ejemplo Verificación, Validación y hasta Análisis y Resolución de Decisiones), pero no me detengo a dejar 'rastro' (documentos formales) de estas actividades porque decido que no aportan valor. Eso provoca que un SCAMPI juzgue que mi proyecto no cumple con los objetivos de esas áreas de proceso. Me encuentro con un problema: si bien el proceso aporta valor, para llegar a la certificación tengo que perder valor.

Definitivamente, y dejando de lado cuestiones comerciales, la certificación no agrega valor.

Otro aspecto interesante del documento es su análisis histórico. Se hace una recorrida por la historia del desarrollo de CMMI, partiendo de los problemas del DoD y su necesidad de resolverlos. Admite que la asociación Cascada/CMM está justificada, ya que CMM se focalizaba en una serie de procesos y actividades que intentan obtener la descripción acabada de lo que hay que hacer antes de comenzar. Es una pena que no pueda ver de primera mano esto, ya que nunca leí nada de CMM de primera mano del SEI y han retirado la especificación, dejando solo información para la actualización de una a otra.

Menciona, además, algunas características del entorno que vio nacer a CMM: se trataba de un entorno donde lo que se buscaba era cubrirse, no buscar la mejor solución. Esto estaba generado por la naturaleza de entidad estatal del DoD y su necesidad de registración y transparencia para cualquiera que preguntara que se estaba haciendo con el dinero público, la forma de contratar y la naturaleza de los problemas que resolvían: software relacionado al control de aviones, misiles, instrumental médico y cosas por el estilo. Este último punto (negar la agilidad para desarrollos donde esté en juego la vida humana) es discutible, y no lo tengo claro: aplicaría un método ágil para construir el software de control de un misil?.

Como dice el artículo, lo que puede aportarle CMMI a un enfoque ágil son métodos y prácticas para apoyar y guiar la adopción de metodologías ágiles en una organización: básicamente, foco en la definición e integración de los equipos y el proceso. No es que no se pueda guiar la adopción de un enfoque ágil en una organización grande y compleja sin CMMI, pero CMMI ayuda a que los esfuerzos de adopción y expansión del enfoque ágil no queden en el folclore oral de la organización.

Asimismo, se reconocen algunos puntos que ningún agilista está dispuesto a negar: en necesario acordar una visión global de la arquitectura, a veces es necesario escribir documentación y, en definitiva, sin algo parecido a un proceso nos vamos al demonio.

Es muy interesante la comparación que se hace entre el paradigma ágil y CMMI en una serie de puntos. En particular, me interesaron dos puntos:

• El primero, que tiene que ver con el foco en la organización: mientras CMMI se focaliza en la organización completa, el paradigma ágil se focaliza en cada proyecto y en el equipo. Creo que vale la pena recordar que la focalización en la organización puede llevarnos al peligro de querer optimizar el funcionamiento de la operación de la organización y no del proyecto, y esto es, definitivamente, un peligro. Trato de explicarme: puestos a mirar la organización como un todo, nos podríamos sentir tentados de reducir los tiempos muertos de un equipo de analistas, cuando en realidad, desde el punto de vista de un proyecto complejo y particularmente sensible, es conveniente asumir esos tiempos muertos. No veo mayor problema aquí siempre que se recuerde que, a veces es conveniente que el foco esté en el proyecto antes que en la organización.
• El segundo, es el que tiene que ver con la confianza: el paradigma ágil requiere la confianza casi como un prerrequisito. Yo veo esto como una debilidad, porque a veces, hay que hacer cosas aún cuando no hay confianza entre las partes. Vamos, en algún momento se empieza y uno no confía la primera vez.

Y por último, lo mejor: el SEI me da la razón a mí (ja) en que la evidencia de que la agilidad funciona es, hoy por hoy, puramente anecdótica. Esto no implica que la agilidad no funcione, sino que es necesario un esfuerzo de formalización de los resultados.