CMMI y Agilidad

En este blog vamos a hacer una explicación detallada de cómo combinar la agilidad o agile con el modelo de calidad CMMI y veremos casos reales en los que la comunión entre estas dos grandes ideas se ha logrado con éxito. Así como veremos el estado actual de CMMI.

Tradicionalmente se ha percibido que estas dos ideas son contrarias, y no tienen por qué.

CMMI es un modelo de evaluación que sirve para determinar la madurez o capacidad de llevar adelante los proyectos comprometidos por una empresa. Dicha madurez de la empresa se clasificará en cinco niveles.

 

CMMI 2.0

Antes de continuar tenemos que hacer un inciso muy importante aquí, ya que valoramos mucho a nuestros lectores, y queremos que la información proporcionada tenga un gran valor, para ello el contenido debe estar actualizado con las noticias más frescas posibles, y tener así una idea más clara del contexto.

CMMI surgió en 1987 como resultado de un contrato del gobierno con la universidad de Carnegie Melon, para tratar de resolver el problema de la fiabilidad con los proyectos de software. En 2012 la universidad transfirió la actividad de CMMI a una empresa privada que denominaron CMMI Institute, esto conllevó a que el modelo tuviera fines comerciales, más tarde en 2016 ISACA compra la empresa integrándola en su modelo de negocio y en 2018 ISACA anunció la versión 2.0. La versión anterior fue la 1.3, se lanzó en 2010, es gratis y está en español. La puedes encontrar en su web

Esto supuso un cambio radical ya que en la versión 2.0 tenemos estos cambios muy grandes. (Entre muchos otros):

• Tiene un coste mínimo de 150 dólares por descargar el PDF. (Hasta entonces el modelo siempre había sido gratuito). Se prohíbe la distribución de su contenido a terceros.
• Formato en línea opcional disponible para que el contenido sea fácilmente seleccionable y accesible. (De pago).
• Guía específica para ayudar a las organizaciones a adaptar y a escalar Scrum.
• Auditorías más frecuentes.
• Cambio en su formato (Supresión de las prácticas genéricas, y metas genéricas).
• Sustitución de áreas de proceso por áreas prácticas. (Veremos más delante de qué se trata)
• Guía de adopción de CMMI 1.3 a 2.0 (De pago).

La consecuencia fundamental que trae consigo es que no podamos compartir información del modelo CMMI 2.0.

No obstante, el modelo CMMI 1.3 aún sigue siendo muy utilizado en muchas empresas, ya que CMMI 2.0 es muy nuevo y la transición a 2.0 conllevará un largo tiempo. El objetivo de este artículo es divulgar los beneficios potenciales al unir estos dos conceptos tradicionalmente opuestos.

 

CMMI 1.3

Este modelo utilizará áreas de proceso que a su vez están clasificadas en categorías ¿Qué es un área de proceso?

Las áreas de proceso (PA) son un conjunto de prácticas que se realizan para conseguir unas metas.

Existen 22 áreas de proceso: (QPM, IPM, RSKM, PP, PMC, SAM, REQM, RD, TS,PI, VER, VAL, CAR, DAR, MA, PPQA, CM, OPM, OPP, OPF, OPD, OT). Las siglas están representadas en la tabla superior.

Éstas son las categorías en las que se agrupan:

• Gestión de proyectos (Project Management)
• Ingeniería.  (Engineering)
• Apoyo. (Support)
• Gestión de Procesos (Process Management)

La ilustración de arriba ayudará a entender cómo funciona. Cada área de proceso tiene un propósito, unas notas introductorias, unos objetivos específicos, unas prácticas específicas, unas prácticas genéricas y unos objetivos genéricos. Para ver más detalles visita la siguiente entrada de nuestro blog

Cuando las empresas satisfacen todas las áreas y en la medida óptima, podemos decir que será disciplinada y madura, tendrá entonces un nivel 5. Obtener un nivel 5 supone que la empresa pueda satisfacer las entregas dentro del tiempo programado. La industria exige cada vez más empresas con un nivel CMMI 3 o mayor.

Los beneficios de conseguir un nivel CMMI 5 son: (Alta predictibilidad y un producto mejor diseñado para la escalabilidad, adaptabilidad y confiabilidad). Apoya conceptos como los procesos, la documentación y a el seguimiento de un plan.

CMMI te dice qué hacer en líneas generales, pero no te dice cómo lograrlo, tampoco indica cómo debe ser el ciclo de vida.

 

Metodologías ágiles

Por otro lado, tenemos los frameworks ágiles, que surgen del manifiesto ágil y  se caracterizan fundamentalmente por la adaptabilidad al cambio, gracias a obtener productos potencialmente entregables en periodos de tiempo muy cortos, ayudando al cliente a ir descubriendo los requisitos lo antes posible (en el mundo de desarrollo de nuevos sistemas software, los requisitos no son completamente conocidos hasta después de que los usuarios trabajan con el producto).

Scrum es el marco de trabajo para la gestión ágil de proyectos más usado en el mundo, además aporta el ciclo de vida iterativo e incremental.

La complejidad de la gestión del desarrollo software requiere un proceso disciplinado (CMMI) y velocidad para adaptarse a los cambios. (SCRUM)

A pesar de esto, Scrum por sí solo no es suficiente, ya que no abarca actividades como:

• El control de versiones
• Integración continua
• La gestión de la configuración
• La gestión de riesgos
• Pruebas unitarias
• Integración
• Arquitectura
• Diseño
• Control de incidencias

Es decir, no abarca todas las áreas de proceso que se recogen en CMMI. Solamente aquellas relacionadas con la categoría de gestión de proyectos.

Kane y Ornburn realizaron estudios en los que se encargaron de realizar un mapeo en el que vincularon frameworks ágiles con la mayoría de áreas de proceso de CMMI (no todas). Donde las áreas de proceso relacionadas con la gestión de proyectos pueden ser cubiertas con Scrum, y, la mayoría de áreas de proceso relacionadas con la ingeniería del software pueden ser apoyadas por eXtreme Programming.

Éstas son las áreas de proceso relacionadas con la gestión de proyectos en el modelo CMMI v1.3

1. REQM - Requirements Management. (Gestión de Requisitos)
2. PP -Project Planning. (Planificación del proyecto)
3. PMC -Project Monitoring and Control. (Monitorización y Control del Proyecto)
4. IPM - Integrated Project Management. (Gestión Integrada del Proyecto)
5. QPM - Quantitative Project Management. (Gestión Cuantitativa del Proyecto)
6. RSKM - Risk Management. (Gestión de Riesgos)
7. SAM - Supplier Agreement Management. (Gestión de Acuerdos con Proveedores)

Y estas son las áreas de proceso relacionadas con la categoría de ingeniería del software a las se puede asociar el framework de eXtreme Programming (XP).

1. PI - Product Integration (Integración del producto)
2. RD - Requirements Development (Desarrollo de requisitos)
3. TS - Technical Solution (Solución técnica)
4. VAL –Validation (Validación)
5. VER – Verification (Verificación)

Implementar frameworks ágiles es una tarea difícil porque requiere un cambio cultural muy grande con respecto a las metodologías clásicas, es fundamental la educación, ya que vamos a tener un sistema donde va a haber una alta interacción con los clientes.

Mark Paulk, el principal contribuidor del modelo CMM, dice “El modelo CMM te dice qué hacer en términos generales, pero no te dice cómo hacerlo, los frameworks ágiles proporcionan un set de las mejores prácticas de cómo lograr una implementación para un modelo en particular”.

Además Paulk recalca: “Cuando implementas racional y apropiadamente los frameworks ágiles, obtienes prácticas de CMM nivel 2 y nivel 3”

En resumidas cuentas, los frameworks ágiles como Scrum y XP son métodos que pueden dar soporte a diferentes partes de CMMI. Combinar Scrum y las prácticas de CMMI puede producir resultados de mayor y mejor impacto que si cada uno trabajara por su cuenta. CMMI y agile se complementan.

 

Caso con Systematic

Systematic es una empresa de desarrollo software creada en 1985 que cuenta con más de 371 empleados distribuidos en oficinas de Dinamarca, Estados Unidos, y Reino Unido.

Las soluciones informáticas que ofrecen abarcan campos como: La sanidad, seguridad, inteligencia nacional y defensa, así como también ofrecen otro tipo de soluciones en el sector público y privado

¿Qué tiene de particular esta empresa?

 

Obtuvieron el nivel 5 de CMMI, y posteriormente han conseguido adaptar agile con éxito, combinando XP y Scrum, obteniendo unos resultados increíbles.

¿Cómo pudieron saber que tuvieron éxito?

 

Su experiencia de más de 20 años les ha permitido unificar un set de procesos para todos los proyectos software.

Esto les permite recopilar los datos sistemáticamente y obtener una visión de la capacidad y rendimiento de la organización.

 El hecho de que se use un proceso común hace que los trabajadores consigan cambiar de proyecto más fácilmente dentro de la empresa, además de compartir experiencias y lecciones aprendidas dentro de la empresa.

La habilidad de poder medir el rendimiento y la capacidad de la empresa, hizo que fuera posible y muy fácil comparar los resultados cuando se aplican nuevos procesos.

Estas son las ventajas que obtuvieron cuando consiguieron el nivel CMMI 5:

• Reducción del re-trabajo en un 38%
• La derivación de lo que puede variar una estimación es del 10%
• 92% de los proyectos son entregados a tiempo
• Fueron capaces de entregar productos en el periodo, costo y calidad esperado, usando el 69 % del esfuerzo comparado con CMMI 1.
• Enfocarse en los procesos de gestión e ingeniería conlleva el 9% del esfuerzo
• Los clientes cada vez más están solicitando un nivel de CMMI 5, y es clave para obtener mejores contratos con las entidades de defensa y sanidad gubernamentales.

Ventajas cuando adquirieron SCRUM:

Los estudios demostraron rápidamente que los procesos son optimizados cuando aplicamos Scrum.

• La productividad en grandes proyectos fue duplicada
• La cantidad del re-trabajo es reducido un 40%  adicional.

En la siguiente figura podemos ver la evolución de forma gráfica

El proceso obtenido es el resultado de combinar los procesos de CMMI, éstos establecen una línea base del proyecto expresada cómo un Product Backlog, se desarrolla así el proyecto con iteraciones (sprints) de un mes.

¿Cómo lograron adaptar Scrum teniendo ya CMMI 5?

 

Identificando los objetivos y necesidades

En CMMI v1.3 tenemos un área de proceso denominada “Organizational Process Focus” (OPF) cuya función establecer e implementar un plan para mejorar los procesos.

Es aquí donde Systematics decidió implementar LEAN como herramienta para optimizar los procesos. La herramienta concreta que se utiliza es Lean Software Development que es como un toolkit ágil.

Pero el uso de una herramienta ágil no te convierte en ágil, si lo que quieres es comenzar a ser ágil lo primero que tienes que hacer es cambiar la cultura de las personas que están en la empresa.

Tenemos que interiorizar primero qué es la agilidad, por qué surge, cuáles son sus valores y sus principios.

(Puedes encontrar los valores y principios explicados en las siguientes entradas de nuestro blog)

• Explicación de los valores ágiles
• Principios ágiles parte 1
• Principios ágiles parte 2
• Principios ágiles parte 3

¿Cómo lograron en Systematics conseguir esto? Se elaboraron talleres, se realizaron actividades, se proporcionaron libros para aprender cómo funciona Lean, hasta los jefes de proyectos fueron entrenados para aprender Lean Software Development.

Lean y OPF nos dicen que las personas encargadas del proceso tienen que ser responsables y estar facultadas para ello.

Una vez las personas fueron formadas, se comenzó a utilizar Scrum en algunos proyectos seleccionados, esto fue lo que denominaron proyectos piloto. ¿Cuál fue el resultado de crear proyectos piloto?

Se confirmó que SÍ es posible utilizar Lean como fuente de identificación para aplicar nuevas mejoras.

Se decidió adoptar Scrum y software basado en historias dentro de la organización.

Se crearon PAT (process action teams o equipos de acción del proyecto) que son básicamente equipos que vinieron a aportar la experiencia y conocimiento adquirido en los proyectos piloto.

Es importante recalcar que Jeff Sutherland (uno de los padres de Scrum) impartió un seminario donde se encargó de formar en Scrum a las personas que iban a participar en los proyectos ágiles.

 

Guía de integración de CMMI y Agile

 

Systematic definió una institucionalización (es cómo se define a la forma de trabajar dentro de una organización) en la que tomaron las 12 prácticas genéricas (asociadas con todas las áreas de proceso) propias de los niveles 2 y 3 de CMMI, y describieroin cómo se deberían implementar con Scrum.

GP 2.1 Establecer y mantener una política de la organización para planificar el proceso:

El objetivo es definir las expectativas de la organización en relación con el proceso y hacerlas visibles a aquellos miembros de la organización que están afectados.

El primer paso para poner en marcha la institucionalización de frameworks ágiles es establecer cómo y cuándo serán utilizados en la organización.

Se puede hacer una agrupación de políticas en función del tamaño, tipo de producto, tecnología y otros factores.

GP 2.2 Establecer y mantener un plan para realizar el proceso:

Es necesario definir un proceso con una secuencia de pasos que nos digan la información necesaria para describir el funcionamiento del proyecto. Este plan también puede contener aspectos esenciales del proyecto como la manera en la que se implementan las  prácticas genéricas. En Scrum, esta información puede ser capturada en un Sprint Backlog.

GP 2.3 Proporcionar los recursos adecuados para realizar el proceso:

Es necesario adaptar cada proyecto con los recursos más oportunos, estos pueden ser profesionales, herramientas y financiación. En Scrum estas necesidades pueden resolverse durante el Sprint Planning, e incluso adaptarse cuando se considere necesario.

GP 2.4 Asignar la responsabilidad y la autoridad para realizar el proceso, desarrollar los productos de trabajo y proporcionar los servicios del proceso.

Para que un proyecto tenga éxito es fundamental definir las responsabilidades. En Scrum no hay una figura de jefe de proyecto, los equipos son multifuncionales y auto organizados, la responsabilidad es compartida. Además de esto, tenemos el rol del Product Owner cuya responsabilidad en pocas palabras es especificar y priorizar el trabajo y el rol de Scrum Master que es el responsable de que se siga el proceso Scrum.

GP 2.5 Formar a las personas para realizar o dar soporte al proceso según sea necesario.

Formar a las personas va ayudarnos a respetar la institucionalización. Las formaciones se pueden dar de muchas maneras: (Formación durante el trabajo, sesiones de mentoring, clases y talleres).

GP 2.6 Poner los productos de trabajo seleccionados del proceso bajo los niveles de control apropiados. (Gestión de la configuración).

Tradicionalmente el propósito de un proyecto es entregar un producto final que contiene (código, manuales, sistemas de software, archivos de instalación, etc). Al implementar agile en nuestro proyecto, el objetivo vendrá dado por obtener la mayor satisfacción del cliente, en un tiempo acordado.  Esto no quiere decir que dejemos de lado el resto de actividades del proceso, sino que debemos armonizar ambos enfoques. Con agile vamos a hacer varias entregas de un producto potencialmente entregables. Y tendremos que tener un control sobre las versiones que se están tratando.

GP 2.7 Identificar e involucrar a los stakeholders relevantes del proceso, según lo planificado.

Esto claramente hace una referencia al manifiesto ágil cuando hablamos de una colaboración continua con el cliente y hacemos hincapié en la transparencia de Scrum, en la que todos sabemos lo que hacen todos en cualquier momento. Esto ayuda a que las personas se puedan involucrar según sea necesario.

GP 2.8 Monitorizar y controlar el proceso frente al plan para realizar el proceso y tomar las acciones correctivas apropiadas.

¿Cómo monitoreamos los sucesos en Scrum? Con las Dailys (Daily Scrum Meeting) inspeccionamos el Product Backlog, informamos qué hemos logrado, qué vamos hacer y que impedimentos hemos tenido.

Además, podemos dar apoyo a esta práctica genérica con el Burndown Chart, que es un gráfico que nos indica qué trabajo hemos logrado y cuánto nos queda por hacer. Scrum permite la adaptabilidad del plan permitiendo que el Prodcut Owner inspeccione y adapte el Product Backlog en función del mínimo producto viable y conseguir maximizar el retorno de la inversión (ROI).

GP 2.9 Evaluar objetivamente la adherencia del proceso y de los productos de trabajo seleccionados y localizar las cosas que no cumplimos.

El Scrum Master es el principal responsable de asegurarse que se siguen las prácticas de Scrum, siguiendo el proceso y eliminando impedimentos.

El Product Owner por su lado es el responsable de maximizar el valor del negocio, definir los requisitos del cliente y priorizar el Product Backlog.

GP 2.10 Revisar con el nivel directivo las actividades, el estado y los resultados del proceso y resolver las cuestiones.

El propósito de esta práctica genérica es proporcionar la visibilidad apropiada del proceso al nivel directivo. La administración necesita obtener:

• La transparencia de los datos producidos por el Burndown Chart.
• Los datos de los defectos

Construyendo así un tablero personalizado en el que se pueda ver el estado del proyecto.

Las responsabilidades de la administración son:

• Eliminar los impedimentos surgidos por los equipos Scrum que no hayan podido eliminar por sí mismos.
• Garantizar el crecimiento y la trayectoria profesional del personal.

La lista de impedimentos generados por los equipos de Scrum tiene que ser transparente para todos, y en especial para la administración, ya que es su responsabilidad asegurarse de que estos impedimentos sean eliminados.

GP 3.1 Establecer y mantener la descripción de un proceso definido.

Podemos decir que esta práctica consiste en refinar la GP 2.2. La diferencia radica en que ésta práctica se de en todos los proyectos de una organización y no solo exclusivamente en unos proyectos seleccionados. Lo que se consigue así, es que la variación entre los frameworks ágiles que se usen en los distintos proyectos sea mínima, permitiendo así mayor intercambio entre proyectos, personas y herramientas dentro de la organización.

GP 3.2 Recoger experiencias relativas al proceso procedentes de la planificación y realización del proceso para dar apoyo a futuros enfoques de frameworks ágiles.

El objetivo de esta práctica es aprender de los resultados de los proyectos de forma individual.  En el marco de Scrum, podemos asociar esta actividad a las Retrospectivas.

 

Críticas a CMMI y cómo han sido resueltas con Agile

Ha habido una corriente de críticas al modelo CMMI, debido a malas implementaciones. De hecho, hay una lista de “críticas bien conocidas” de malas implementaciones, una buena forma de enfrentarlas es aplicar Scrum.

 

Conclusiones

El éxito en esta empresa, además de la explicación mostrada en párrafos anteriores, demuestra que CMMI y Scrum pueden complementarse y trabajar con éxito. Los resultados obtenidos son mucho mejores que si Scrum o CMMI trabajaran de forma independiente. Esto lo podemos ver analizando los resultados, por ejemplo en Systematic, cuando aplicaron Scrum teniendo previamente un nivel CMMI 5, se mejoran la productividad, en relación a procesos tradicionales, reduciendo al 50% la cantidad de defectos, re-trabajo y sobrecarga de proceso.

Este artículo ha presentado una forma en la que las prácticas genéricas de CMMI pueden institucionalizar prácticas ágiles además de utilizar Lean Software Development como una manera de identificar mejoras en una empresa con CMMI nivel 5.