Metodologías ágiles y modelos de procesos software (CMMI e ISO)

“Cada década más o menos las metodologías de desarrollo entran en conflicto. La 1 ª Década del siglo 21 no ha sido diferente, con los partidarios de los métodos ágiles en batalla con el mundo de CMMI"— Robert Austin n este capítulo se tratará por un lado, la diferencia, y por otro, como se complementan las metodologías ágiles y los principales modelos de procesos, como CMMI-DEV (Capability Maturity Model Integration for Development) (CMMI Product Team, 2010) o ISO/IEC 12207 (ISO, 2008). De hecho son cada vez más las empresas que han combinado ambos enfoques y muchas las que encuentran la necesidad de hacerlo, aprovechando las ventajas de las metodologías ágiles y de modelos como CMMI-DEV o ISO 15504.

10.1 Modelos de procesos (CMMI e ISO/IEC 12207) y las prácticas ágiles

Pueden ser muchas las razones de por qué se perciben los métodos ágiles y CMMI-DEV como elementos opuestos. Puede que las primeras implantaciones de CMMI-DEV fueran en organizaciones de gran tamaño, y las primeras implantaciones ágiles fueran realizadas en empresas pequeñas, pequeños equipos o con requisitos volátiles.

Capítulo

10

164

Tampoco se debe olvidar la mala aplicación, interpretación y evaluación de CMMI-DEV en empresas, donde los implantadores y/o evaluadores olvidan el negocio de la empresa, y la ingeniería del software que más se adapta a la organización, generando cantidades inútiles de sobredocumentación para justificar la implantación del modelo. Quizás también por la terminología, “institucionalizar”, “repetible”, etc., frente a “integración continua”, “refacto- ring”, “iterativo e incremental”, etc. O quizás porque CMMI-DEV o ISO/IEC 12207 se vean antiguos y los métodos ágiles algo moderno; aunque prácticas clave en los métodos ágiles, como el ciclo de vida iterativo e incremental (de los años 60), o la refactorización (de los año 90), son anteriores a la aparición de CMMI-DEV o ISO/IEC 12207.

Como indica Austin (Austin, 2007), entre las metodologías de desarrollo aparecen conflictos cada cierto tiempo. La batalla entre las metodologías ágiles y los modelos de proceso como CMMI-DEV o ISO/IEC 12207 persiste desde hace ya unos años. Aún así, el uso de prácticas ágiles se utiliza cada vez más junto con los modelos de procesos. Incluso destacados autores del mundo ágil, como los padres de Scrum, sugieren que existe una gran sinergia al utilizarlas (J. Sutherland & Johnson, 2010).

CMMI-DEV (CMMI Product Team, 2010) es actualmente estándar de facto para la mejora de procesos y la determinación de los niveles de madurez en las organizaciones. CMMI-DEV y las metodologías ágiles comparten característi- cas, aunque se encuentren en diferentes niveles de abstracción. No están necesariamente en competición, y, de hecho, pueden ser complementarias. A continuación se listan las características más relevantes de los modelos de proceso (como CMMI-DEV o ISO/IEC 12207) respecto de las buenas prácticas ágiles:

Un modelo de procesos se centra en el qué se espera encontrar en una organización, mientras que metodologías y métodos ágiles se centran en el cómo elaborar productos del ciclo de vida del software. En algu-

165

nos puntos el modelo de procesos puede mostrar productos de trabajo típicos, pero son recomendaciones o ejemplos, no obligaciones. Un modelo de procesos no establece orden en la ejecución de los pro- cesos, ni determina un ciclo de vida, son las metodologías quienes de- terminan este punto, recomendando por ejemplo el ciclo de vida itera- tivo e incremental.

Un modelo de procesos muestra áreas de proceso, no procesos en sí. Muestra tipologías de proceso, que luego en cada organización pueden instanciarse de diferente manera, y pueden existir numerosas corres- pondencias entre “áreas de proceso” y “procesos” de la organización, etc. De hecho las evaluaciones de un modelo de procesos tienen (o de- bieran tener) el objetivo de interpretar el modelo en la organización concreta, y no el buscar una relación uno a uno entre áreas de proceso y procesos de la organización.

Llevar los procesos al extremo, no aceptando prácticas ágiles, es tan perjudicial como llevar prácticas ágiles al extremo opuesto, sin incorporar características consideradas “no ágiles”. Y esto produce resultados insatisfactorios en los proyectos, en las metodologías y especialmente en las personas.

Esta es una de las barreras más arraigadas actualmente en la mejora de procesos y el desarrollo software en el mundo ágil. Ya sea con la frase “los procesos implican ciclos de vida en cascada” o sustituyendo la palabra “procesos” por algún modelo de procesos concreto, principalmente CMMI-DEV o ISO 12207: “No implantamos CMMI-DEV porque implica ciclo de vida en cascada”, “ISO 12207 no funciona porque trabajamos de manera ágil, iterativa”.

En las especificaciones de los modelos de mejora y evaluación de procesos actualmente más conocidos no existe ninguna mención explícita que indique secuencia, fases o compartimentos estancos entre actividades. El ciclo de vida en cascada es mencionado solamente una vez, junto el ciclo de vida iterativo e

166

incremental en CMMI.-DEV Asimismo, el modelo de procesos de referencia ISO/IEC 12207 (utilizado junto con la norma ISO/IEC 15504 en las evalua- ciones de la calidad del proceso de desarrollo software) tampoco hace mención a ningún aspecto relacionado con un ciclo de vida en cascada. De hecho, indica explícitamente que el orden de los procesos indicados en la norma no preesta- blece ningún tipo de secuencia.

10.2 Relación entre Scrum y las áreas de proceso CMMI-DEV

Como se ha visto en capítulos anteriores, Scrum es fundamentalmente una metodología para la gestión de proyectos. En este sentido, CMMI-DEV y las prácticas ágiles están en diferentes niveles de abstracción. CMMI se enfoca en lo que debe hacer la organización (incluyendo los proyectos software) y Scrum en cómo tiene que hacerse una gestión de proyectos ágiles. Como indicaba Glazer y otros autores, (Glazer et al., 2008) Scrum brinda un “how-to” de la gestión del proyecto software. Los métodos ágiles, como Scrum, contienen los pasos de cómo trabajar en entornos particulares (Paulk, 2001)(Glazer et al., 2008). En ese sentido, pueden encontrarse diferentes estudios que intentan unir los modelos de desarrollo de procesos y las prácticas ágiles, como por ejemplo (Glazer et al., 2008) o (J. Sutherland & Johnson, 2010). Estos autores comentan que tanto CMMI como los métodos ágiles pueden trabajar juntos. En el caso de Scrum, (J. Sutherland et al., 2008) y (Jakobsen & Johnson, 2008) discuten sobre la relación entre el nivel 5 de madurez de CMMI-DEV y Scrum. Estudios similares, como (Marcal et al., 2007)(Jakobsen & Sutherland, 2009)(Potter & Sakry, 2011) identifican equivalencias entre ambos elementos.

A continuación se analizarán las buenas prácticas de las áreas de proceso correspondientes a la gestión de proyectos en CMMI-DEV y como pueden ser cumplidas con las prácticas ágiles de Scrum. Las áreas de procesos de CMMI-

167 DEV implicadas son las siguientes32_:

Integrated Project Management (IPM) Project Monitoring and Control (PMC) Project Planning (PP)

Quantitative Project Management (QPM) Requirements Management (REQM) Risk Management (RSKM)

Supplier Agreement Management (SAM)

Para que un área de proceso sea correctamente implementada, deben alcanzarse las metas específicas definidas para esa área de proceso, que a su vez se consi- guen mediante la implementación de las prácticas específicas de cada meta. Cuando se va a evaluar la implementación de las prácticas se comienza desde abajo hasta arriba, esto es, evaluando en primer lugar el cumplimiento de las prácticas específicas de cada meta específica, posteriormente las metas específi- cas y luego las áreas de proceso.

Las relaciones entre las metas específicas de estas áreas de proceso y las prácticas de Scrum se ven en la Tabla 12. La primera columna contiene las metas específicas (o SG, del término inglés specific goal) de CMMI-DEV y la segunda contiene el grado de apoyo por parte de Scrum. Estos resultados provienen de un estudio realizado en el año 2012 y publicado por Javier Garzás y Mark Paulk en (Garzás & Paulk, 2012). Así mismo pueden encontrarse trabajos similares relacionados con la norma ISO/IEC 12207 (Garzás et al., 2011).

32 _{Los nombres de las áreas de proceso fueron tomados de la versión original, en}

168

Área de proceso Apoyo por parte de Scrum

Requirements Management (REQM)