Esta semana pasada he asistido a un curso de Scrum (Manager) organizado por el COIICV.
No voy a entrar a explicar qué es Scrum… de eso ya hay millones de páginas que lo hacen, pero sí algunas conclusiones que he sacado.
Scrum vs CMMI
Scrum es una metodología que se opone al modelo o los procesos de CMMI y se entiende… mientras Scrum tiene su origen en el desarrollo de productos innovadores buscando velocidad y adaptabilidad, CMMI tiene su origen en proyectos militares. El primero se centra en las personas y en la flexibilidad, el segundo en los procesos.
La diferencia fundamental entre ambos es que Scrum se centra en obtener un producto de valor para el cliente, mientras que CMMI en obtener ese producto con la calidad, costes y fechas pre-establecidas.
He estado leyendo opiniones al respecto de cómo sacar partido de Scrum y CMMI (a la vez) en una organización, pero no he sacado nada en claro… supongo que dependerá de cada caso.
Como curiosidad, el curso realmente trataba de Scrum Manager… que se supone que es la síntesis entre metodologías ágiles (como Scrum) y modelos predictivos (como CMMI), pero la verdad es que no vi ninguna diferencia entre Scrum y Scrum Manager.
Scrum no es una bala de plata
Ni Scrum ni probablemente ninguna metodología. Habrá casos (proyectos u organizaciones) en los que Scrum encaja perfectamente y es posible aplicar esa filosofía y otros en los que no. Se habló que es útil en proyectos, con requisitos muy cambiantes o incluso donde no los hay y se van ocurriendo sobre la marcha (por ejemplo al desarrollar productos innovadores).
En mi opinión, creo que puede ser una ventaja competitiva en start-ups o empresas jóvenes que pueden “vender” o proponer al cliente esa metodología como elemento diferenciador de empresas más tradicionales.
Scrum y las personas
Una de las cosas que me ha llamado la atención es que cuando se habla en Scrum del equipo de desarrollo se hace referencia a: multi-disciplinar, auto-organizado y experto. Entiendo que hay perfiles de personas que encajan mucho más en Scrum que en CMMI. Mientras en el primero el conocimiento está en las personas en el segundo está en los procesos. Da la impresión que Scrum “forma” personas comprometidas y con una clara vocación de mejora y CMMI “forma” personas disciplinadas.
Artefactos
Respecto a los artefactos de Scrum hay varios que me parecen muy útiles y que se deberían utilizar sea cual fuere la metodología:
El gráfico burn-down: Esencial para responder a la típica pregunta de “¿Cuánto os falta para acabar?”. Además creo que es la mejor manera que he visto de visualizar el progreso de una iteración y fácil y rápida de mantener.
Las reuniones diarias del equipo de desarrollo: La forma más rápida y directa de conocer cada día el estado de las tareas.
Añadiría además, algún mecanismo de visualización, para las tareas de un Sprint, como por ejemplo Kanban.
Hay otros que no me parecen demasiado novedosos: Por ejemplo, los sprints en realidad se parecen a las iteraciones en un ciclo de vida iterativo-incremental o el product backlog que parece simplemente el alcance del proyecto…
Otros como que el cliente forme parte del equipo o se implique tanto en la metodología, es algo que ya se me escapa…
Scrumban
Dicho esto, hay una cosa que ni Scrum, ni CMMI y que ninguna metodología resuelven: Las estimaciones.
De hecho en Scrum, se puede utilizar la técnica de estimación póker, donde participa todo el equipo, pero al final se habla del “juicio de expertos”, es decir, tienes que tener a unas cuantas personas expertas en estimar (eso existe?). A todo esto, la estimación poker, vale la pena probarla :).
Vamos que al final, si la cagas estimando, tendrás tus sprints, pero igualmente no llegarás a tiempo, y sí, cuando acabes un sprint podrás “negociar” lo que entra en el siguiente con el cliente, pero igualmente como la estimación es algo tan volátil, los retrasos se producen igual y el desastre ocurrirá. A parte de esto, puede ocurrir que en los sprints se tienda a postergar las tareas hacia el final o que no se mantenga la tensión durante toda la duración de este y se produzcan retrasos.
Sobre esto, leí algo este verano y consiste en mezclar Scrum con Kanban (Scrumban). Con Kanban lo que se consigue es tener un flujo de trabajo continuado, ajustar la carga de trabajo y predecir con mayor claridad los tiempos de entrega de tareas, eso sí, desaparecen los sprints (o iteraciones).
En definitiva, recomendable el curso de Scrum y más para un novato en la gestión de proyectos como yo :). Para los interesados, en este vídeo dice todo lo que hay que saber sobre Scrum en 6 minutos y en esta presentación está todo el contenido del curso.
