Translate

lunes, 23 de julio de 2012

CMMI y Agil Software Development




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.