El Blog de Pablo Fernando Sanchez

Leo en la Wikipedia que un oxímoron es «una figura literaria que armoniza dos conceptos opuestos en una sola expresión, formando así un tercer concepto que dependerá de la interpretación del lector. Dado que el sentido literal de un oxímoron —por ejemplo, un instante eterno— es absurdo, se fuerza al lector a buscar un sentido metafórico —en este caso, un instante que, por la intensidad de lo vivido durante el mismo, hace perder el sentido del tiempo». Pues bien, soy de la opinión que, aunque parezca un oxímoron en función de lo que nos tiene acostumbrado el mercado, no tenemos que oponer a los métodos ágiles y al Capability Maturity Model Integration (CMMI) —en su rol de representante de los métodos tradicionales— en una expresión como la del título. Ese aparente oxímoron diría: «¡métodos ágiles y CMMI!». Y digo aparente, porque en realidad no lo es.

Explico. Creo que...

• la industria está plagada de tecnócratas desorientados, quienes en lugar de hacer ingeniería están más pendientes de apoyar hasta el fin ciertos inexplicables fanatismos personales, lo cual nubla la visión abierta que DEBE tener un ingeniero, y...
• CMMI puede convivir perfectamente con métodos ágiles —al contrario de cómo se esfuerzan en demostrar, no son para nada opuestos.

Está bien, tal vez fui duro con la afirmación del primero de los puntos, pero la verdad es que ocurre... Veamos... Yo me casé una sola vez, con mi esposa y para toda la vida. Este es el único marco en el que acepto esto de casarse. Hay gente que, literalmente, se «casa» con una tecnología —sin siquiera cobrar por ello— exhibiendo una intolerancia general hacia las ideas de los otros. En todas sus formas, esta actitud de adversarios además de no ser razonable, es contraproducente para la tarea que se tiene entre manos: desarrollar software de la más alta calidad en el menor tiempo posible.

Que software libre, que software propietario, que métodos ágiles, que métodos tradicionales, que enfoque estructurado, que enfoque orientado a objetos, que tecnología de objetos, que Microsoft Visual Basic, que Java, etcétera. Vergonzoso... Las tecnologías están para que nosotros, los seres humanos que incurrimos en la ingeniería —seamos o no ingenieros—, las aprovechemos como mejor nos convenga... Nada más... Cada una de ellas puede convivir perfectamente con otra, si el proyecto lo justifica. No podemos ser fanáticos inquisidores en este marco. El fanatismo está para otras áreas en las cuales la lógica es distinta: fútbol, política, religión, etcétera. Pero no nos podemos permitir fanatismos en términos profesionales e ingenieriles.

Ahora bien, dejo de «hacer amigos» —aunque conozco muchos profesionales que me inspiran el más profundo de los respetos y que concuerdan con lo expresado— para focalizarme en la segunda de las afirmaciones, eso de que «CMMI puede convivir perfectamente con métodos ágiles».

En primer lugar, el Software Engineering Institute (SEI) de la Carnegie Mellon University, que es la entidad titular de los derechos de evaluación del modelo CMMI, no dice que tenemos que hacer todo lo que plantea dicho modelo. A pesar que CMMI puede aplicarse tanto en organizaciones grandes como en pequeñas, estas últimas suelen carecer, en gran medida, de los recursos y el conocimiento requerido para iniciar un proceso de mejora basado en CMMI.

Como CMMI es un modelo, por definición no es perfecto. Las prácticas del modelo necesitan ser interpretadas a la luz del trabajo a realizar y ser escaladas para proveer valor, no sobrecarga. Tenemos que ser lo suficientemente coherentes en nuestras labores de ingenieros para detectar aquellos puntos que nuestra organización no necesita o que en función de sus procesos no le conviene cubrir. Si hacemos esto y lo podemos justificar —cosa que no es negociable—, la evaluación arrojaría que es válido. Por lo tanto, podemos y debemos ajustar el modelo a nuestras necesidades particulares.

Por otro lado, al tiempo que CMMI da ejemplos de procesos y prácticas a nivel organizacional, no provee detalles específicos para los desarrolladores de software y los equipos que integran. Allí es donde entran en juego modelos de un nivel más bajo que ayuden a implementar las prácticas identificadas en CMMI. Ejemplos de ellos serían el Personal Software Process (PSP) y el Team Software Process (TSP), los cuales fueron desarrollados también dentro del SEI allá por 1998 por Watts Humphrey para complementar el «qué hacer» del CMMI —CMM en ese entonces— y acelerar la adopción proveyendo el «cómo hacerlo». Eso mismo se puede lograr mediante muchos y distintos modelos existentes, o nuevos o híbridos por modelar para el caso.

Además, también conviene complementar o extender CMMI con otras iniciativas de mejor práctica como las prácticas de línea de producto, la gestión del valor ganado —o «Earned Value Management» (EVM)—, sistemas basados en COTS, adquisición, mercadeo, Six Sigma, ISO 9001 y un amplio etcétera.

Más allá de su reputación, CMMI, PSP y TSP cubren el optimismo infundado, la irresolución de cronogramas y las metas no cumplidas en una forma ágil. Esta conclusión surge si comparamos los enunciados del «Manifiesto Ágil» con TSP, por ejemplo. Las relaciones son claras, pero por supuesto: tenemos que saber un poco de CMMI, PSP, TSP y agilidad para notarlo. En próximos artículos detallaré este asunto. Por ahora, lo dejo para que quien lo desee investigue un poco.