« Un paseo por Foros de Inversores | Main | La tarjeta de felicitación más 'kitsch' de estas navidades »

11/27/2008

Comments

Lucas Rodríguez Cervera

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 https://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 https://gettingreal.37signals.com/.

Un ejemplo

Mario

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 :-)

Juan Palacio

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 (https://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!


Mario López de Ávila Muñoz

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.

Juan Palacio

Hola Mario y compañía!

Sí, hace unos días comentaba precisamente este documento:
https://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:
https://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.
https://www.scrummanager.net

JM

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

Mario López de Ávila Muñoz

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.

Sergio

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!

Joserra

Nosotros estamos en ello (https://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...

The comments to this entry are closed.

Categories