Imagino que a estas alturas todos los hipotéticos que andáis interesados, como Juan, Ángel y yo mismo en las múltiples derivadas del paradigma "ágil" en la gestión estáis al tanto de la publicación, por parte del SEI, de un documento bastante majo que resume la posición oficial del Instituto con relación al tema "ágil". Por cierto que uno de los autores es mi muy estimado David Anderson [o al menos lo era, hasta que me he enterado de que se ha pasado al lado oscuro... ved los comentarios de Juan Palacio], uno de los primeros que se atrevió a hablar de TOC para el desarrollo de Software.
Para los que no estáis al tanto, sí, habéis leído bien... El Software Engineering Institute nos deja bien claro que la tan traída oposición entre métodos ágiles de gestión de proyectos de desarrollo de software y el empleo del CMMI es, como cualquier conflicto, un "constructo de la percepción". Mis socios de UNKASOFT os podrían contar algo de esto, porque han trabajado con Juan en la implantación de SCRUM al tiempo que preparan una certificación CMMI. Todo es posible, chicos.
Una de las cosas que más me ha gustado de este documento es el capítulo en el que aclara, para los que no estén al tanto, los orígenes de los métodos ágiles. Algún taliban amigo mío [no digo nombres] haría bien en echarle un vistazo. Los fundamentos de todo lo que conocemos hoy como "ágil", léase SCRUM, Crystal Methodologies, DSDM, etc, están en un enfoque que podemos denominar, genéricamente, como Iterative and Incremental Design and Development (IIDD), empleado ya hace 75 años por ingenieros del Departamento de Defensa (DoD) del Gobierno de los Estados Unidos. Incluso el propio Deming, al que todos conocemos como "padre de la Calidad" con mayúsculas, puede considerarse, con su PDCA, un precursor de la idea! Para alguno será duro aceptar que tanto la NASA como el Ejército del Aire de los Estados Unidos utilizaban prácticas como el time-boxing, los desarrollos iterativos y las entregas incrementales en los años 50!! [Echad un vistazo al intercambio de comentarios, en esta misma entrada, entre Juan Palacio y el que esto escribe].
Y no es sólo cuestión de años... algunos de los métodos ágiles más populares nacieron en el seno de multinacionales mastodónticas. XP [eXtreme Programming, eso de lo que os he hablado tanto, Daniel] nació en Chrysler en el año 1996 de la mano de Ron Jeffries [del que pocos se acuerdan] y Kent Beck. Feature Driven Development (FDD) comenzó, por otro lado, en uno de los mayores bancos asiáticos, el United Overseas Bank.
De hecho [y esto es una reflexión personal], no podría haber sido de otra manera. Las grandes compañías disponen de recursos, de todo tipo, suficientes para permitir este tipo de experimentos Y [es un "Y" mayúsculo] proporcionarles la publicidad que necesitan para alcanzar una difusión mundial. Escuchad esto: NINGUNA DE LAS MÁS CONOCIDAS METODOLOGÍAS DE GESTIÓN HA NACIDO NUNCA EN UNA PYME y no es porque no se realicen innovaciones en las pequeñas o medianas empresas, sino PORQUE LAS QUE SURGEN NO TIENEN POSIBILIDADES DE DARSE A CONOCER. Imaginaros el tesoro de innovaciones que debe existir, oculto a la vista de todos, en esas empresas de 6 a 100 trabajadores que constituyen el 90 y mucho por ciento del tejido empresarial del país.
En resumen, es éste un documento de lectura recomendada, que sirve de puente entre dos colectivos que tradicionalmente han vivido de espaldas el uno al otro, cuando no directamente enfrentados. ¿Metodologías Ágiles o CMMI? Y, ¿Por qué no ambos?
Interesantísimo el artículo y los comentarios. En referencia a la siguiente frase:
NINGUNA DE LAS MÁS CONOCIDAS METODOLOGÍAS DE GESTIÓN HA NACIDO NUNCA EN UNA PYME
Estoy totalmente de acuerdo, aunque creo que eso puede estar empezando a cambiar. Ahora es más facil compartir tu forma de trabajar. Muchas empresas hablan de ello en su página web o blog. Generalmente describen técnicas o mejores prácticas de forma aislada e inconexa, no articuladas en una metodología que les de cohesión. Esto es algo que intentaremos conseguir en nuestra iniciativa http://openprocedures.com. Estos materiales se comparten por diversos motivos como ánimo de compartir, comunicación interna, para obtener promoción, etc...
Un buen ejemplo de metodología (o más bien compendio de mejores prácticas) generada por una pyme sería el Getting real de 37signals http://gettingreal.37signals.com/.
Un ejemplo
Posted by: Lucas Rodríguez Cervera | 12/01/2008 at 08:09 AM
Exacto, Juan, eso es lo que pretendía decir, que IIDD como modelo genérico de gestión no es algo nuevo, si por nuevo entendemos del 2001 hasta nuestros días. Que enfoques iterativos, de entregas incrementales, han existido desde hace mucho. Y vuelvo al ejemplo del EVO de Gilbs, que data en sus inicios de los 60. Pero tienes toda la razón en lo de que pretender que existía algo llamado IIDD, en plan "marca registrada", raya con lo deshonesto. Modifico el texto del post para no inducir a confusiones.
Una vez más, muchas gracias por compartir todo eso que tienes en la cabeza :-)
Posted by: Mario | 11/29/2008 at 11:40 AM
Hola Mario,
No, no creo que Microsoft tenga nada que ver. Me refiero a cambiar radicalmente de criterio, de ser contra-CMMI a ser Pro-CMMI.
Que, posiblemente nos pasaría a todos, si nos contratara un Microsoft, un SAP, o... yo que sé, cojo jefes de su plataforma de gestión sobre CMMI.
Es sólo que como los humanos somos así, se le puede suponer más neutralidad a quien su sueldo no depende ni de un modelo ni de otro.
Gracias por el artículo, y en él puedes ver como el informe de SEI pilla por los pelos, que en el texto abrevien la expresión "evidence of iterative and incremental development's" como IID, para afirmar que hay un modelo llamado IID que data de 1930...
IID es un término que de forma genérica se emplea en muchos artículos para designar a cualquier modelo iterativo, sea ágil o no (http://www.agilecollab.com/iterative-and-incremental-is-not-equal-to-agile-key-aspects-of-agile)
Como dices, es mucho lo que se puede aplicar tomando lo mejor de ambos modelos, pero con el espíritu de consultor que tiene como objetivo mejorar al cliente, no con el de evaluador que tiene como objetivo vender su trabajo.
Aplicar lo mejor de CMMI sobre los principios de la agilidad supone cuestionar y modificar cosas de CMMI, algo que puede hacer un consultor, no un evaluador.
Un abrazo!
Posted by: Juan Palacio | 11/28/2008 at 06:46 PM
Joer, Juanillo, no sabía yo que andabas diciendo esas cosas... a ver, es cierto que si googleas el palabro entrecomillado apenas obtienes referencias, pero si lo haces con cariño encontrarás un par de referencias interesantes, la más apropiada de las cuales es un artículo de Craig Larman y Victor R. Basili, publicado en la revista de la IEEE Computer Society en 2003 en el que se cuenta esta misma historia con más detalle. Te mando el artículo por email [con un fuerte abrazo!].
Es posible que forme parte de una conspiración Microsoftiana para reinventar la historia [de hecho, la primera mención a IIDD en Wikipedia es de enero de 2003], pero sabes mejor que yo que para cuando se elaboró el Manifiesto Ágil los métodos ágiles llevaban al menos un par de décadas en el mercado. Evolutionary Project Management (EVO) estaba en uso desde los 60. Hasta en el PMBOK encuentras referencias a métodos ágiles [Eso del "rolling wave planning" seguro que te suena] que se remontan a los 50. Y acepto como válida la referencia a Deming [y a Shewheart] como inspiración de metodologías de gestión basadas en iteraciones y entregas progresivas.
Por lo demás, CMMI es un estándar organizativo, mientras que las metodologías ágiles son de aplicación en su práctica totalidad en el limitado ámbito de un proyecto, pero creo que no hay ninguna razón real, definitiva, que impida incardinar unos en otro. Sabes que el CMMI cuenta el QUÉ, no el CÓMO, que sí encontramos en las descripciones hechas por expertos de metodologías ágiles. Creo que sólo son incompatibles a causa del papanatismo, ignorancia y falta de imaginación talibán de los auditores / evaluadores [que NO "consultores", porfa] de CMMI.
Posted by: Mario López de Ávila Muñoz | 11/28/2008 at 05:48 PM
Hola Mario y compañía!
Sí, hace unos días comentaba precisamente este documento:
http://www.navegapolis.net/content/view/837/63/
Y como apunto, creo que la clave está en la síntesis, no en la suma de los dos, porque tienen principios y objetivos diferentes, y es como sumar café y tila.
CMMI tiene conceptos y principios valiosos, igual que todas las prácticas ágiles.
El concepto de "institucionalización", de modelo global, de objetivos genéricos... son principios de CMMI, y pueden enriquecer mucho si se combinan con los principios de agilidad.
CMMI los ha aplicado a principios de previsibilidad sobre planes cerrados y resultados basados en el protagonismo de los procesos.
Aplicándolos sobre los principios de la agilidad: planes en continua evolución y resultados basados en las personas, se da un paso en la evolución dialéctica del conocimiento y pueden generar mejores y nuevas formas de gestionar el desarrollo de software.
Pero tomar el legado de CMMI aplicando algunas de sus formas sobre los principios de la agilidad, no es aplicar CMMI y además agilidad.
Creo (quizá equivocado, pero convencido) que el fondo del documento es no perder parroquia en CMMI, y no quitarsela a la agilidad, pensando más en sus respectivos negocios que en el de las empresas de software.
Es significativo que el criterio de David Anderson (uno de los contribuidores de FDD hasta 2005) cambiara de crítico a entusiasta de CMMI, justo en 2005 cuando pasa a nómina de Microsoft para desarrollar la línea de MSF para CMMI.
En la hemeroteca de Navegapolis:
http://www.navegapolis.net/content/view/124/93/
Saludos!
P.D.
Echar un vistazo a ScrumManager... es la idea, y poco a poco y con la ayuda de todos los que queráis podemos darle forma.
http://www.scrummanager.net
Posted by: Juan Palacio | 11/27/2008 at 09:43 PM
Hola:
Como dice Mario, en Unkasoft llevamos un año intentado implantar un proceso CMMI-2 basado en SCRUM, y la verdad es que no es tema fácil.
Actualmente nos encontramos en fase de SCAMPI (a punto de tener la evaluación final), y el resultado es agridulce.
Por un lado, es cierto que las metodologías ágiles y CMMI puede ser como el agua y el aceite (o como la tila y el café, como bien dice Juan): puedes juntarlos, pero es difícil que se lleven bien.
Por otro lado está el tema de los consultores (que ha tocado Mario en sus comentarios): algunos todavía ni han oído hablar del término "ágil". Otros veteranos empiezan a ver la luz, y algunos visionarios llevan años luchando desde dentro para "agilizar" la interpretación del modelo. Estos últimos los cuentas con los dedos de una mano (al menos en España) y son los que realmente le dan valor al CMMI.
De cara a conseguir un nivel CMMI, dependes mucho del consultor que te evalúe: una misma implantación ágil puede ser válida para unos y rechazada por otros, lo cual se convierte en un "prefiero pasarme de clásico no me vayan a tirar en el examen", y al final la mayoría de las implantaciones acaban tirando más a lo pesado que a lo ágil.
Sin embargo, yo creo que es posible conseguir la cuadratura del círculo (aunque durante este año he pasado por muchas opiniones). Con una cultura de empresa adecuada, experiencia en ambos mundos y en evaluaciones CMMI y suerte, creo que es posible mantener un espíritu ágil y llegar a niveles CMMI (al menos el 2, que es el que conozco). Otro tema es que te toque el evaluador que no le mola lo ágil. Entonces sí que date por muerto.
Sin embargo, creo que en toda esta "guerra" deberíamos aprender los unos de los otros.
Los clásicos del enfoque revolucionario de la corriente ágil, y los agilistas de cierto grado de control y rigor que suele faltan en los ambientes ágiles (más de uno y de dos piensa que ágil es igual a "escribe código y no hagas otra cosa", cuando para implantar una metodología ágil hace falta tener mucho más aplomo y constancia de lo que parece a simple vista).
Y volviendo al famoso documento del SEI, es posible que estén intentando mandar un mensaje a todos sus evaluadores que están repartidos por medio mundo. A lo mejor las cosas están empezando a cambiar.
Ahora sólo falta la contrapartida: que las implantaciones ágiles estilo "pancho villa" aprendan algo de CMMI, que en el modelo hay pequeñas joyas escondidas.
Un saludo
JM
Posted by: JM | 11/27/2008 at 05:31 PM
Una y otra vez a lo largo de mi vida profesional me he encontrado con el conflicto que surge entre acciones encaminadas a garantizar Control y las acciones encaminadas a facilitar Velocidad o Agilidad. Estoy convencido de que se trata de uno de esos "conflictos universales" que muchos profesionales de TOC, TRIZ y SD estamos catalogando o inventariando, cada uno desde su particular punto de vista ["Mi hobby es coleccionar conflictos arquetípicos" - toma ya penosidad!!!!]
Como cualquier conflicto, es sólo una ilusión, está en nuestra cabeza, no en la Realidad. De ahí, debe ser perfectamente posible compaginar los Principios Ágiles con la "Ingeniería de Sistemas" del CMMI, siempre lo he creído, como he creído en sistemas de calidad ISO 9000 sin burocracia toda mi vida. Los hay, lo sé de buena tinta.
Uno de los problemas que tienen las metodologías ágiles, y esta es la razón por la que se escribe tanto sobre el asunto de un tiempo a esta parte, es su "escalabilidad". Es decir, funcionan bien cuando está implicado un grupo de pequeño tamaño, localizado físicamente en un mismo sitio, etc, pero su traslación a grupos de mayor tamaño, con múltiples localizaciones, etc, suele dar problemas. Recordad que uno de los principios clave de la "agilidad" es el uso preferente de la comunicación cara a cara frente a otros sistemas de comunicación. Difícilmente puede llevarse a cabo en proyectos que implican a decenas o centenares de personas repartidas por todo el mundo. CMMI, por otro lado, sí es escalable, funciona bien con proyectos de gran tamaño y te proporciona los principios de gestión, los procesos y las prácticas de soporte que necesitas. [Y sí, conozco los Scrums de Scrums de Kent, mirad mi lista de lecturas, porfa.]
En este sentido, siempre me ha gustado el enfoque de Cockburn con las metodologías Crystal - las prácticas recomendadas varían en función del tamaño y la criticidad del sistema en el que estás trabajando. A mayor tamaño y/o criticidad, mayor necesidad de control, desde Crystal Clear a Crystal Orange y más allá.
Para terminar, creo que no deberíamos confundir el estándar CMMI con la interpretación que del mismo hacen los auditores que evalúan la conformidad de cara a una certificación. Buena parte de lo que piden no es que no esté de acuerdo con el espíritu del modelo, es que ni siquiera está de acuerdo con la letra.
Posted by: Mario López de Ávila Muñoz | 11/27/2008 at 12:36 PM
Interesante post, Mario, me ha tocado la fibra, porque precisamente nosotros mateníamos una lucha interna sobre estos temas.
Al final, una pyme, es muy dificil que tenga proyectos suficientemente grandes como para que estas metodologías den todo lo que tienen que dar de si. De hecho, los proyectos habituales de una pyme, no pueden aplicar todos los paradigmas de cada metodología.
En nuestro caso, mezclamos, sobre todo, XP
Saludos!
Posted by: Sergio | 11/27/2008 at 11:21 AM
Nosotros estamos en ello (http://najaraba.com/agil/porpropiaexperiencia-Biko.pdf), pero la verdad que cada vez veo menos sentido a mantener CMMI si te decantas por la agilidad si no es por motivos estrictamente de certificaciones.
Al final acabas haciendo las cosas según las metodologías ágiles, pero de manera que te obligas a crear los artefactos que dejen constancia de que has hecho cada uno de los procesos que te obliga a tener CMMI... ¿es malo esto? Bueno, depende ;) si crees que después te van a ayudar en tu gestión, pues no, pero si en realidad solo son por cumplir la certificación y no sirven para nada...
Posted by: Joserra | 11/27/2008 at 10:19 AM