Thinking-in-process: Combinando CMMI y SCRUM (I)

Estos posts han sido publicados inicialmente en el Lab "Project Management SCRUM" de TheProject.ws.

En el anterior artículo se introdujo el contexto de los diferentes tipos de metodologías, tanto tradicionales como ágiles, y algunos factores que determinan el éxito de su aplicación a las organizaciones.

En este artículo se profundiza en algunos de dichos factores y se comparan dos enfoques que han ganado mucha popularidad en última década: el modelo de madurez CMMI y la metodología de gestión de proyectos Ágiles.

Equipos grandes vs pequeños

El tamaño de los equipos, y como están organizados entre ellos, es uno de los factores más importantes que se debería tener en cuenta a la hora de escoger qué enfoque metodológico y organizativo queremos seguir.

Equipos pequeños, grandes y organizaciones de múltiples equipos pequeños

Los equipos pequeños, p.e. menores de 10 miembros, típicamente incorporan con más facilidad las metodologías ágiles como SCRUM debido a dos motivos fundamenteales: 1) afrontan proyectos con menos riesgo, y por tanto, con menores necesidades de mitigarlo mediante las prácticas de calidad y 2) tienen menos personal y eso dificulta su dedicación a las mencionadas prácticas de calidad.

Los equipos grandes, p.e. mayores de 15 o 20 personas, por contra muy probablemente realicen proyectos con un tamaño y riesgo mucho mayor que justifica la realización de muchas actividades de calidad, y además podrán tener miembros dedicados a actividades de calidad concreta (p.e. diseño de procesos, testing, auditorías, métricas). Estos equipos típicamente pueden adoptar y adaptar una metodología como RUP [1] y obtener el provecho de tener definidos los procesos de desarrollo donde participan equipos grandes con muchos roles diferentes.

Existen otros escenarios donde una organización mediana o grande tiene múltiples equipos que tienen poca o ninguna relación entre ellos. Esto puede pasar en una empresa que realice proyectos para clientes o bien, en menor grado, en una que desarrolle un producto complejo con equipos encargándose de componentes o subproductos. En ambos casos,

En estos escenarios, especialmente si no existe un departamento de procesos o una tradición en la gestión de procesos, suele ser más sencillo extender el modelo monoequipo de SCRUM a múltiples equipos debido a la facilidad que éste introduce para el seguimiento de los equipos (con las herramientas roadmap y sprint backlog).

Por tipos de proyecto (web, alta tecnología)

La naturaleza de los productos realizados por los proyectos es otro factor que determina que enfoque metodológico y organzativo es más ventajoso.

El desarrollo de software presenta condicionantes diferentes al de otro tipo de productos. En general son proyectos donde la tecnología es mucho más dinámica, la duración del proyecto y de las tareas individuales suele ser reducida, su coste fundamental viene dado por el esfuerzo del personal y la realización de cambios es relativamente rápida y barata.

Esto ha facilitado que muchos de los proyectos se hagan con una planificación muy deficiente y aún así alcancen parcialmente sus objetivos. Por otro lado, estas características fueron las que originaron las metodologías ágiles como SCRUM que responden bastante bien a estos condicionantes.

Los enfoques que indico, basados en el tamaño de los equipos o en el tipo de proyecto, no son en absoluto únicas sino tendencias de la industria basadas en la facilidad de implantación y las prácticas actuales. Cualquier organización con suficiente conocimiento de metodología y una visión clara de sus fortalezas, debilidades y objetivos puede adoptar un enfoque diferente con éxito.

Como se complementan

En la sección anterior se discute factores que recomiendan que una organización se base en una metodología tradicional (p.e. RUP) o en una ágil (p.e. SCRUM).

Tanto si se escoge la aproximación tradicional o la ágil, la implementación en cada organización puede ser más efectiva si se basa en un modelo de referencia que ayude a la organización a que dicha implementación no descuide ningún aspecto importante y a que el proceso definido sea más eficaz y se mantenga efectivo a lo largo del tiempo.

Considerando la metodología ágil más popular, SCRUM, y el modelo de madurez más extendido, CMMI, veamos cómo pueden complementarse. Para ello, es necesario conocer tanto las actividades, roles y productos de SCRUM [3] como la estructura y áreas de proceso de CMMI [4].

Las principales mejoras mutuas que puede traer el uso conjunto de SCRUM y CMMI son:

Mejoras que CMMI aporta a SCRUM

1. CMMI ayuda a determinar de una manera más formal las mejoras que se pueden introducir en los procesos, p.e. mediante las métricas o las auditorías internas.

2. La planificación formal ayuda a capturar y dar seguimiento a las decisiones de gestión del proyecto, especialmente cuando los proyectos y la organización crecen y la presión aumenta.

3. Ayuda a involucrar de manera común al resto de la organización y a los actores externos, tanto en el seguimiento de los proyectos como en el aprendizaje y difusión de las mejoras.

4. Define más claramente los roles a nivel de equipo y fuera de los equipos, hecho que facilita la asunción clara de las responsabilidades.

5. Facilita que se determine la formación que no puede adquirirse autónomamente por los miembros de los equipos, especialmente importante en proyectos grandes.

6. Normaliza la realización de ciertas tareas, de manera que puede reaprovecharse mejor el conocimiento, se es más eficiente y se evitan problemas de calidad.

7. El desarrollo más formal de requisitos de cliente ayuda a estimar y planificar mejor el proyecto que un simple “roadmap” de producto.

Ventajas de implementar CMMI usando SCRUM

1. Los procesos que se definen se suelen realizar realmente, ya que se diseñan ligeros y de un seguimiento frecuente y compartido por el equipo.

2. El aprendizaje en los proyectos es continuo, mediante las reuniones SCRUM y las retrospectivas, y esto suele llevarse fácilmente de vuelta a los procesos.

3. La verificación y el seguimiento a los riesgos se realizan de una manera manual mediante las reuniones del equipo y las demostraciones al cliente.

4. Los proyectos pequeños no se ven penalizados por metodologías pesadas. Se pueden definir “perfiles de proyecto” que añadan nuevos procesos y actividades sólo para “proyectos grandes”.

5. Los miembros del equipo están en contacto frecuente con el jefe de proyecto, hecho que le aporta información muy valiosa para la planificación y seguimiento del proyecto.

6. La planificación de las tareas basadas en un roadmap ayuda a mantener el trabajo centrado en las prioridades de cada momento y evitar realizar trabajo innecesario.