Hace algunos días venia pensando en este post, pues sé que puede herir susceptibilidades y generar controversia, pero la reflexión y la sensatez me ha llevado ha escribirlo. Comenzaré entonces el post con las dos conclusiones con las que quiero terminar:
- CMMi es un modelo prescriptivo que incluye muchas componentes y elementos, su adopción es lenta y bastante costosa para los equipos y organizaciones, e incluso adoptándolo no se garantiza que "todo vaya a ir bien"
- SCRUM es un marco poco prescriptivo que tiene excelentes prácticas de gerencia de proyectos, gestión de requisitos y habilita de una forma rápida la mejora continua, su adopción es simple y poco costosa, adicionalmente su correcta implementación hará que pronto "todo vaya bien".
Ya que saben mi conclusiones, espero estén interesados en conocer mis argumentos. Voy a manejarlos en forma de cuadro comparativo:
Característica
|
CMMi (Capability
Maturity Model Integration)
|
SCRUM
|
Tiempo de adopción
|
·
Lo normal es que la adopción de
cada nivel toma aproximadamente entre 12 a 18 meses [1]
·
La adopción completa de CMMi
nivel 5 toma entre 3 a 5 años empleando técnicas de Six Sigma [1]
|
·
Aplicar Scrum y toma poco tiempo, aproximadamente 3 a 4 sprints
de 2 semanas para estar ejecutando bien el framework. Se sugiere
acompañamiento (coach) o mucha lectura para hacerlo bien [4]
|
Costo
|
Mínimo 100.000 dólares por cada nivel, compartido entre consultorías, adopción y adaptación del modelo dentro de la organización[12]
|
Sin información.
Nota: Se puede adoptar el framework y las prácticas
técnicas a muy bajo costo para los equipos.
|
Capacidad
|
La "capacidad certificada" de hacer software solo se
demostrará después del primer nivel (nivel 2) certificado (he concluido, que seguirás fallando en proyectos)
|
La capacidad es dada por el software funcionando cumpliendo
la Definición de Hecho/Realizado (Definition of Done - DoD), disponible desde
el primer sprint.
Aunque es cierto, también se puede fallar en Agile
[7][8][9], pero un equipo con coraje y el poder de las retrospectivas
pueden cambiar favorable y rápidamente esta situación.
|
Complejidad del modelo
|
Entender CMMi requiere de entrenamiento y es un
documento de 482 páginas (esta es la hora que nó me lo termino de leer)[2]
|
Para entender Scrum requiere de máximo una tarde leer
la guía oficial que tiene 16 páginas [3]. ( y bueno, mucha reflexión y
lecturas complementarias [4] para comprender este marco que te da límites y
libertad.)
|
Universalidad del entendimiento del modelo
|
Muchas cosas dependen de la interpretación del
consultor y de quien haga la evaluación (frase que se escucha con frecuencia
mucho en el mundo CMMi).
|
He observado que entender el marco a pesar de ser simple, requiere de
acompañamiento y mucha lectura.
El framework te proporciona unos límites claros y mucha
libertad para moverte dentro de ellos.
La recomendación en este caso es:
· cumpla las reglas,
·
haga todas las reuniones
·
no fusione roles
·
no alargue el sprint
· Lea a los líderes
|
Áreas de interés
|
CMMi se involucra con muchas áreas dentro de la organización, los
proyectos y la ingeniería [5][2]:
·
Administración de procesos
o
Entrenamiento
o
Innovación
·
Ingeniería
o
Requisitos
o
Verificación
o
Validación
o
Solución técnica
·
Gestión de proyectos
o
Gestión
o
Administración de proveedores
·
Soporte
o
Medición
o
Auditorías al proceso y producto
o
Gestión de la configuración
o
Análisis de causas
o
Análisis de decisiones
|
Scrum con respecto a
CMMi solo se encuentra fuertemente asociado a la gestión de proyectos
y a la gestión de requerimientos [6]
Respecto a la Ingeniería esta no se encuentra definida
en Scrum, la responsabilidad es delegada al equipo auto-organizado que sabe y
conoce como lograr el producto:"el
equipo decide como pasar de una lista de requerimientos a un producto
potencialmente entregable durante el sprint".
Por lo tanto, los equipos SCRUM se apoyan fuertemente en
las prácticas técnicas (para cumplir el manifiesto ágil el cual hace el
llamado a la excelencia técnica) y así lograr la DoD (Definition of Done).
Dentro de las prácticas técnicas se encuentran [10]:
Es de observar que estas prácticas técnicas dan soporte
a las diferentes áreas de CMMi, dejando por fuera a:
|
Ciclos de mejora
|
Aunque se realizan auditorías tanto a los proyectos como a la organización y se recolectan y aplican las lecciones
aprendidas, los ciclos de mejora toman tiempo y dependiendo de la
organización se realizarán entre 2 a 4 en el año.
Y la aplicación de las mejoras depende de las políticas de la organización
|
Se realizan mejoras cada sprint (el cual finaliza entre
2 a 4 semanas), habilitando el PHVA en ciclos cortos y potencializando inmediatamente la mejora continua de los equipos de desarrollo.
Scrum no está orientado a la organización, sino a
los equipos y estos son los directamente beneficiados con el framework
.
Es natural el compromiso del equipo con la mejora
(kaizen)
|
Bajo lo expuesto anteriormente, concluyo:
Es más fácil lograr CAPACIDAD* con Scrum que con CMMi, en términos de costo y tiempo.
-
-
-
"Con Scrum el proceso de alcanzar capacidad es más rápido, barato, natural y convergente que con CMMi."[14]
-
* Hablo de capacidad pues la "C" de CMMi es de Capacidad que es el argumento de venta del modelo y considerando dicha capacidad como la facultad de hacer software de alta calidad funcional y técnica que cumpla con las expectativas de los clientes y usuarios, por parte de la organización y sus equipos de trabajo.
Ahora resulta que todos son ágiles
Es frecuente encontrar artículos del SEI y al PMI y otros de corrientes de la ingeniería de software clásica, apegados a modelos rígidos diciendo:
-
-
"si, si, y además nosotros también somos ágiles. Miren pueden pagarnos estos cientos o miles de dólares para que yo lo certifique o certifiquemos su empresa en agilidad bajo nuestro modelo"
Observo que se les esta yendo el negocio de las certificaciones y las consultorías de las manos, pues cada vez las empresas y los equipos de software están encontrando más pronto la EXCELENCIA y CAPACIDAD de hacer software con altísima CALIDAD en el agilismo, que bajo los esquemas tradicionales y rígidos como son CMMi, PMBoK, RUP, entre otros.
En la misma línea del párrafo anterior, es una moda el uso la palabra ÁGIL / AGILE (o en su defecto SCRUM), y muchos quieren ponerla de prefijo o de apellido a su negocio, framework, título, etc., cosa buena pues apunta a que los agilistas tienen la razón y cosa mala pues habrán muchos diciendo que son ágiles sin serlo. Más temprano que tarde el mercado y los hechos demostrarán quienes son o no del mundo agile, y esto será dictado por el cumplimiento del Manifiesto Ágil y sus Principios [11], y el éxito en la forma de ejecutar lo que se comprometen en un entorno complejo.
¿Además qué grande (léase: google, facebook, yahoo, microsfot, etc) del software tiene CMMi nivel 5?
Volviendo al inicio
Termino entonces este post con las conclusiones prometidas:
- CMMi es un modelo prescriptivo que incluye muchas componentes y elementos, su adopción es lenta y bastante costosa para los equipos y organizaciones, e incluso adoptándolo no se garantiza que "todo vaya a ir bien"
- SCRUM es un marco poco prescriptivo que tiene excelentes prácticas de gerencia de proyectos, gestión de requisitos y habilita de una forma rápida la mejora continua, su adopción es simple y poco costosa, adicionalmente su correcta implementación hará que pronto "todo vaya bien".
Queda abierta la discusión
Saludos y un abrazo ágil a todos
Referencias:
[1] http://www.sei.cmu.edu/library/assets/bridging-gap.pdf
[2] CMMI for Development, Version 1.3. http://www.sei.cmu.edu/reports/10tr033.pdf
[3] The Scrum Guide -https://www.scrum.org/Scrum-Guides
[4] Por dónde comenzar a leer y a estudiar de Scrum http://lecciones-aprendidas.blogspot.com/2013/05/por-donde-comenzar-leer-de-scrum.html
[5] Framework para el Desarrollo De Software En Entornos Académicos - https://docs.google.com/file/d/0B5JZ11Z2PoWWWDlheXY2SnhUc2M/edit?pli=1
[6] Can Scrum help to improve the project management process? A study of the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3. http://www.javiergarzas.com/2013/03/cmmi-scrum.html
[7] Ways to Fail with Scrum!- Jeff Sutherland http://www.gbcacm.org/sites/www.gbcacm.org/files/slides/3B%20-%207%20Ways%20to%20Fail%20with%20Scrum!.pdf
[8] How to Make Scrum Fail - http://agile.dzone.com/articles/how-make-scrum-fail
[9] Scrum Fails? -Ken Schwaber http://kenschwaber.wordpress.com/2011/04/07/scrum-fails/
[10] What are the Most Important and Adoption-Ready Agile Practices? http://www.infoq.com/research/agile-practises?utm_source=infoqresearch&utm_campaign=rr-content#.UUmgOcTIFVw.twitter
[11] Manifiesto Ágil -http://agilemanifesto.org/
[2] CMMI for Development, Version 1.3. http://www.sei.cmu.edu/reports/10tr033.pdf
[3] The Scrum Guide -https://www.scrum.org/Scrum-Guides
[4] Por dónde comenzar a leer y a estudiar de Scrum http://lecciones-aprendidas.blogspot.com/2013/05/por-donde-comenzar-leer-de-scrum.html
[5] Framework para el Desarrollo De Software En Entornos Académicos - https://docs.google.com/file/d/0B5JZ11Z2PoWWWDlheXY2SnhUc2M/edit?pli=1
[6] Can Scrum help to improve the project management process? A study of the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3. http://www.javiergarzas.com/2013/03/cmmi-scrum.html
[7] Ways to Fail with Scrum!- Jeff Sutherland http://www.gbcacm.org/sites/www.gbcacm.org/files/slides/3B%20-%207%20Ways%20to%20Fail%20with%20Scrum!.pdf
[8] How to Make Scrum Fail - http://agile.dzone.com/articles/how-make-scrum-fail
[9] Scrum Fails? -Ken Schwaber http://kenschwaber.wordpress.com/2011/04/07/scrum-fails/
[10] What are the Most Important and Adoption-Ready Agile Practices? http://www.infoq.com/research/agile-practises?utm_source=infoqresearch&utm_campaign=rr-content#.UUmgOcTIFVw.twitter
[11] Manifiesto Ágil -http://agilemanifesto.org/
[12]Profiles of Level 5 CMMI Organizations - http://www.compaid.com/caiinternet/ezine/reifer-profiles.pdf
[13]Jeff Sutherland. Scrum and CMMI Level 5: The Magic Potion for Code Warriors "http://systematic.com/media/282221/Scrum_and_CMMI_Level_5___The_Magic_Potion_for_Code_Warriors.pdf
[14] Texto de mi autoría adicionado el 15 de septiembre de 2013
[13]Jeff Sutherland. Scrum and CMMI Level 5: The Magic Potion for Code Warriors "http://systematic.com/media/282221/Scrum_and_CMMI_Level_5___The_Magic_Potion_for_Code_Warriors.pdf
[14] Texto de mi autoría adicionado el 15 de septiembre de 2013
