Combinar Scrum y CMMI (parte 2 de 2). Donde Scrum ayuda a implantar CMMI
La primera parte de este post terminaba comentando como también los padres de CMMI y Scrum hablaban de que combinar Scrum y CMMI es posible, y recomendable. Aparte de los trabajos de Jeff Sutherland (uno de los padres de CMMI), y de otros conocidos del mundo ágil, también Mark Paulk, quien escribiera la versión 1 de CMM (previa a CMMI), tiene trabajos sobre Scrum. Como tuve la suerte de trabajar con Mark varios meses en la Carnegie Mellon, en este post os dejo un muy breve resumen de aquella colaboración, concretamente sobre aquello de combinar Scrum y CMMI.
Scrum es principalmente una metodología para la gestión de proyectos de manera ágil. Por ello, a la hora de estudiar cómo combinar Scrum y CMMI, hay que pensar que el apoyo que Scrum puede prestar a la implantación de CMMI lo vamos a encontrar en aquellas áreas de proceso más relacionadas con la gestión de proyectos. Concretamente, en CMMI (hablo por defecto siempre de CMMI-Dev) estas áreas de proceso son: Requirements Management (REQM), Project Planning (PP), Project Monitoring and Control (PMC), Integrated Project Management (IPM), Quantitative Project Management (QPM), Risk Management (RSKM) y Supplier Agreement Management (SAM).
Una tabla resumen sobre combinar Scrum y CMMI
Para los que conozcáis CMMI, recordareis que cada área de proceso se subdivide, entre otros, principalmente en los llamados SG (Specific Goal). Y en este sentido, la siguiente tabla trata sobre cómo combinar Scrum y CMMI, y muestra en qué grado Scrum ayuda a la implantación de los SG de cada una de las áreas de proceso más relacionadas con la gestión de proyectos, las que mencionamos antes.
Podéis ver en la tabla un “++” cuando el apoyo que presta Scrum es alto, “+” cuando es parcial o un “o” cuando no hay relación, es decir, Scrum no contempla nada relacionado con el SG. Que la relación de Scrum con un SG sea un “+” o un “o” no quiere decir que Scrum vaya “en contra de lo que dice CMMI”, sólo quiere decir que Scrum no trata con el objetivo que tiene el SG.
Como podéis imaginar, en lo que refiere a la relación entre las prácticas de Scrum y los SG, la anterior tabla es sólo un resumen. Por cada SG hay mucho más detalle de cómo y dónde está la relación. Por ejemplo, en la “SG 1 Manage Requirements”, quizás la relación más obvia, va a venir de todo lo referente a “historias de usuario”, etc., etc., etc. Y así con el resto de SGs. Pero pienso que entrar en más detalle excede el objetivo de un post, y podría hacernos perder el mensaje global referente a cómo combinar Scrum y cmm.
Como conclusión, también recordar que, como hablábamos en la primera parte de este post, cuando hablamos de combinar Scrum y CMMI, una cosa es implantar CMMI, y otra evaluarse. Hay prácticas de Scrum que, normalmente, no dejan evidencias persistentes (es de cir, documentos, registros, etc.). Un tablero de historias de usuario (te recomiendo aquí este post) en post-it es difícil de enseñar mucho tiempo después de su creación a un evaluador (auditor). Este es para mí el principal problema de la unión CMMI – Scrum, el mostrar evidencias en las evaluaciones (auditorías).
—
Enlace a la primera parte de este post sobre combinar Scrum y CMMI.
