Es un hecho que tanto CMMi como el
desarrollo Ágil han sido dos corrientes a las que muchas organizaciones
(pequeñas, medias y grandes) atribuyen el éxito o fracaso de sus proyectos de
desarrollo de software.
Desde su origen, es evidente que CMMi ha
sido adoptado por organizaciones en donde el manejo del riesgo, presupuesto,
grandes equipos de trabajo y tiempos son piezas fundamentales en un ambiente
contractual. Por otro lado, el desarrollo Ágil ha tenido un mayor uso en
organizaciones pequeñas, con equipos de trabajo reducidos y requerimientos
volátiles. Estas y otras características dan lugar a preguntarse si en realidad
ambos modelos son polos opuestos o si existen posibilidades de combinarlos para
crear una sinergia de beneficio en el desarrollo de software, y más importante
aún poder saber cuándo se debe aplicar dicha combinación.
La publicación del Software Engineering
Institute titulada “CMMI or Agile: Why Not Embrace Both!” hace énfasis en
indicar que muchos de los malentendidos que ambas perspectivas sufren es debido
al mal manejo de la terminología, falta de información exacta y mal uso de los
modelos. En el caso de CMMi es errado pensar que debe ser aplicado cuando en
realidad debe ser implementado dado que no es un proceso estándar sino un
modelo del cual se debe aprender y relacionar a la situación actual de la
organización. Para el desarrollo Ágil, los valores presentados en el Agile Manifesto son comúnmente mal interpretados tendiendo como consecuencia una
errónea percepción de polaridad entre CMMI y Agile.
Neil Potter y Mary Sakry en su
publicación “Implementing scrum (agile) and cmmi together” indican que SCRUM es
un ejemplo de implementación de algunas prácticas descritas en CMMi Nivel 2 y
3. Aunque presentan una tabla de mapeo entre algunas prácticas de CMMi y
algunas prácticas de SCRUM, considero que el solo hecho de llegar a comprender
SCRUM a una organización puede requerir tiempo y esfuerzo que no necesariamente
debe ser en paralelo a una implementación de CMMi.
Antes de tomar una decisión sobre cuando
implementar CMMi y Ágil en conjunto, considero importante conocer primero la
organización y los problemas que se desean solventar. Es vital definir a donde
se quiere llegar ya que no es lo mismo tener una organización que requiere
mejoras a nivel de desarrollo y testing de software que tener una organización
que requiere solamente mejoras a nivel de administración de procesos de riesgo
y presupuesto.
Si la organización es pequeña al igual
que sus proyectos, la misma teoría nos da la pauta a recomendar iniciar la
implementación de una metodología ágil que se va a enfocar principalmente en la
interacción con el cliente, productos funcionales y desarrollo iterativo incremental.
Si la organización es grande (por ejemplo
stakeholders y desarrolladores distribuidos geográficamente) y la interacción
con el cliente no es tan viable, se hace evidente que implementar CMMi sería lo
más adecuado debido a la necesidad de tener procesos que permitan optimizar los
resultados en este tipo de ambiente que su naturaleza contractual requiere.
Dado que CMMI se centra en la
administración de procesos a través de prácticas y Ágil se centra en la
actividad de desarrollo como tal, creo que la combinación de ambos puede traer
grandes beneficios. La decisión de cuando utilizarlas en conjunto puede darse
cuando por ejemplo la organización pequeña mencionada anteriormente crece o se
ve en la necesidad de crear o mejorar procesos que optimicen su rendimiento, en
este caso es viable optar a implementar CMMi sobre una base Ágil sólida que no
va a desaparecer como producto de dicha unión. De igual forma, si la
organización grande se encuentra con la necesidad de implementar prácticas ligadas directamente
al desarrollo de software, una metodología Ágil puede proveer las herramientas
necesarias para concretar la implementación de las prácticas.
Tanto en la implementación individual de
cada modelo como en la combinación presentada anteriormente, el tomar de
referencia casos de éxito y fracasos no garantiza el éxito al momento de
realizar la unión. Algunas variables como lo son el factor cultura, infraestructura,
tamaño y visión organizacional provocan diferentes resultados que pocas veces
son predecibles dado la variación que dichos aspectos poseen. La motivación a
unir estas dos perspectivas no debe tener como objetivo por ejemplo el subir de
un nivel de madurez para ser evaluados y certificados, sino enfocarse en
mejorar los procesos y actividades asociadas a un proyecto de desarrollo de
software que tenga como output un producto útil y de valor para el usuario
final.
