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.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Combinar Scrum y CMMI (parte 1 de 2). 5 claves a tener en cuenta - Javier Garzás, sobre calidad software y otros temas relacionados
Muy buen artículo Javier, cómo te envidio por haber estado con Mark Paulk en el SEI, debe ser fantástico.
Aunque esté feo autoreferenciarse, para complementar este artículo me permito indicar un par de artículos míos en el Blog «SCRUM LAB» de la web TheProject.ws
Un abrazo!
– http://www.theproject.ws/es/project-management-scrum/entrada/combinando-cmmi-y-scrum-i
– http://www.theproject.ws/es/project-management-scrum/entrada/combinando-cmmi-y-scrum-2-0
Leidos! Gracias por las referencias.
Pingback: Batman trabajó en el SEI (Software Engineering Institute) - Javier Garzás, sobre calidad software y otros temas relacionados
Estoy de acuerdo que la implementación y la evaluación son cosas distintas, mas sin embargo no creo que sea un problema generar un evidencia de un tablero de historia, solo se ocupa alguna herramienta que genere dicho tablero, recomiendo jira para el manejo de proyectos, con el pluging de desarrollo ágil que muestra el tablero de historias de usuario, y con esto resolver todos eso “problemas” de generar evidencia para CMMI.
Después de tiempo regreso a este post con una duda: el white paper de DAD (Disciplined Agile Delivery) indica que el alcance de Scrum va principalmente a la etapa del desarrollo, lo cual va en contra del pensamiento popular (METODOLOGÍA de gestión de proyectos de forma ágil, cuando es solo un marco de trabajo). Siendo así, hasta dónde puede exigirse a Scrum llegar dentro del ciclo completo de un proyecto TI si, según lo indicado, no cubre la estimación ni análisis (irónico esto, ya que es parte del curso de certificación CSD)?
Hola Rodrigo,
desde mi punto de vista, existe una confusión entre lo que es en sí Scrum y lo que creemos (o necesitamos) que sea.
Scrum formalmente es un marco de trabajo MUY sencillo, aunque lo poco que dice es también MUY útil. DAD tiene razón respecto a que se enfoca a la fase de construcción y no tiene fases de «visión» ni de «transición». Si no se tiene una perspectiva más amplia y se intenta aplicar «solo Scrum» nos encontramos con la contradicción que falta una visión inicial (análisis inicial, construcción de un backlog y de un release plan, etc.). Obviamente esto no es lo que necesitamos en un proyecto real y lo hemos de acabar haciendo igualmente. Ambler tiene estadísticas que dicen que la duración media de una fase de «envisioning» es entre 2 y 4 semanas.
Es decir, que Scrum (como casi todos los otros cuerpos de conocimiento) se han de adaptar a nuestras necesidades, pero al revés que los demás (p.e. CMMI, RUP, ITIL…) se trata fundamentalmente de «añadir lo que necesitamos » y no de «simplificar».
Un ejemplo que uso en mis cursos para ilustrar esto es la
The Big Agile Practices Survey Results, donde se ven decenas de prácticas (muchas de ellas vienen de XP) que son necesarias y que Scrum no proporcionan. Ergo, Scrum es un marco de trabajo que sirve como base para nuestros procesos ágiles. Con una visión amplia, esto se revela como bastante natural.
Gracias por la respuesta Alex.
Dicho esto, sería «normal» caer en un water-scrum-fall entonces? Lo digo especialmente por el lado del análisis y diseño del proyecto (entiéndase el levantamiento de información, la estimación, los horrorosos (a mi parecer) casos de uso, creación de especificaciones técnicas, etc etc etc). O en todo caso, cuál sería la práctica más recomendable para esas fases de un proyecto?
Hola Rodrigo,
habría que ver que entiende cada uno por «scrumfall». Si se trata de repetir un proceso «tradicional» de estimación>análisis>diseño… y luego simplemente hacer sprints de programación, no tendría sentido. Las iteraciones deben contener todas las actividades del ciclo de vida precisamente para dar flexibilidad y hacer «barato» el cambio.
Otra cosa es dedicar un tiempo a crear la visión del proyecto para asegurar que todos los roles (cliente, programadores, etc.) entienden suficientemente el proyecto para iniciar su desarrollo con un riesgo asumible. Para dar un orden de magnitud a los equipos, les aconsejo que se parezca al tiempo que dedican actualmente a preparar una oferta, en función de la complejidad del proyecto. A esto se le puede llamar «sprint 0», «incepción», etc. y es a lo que me refería con que la media de los proyectos son de 2 a 4 semanas (eso sí, probablemente calculado en proyectos «americanos» grandes, que es de donde se tomó la encuesta).
Saludos,
Àlex – Cynertia Consulting