Posteado por: navarros | 14 noviembre 2008

CMMI® or Agile: Why Not Embrace Both!

cmmi/agile embrace bothEsta clara la pujanza de las metodologías Ágiles dentro del panorama de gestión de proyectos de las empresas en nuestro país. Pero este fenómeno lleva ocurriendo en EEUU con una mayor duración lo que esta apartando las metodologías tradicionales establecidas como CMMI, incluso arrinconándola a las empresas con más solera teniendo una baja penetración en las nuevas.

Tal y como somos los humanos nos gusta posicionarnos en extremos y ser de un bando, partido, equipo de futbol y denostar al supuestamente contrario, esto es lo que ha ocurrido con las metodologías ágiles y las predictivas. Los defensores de unos y otros han criticado el funcionamiento de las otras, en muchos casos sin experiencia en el otro bando, no permitiendo casi ni el dialogo inteligente. Es tan extremo que en la última formación que impartí, los asistentes se mostraron muy sorprendidos al enunciar que ambos modelos tenían ventajas y que era no solo imposible sino contraproducente seleccionar una sobre la otra de forma generalista y dogmática, se debe seleccionar las prácticas y modelos que ajusten a la empresa, equipo, situación y objetivos para tener éxito. Resulta curioso que sea más difícil de vender esta postura que una clara adhesión a un lago por motivos de “creencias”. Otro día os contaré un poco más de las formaciones que hacemos.

El caso es que el SEI (Software Engineering Institute) de la Carnegie Mellon University está reaccionando ante este avance. Para ello defendiendo una postura similar a la que indicaba anteriormente ha publicado un paper llamado“CMMI® or Agile: Why Not Embrace Both!”. Esta escrito por personas que trabajan en diferentes organizaciones como expertos en CMMI y metodologías ágiles.

El objeto del documento es detallar la posición oficial del SEI de acercamiento y coexistencia de las metodologías Ágiles y CMMI. Para ello hace un repaso por los paradigmas del CMMI y de las ágiles, luego otorga a cada una un lugar en el proceso de desarrollo y enumera los beneficios de combinarlo (eso es sintetizar eh! :) ). El documento es algo extenso para el contenido pero hay algunos párrafos que merecen la pena destacar.

CMMI IS A MODEL, NOT A PROCESS STANDARD

This view of CMMI as a standard is a complete misuse of a model. To reiterate from the model itself, “CMMI contains neither processes nor procedures;” the lists of typical work products, for example, are examples of process outputs. They are not exhaustive lists of required process outputs nor are they mutually exclusive of other possible process outputs. The practices are not steps in an organization’s set of standard processes, and they are not activities that necessarily occur neatly within a specific business process.

Muy claro…

Goals are the only required components of CMMI. The practices within the goals are expected,
but not required.

Totalmente de acuerdo y sin embargo

However, for people and organizations that do not have the skills or experience to understand, interpret, and implement the practices and goals to their specific contexts, the informative material takes on the mantle of requirements. This situation is also true for appraisal teams and lead appraisers.
Thus, the over-emphasis on specific model examples, typical work products, and subpractices often results in prescriptive processes with little gain in quality or organizational performance. This concept-based disconnect is compounded by an approach toward CMMI use that can be aptly described as pathological box-checking and an over-zealous contracting or “small-picture” auditing attitude that seems willing to sacrifice what is good for people, projects, customers, products, and the long-term health of each in favor of supporting the generation of appraisal evidence.

Y este es el problema, si tienes a personal que certificas y apruebas oficialmente para realizar las labores de guiado y valoración no puedes luego enunciar que “hay gente que…”. Aquí, los que hemos vivido estos procesos estaréis de acuerdo conmigo, es donde está el problema, no todos, al contrario diría, muy pocos saben hacer esto con el verdadero objetivo de mejorar los procesos y el modo de trabajo de las empresas para dotarlas de mayor valor.

The Agile Manifesto has been frequently cited by Agile proponents as justification for not having processes, for not documenting their work, and for not having plans.

Es muy tentador, por fin dejar de documentar y planificar. Es cierto ocurre, enseguida se entiende por donde se desea el Agile Manifesto.

CMMI and Agile are compatible. At the project level, CMMI focuses at a high level of abstraction on what projects do, not on what development methodology is used, while Agile methods focus on how projects develop products. Therefore, CMMI and Agile methods can co-exist.

Agile methods provide software development how-to’s, purposely absent from CMMI, which work well on small co-located projects. Meanwhile, CMMI provides the systems engineering practices often required on large, high-risk projects. CMMI also provides the process management and support practices (and principles) that help deploy and continuously improve the deployment of Agile methods in an organization regardless of organization or project size.

El objetivo del documento y la colocación de cada metodología en su terreno.

The first real step in the process of reconciliation has been taken and manifests itself in this report.
We, as this report’s authors and contributors, represent those professionals in the CMMI and Agile communities who are passionate about the subject of Agile methods and CMMI and are concerned with the perceptions that the software industry holds on both sides of the issue. By chartering this group to collaborate and write this report, a demonstrable, concrete step into the exploration and understanding of the issue has been taken, and this Call To Action outlines steps that can be taken by experts in both communities that can begin to repair the perceptions and reconcile our two communities. The next step is up to you. All practitioners (whether working with an Agile approach or CMMI) have a responsibility to learn about other technologies (and not just CMMI or Agile) and make the best use they can of the ideas they encounter for the betterment of their project, their organization, and the larger software engineering community

Y el tratado de paz y llamamiento a la concordia.

Muy recomendable también la última parte del documento con la comparativa de los paradigmas CMMI/Agile.

About these ads

Responses

  1. Me gustan los desarrollos “Agile”s. Sobre todo porque entre otras cosas es poner nombre a lo que muchos hacemos, y ya se sabe que si hay un nombre para algo, automáticamente está ya justificado.

    Independientemente de ciclos de vida en espiral, en cascada, etc, el principal problema en las metodologías tradicionales es que una vez firmado el documento de especificaciones o el de análisis o el de diseño técnico, cualquier cambio (o bug por parte del cliente) supone un cristo, ampliaciones al proyecto y malos rollos. Si no le cobramos menos al cliente por nuestros bugs… ¿por qué cobrarle más por los suyos?

    Aparte de que los % de avance de los proyectos son completamente irreales (requisitos ok, análisis ok, arquitectura ok, diseño ok, …) y nos autoengañamos hasta que no llegamos al último punto.

    Para mi ágil significa que (ordenadamente) los requerimientos están siempre abiertos. Que somos flexibles. Que el cliente ve resultados pronto. Que las cosas pueden cambiarse. Que Gmail puede estar en beta permanente.

    Pero, hay dos problemones que no sé cómo cuadran en proyectos con presupuesto cerrado: obviamente hay que acotarlo, habrá que valorar cambios al alcance, etc, y volvemos a lo de siempre.

    Y el segundo problema es el personal con el que cuentas: la proporción de juniors en tu equipo (sean ingenieros, o informáticos, o personas) no puede ser la de un equipo tradicional. Tienes que tener un equipo senior.

    Tengo la suerte de contar en mi actual proyecto con ambos factores: la flexibilidad de un presupuesto anual cerrado pero con alcance flexible, y un equipo pequeño pero muy cualificado. Los lunes tomamos decisiones colegiadas. y se ejecutan. O se cambian cosas ya hechas.

    ¿Pero a qué porcentaje de proyectos le pueden cuadrar las metodologías ágiles?

    P.D: Estoy empezando a leer Ágil, y disculpa por la extensión del comentario, te he robado espacio en tu muro…

  2. Bienvenido serverperformance. Tienes mucha razón, el nombre importa, cuando imparto cursos me gusta realizar la comprobación de esto. Cuento la teoría, se asiente por el respetable con algo de excepticismo y luego vemos como en la mayoría de los casos ya se realiza pero con un nombre más cercano como “la reunión junto a la maquina de café”, “¿que?, ¿que ya hacemos scrums diarias?, que buenos somos”, si pero sobretodo sois lógicos.

    En cuanto al encaje de las metodologías ágiles en proyectos de un tipo u otro yo opino que lo primero es que encajen en la empresa. Me explico, la metodología ágil se basa en que confías en tener profesionales en tu equipo y que sus aportaciones en la gestión del proyecto tienen, al menos, la intención de que llegue a puerto con garantías. Con esta premisa, sencilla de enunciar pero no tan sencilla de aplicar, más por resistencia del personal a cargo que de la complicación técnica, todo lo demás se hace flexible. Insisto, desde esta premisa el cliente manda. “quiero un presupuesto cerrado” explica las ventajas de un modelo flexible sino quiere “aventuras” advierte que le ofrecerás el precio más caro del proyecto para prevenir las variaciones de costes y te reservas el derecho de solicitar más presupuesto por cambios en el alcance. Esto no impide las técnicas de gestión ágil, reuniones, entregas parciales, aceptación de cambios, pruebas exhaustivas, técnicas LEAN.
    En cuanto al personal viene a colación de la misma premisa, para confiar en un profesional, este debe serlo y por tanto requerirá un salario acorde. Desde luego tiene que haber cabida para la formación e incorporación pero hazlo a través de técnicas de acompañamiento estilo XP, es un coste incial recompensado n veces en el futuro.

    P.D. Este es un muro con un espacio bien grande, eres bienvenido e invitado “a pintar”,lo qe quieras, un saludo

  3. “lo que esta apartando las metodologías tradicionales establecidas como CMMI,”

    CMMi es un modelo, no una metodologia…

  4. Tienes razon keagui, encantado de ser corregido.
    Metodología y modelo se suelen utilizar de forma indistinta aunque no se debería. Pero peor es que no solo se utiliza indistintamente en el modo de expresarse sino en el de aplicarse. De allí muchos de los problemas que tiene su implantación.
    Insisto, encantado de ser corregido, bienvenido!


Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Categorías

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

%d personas les gusta esto: