El Blog de Pablo Fernando Sanchez

Esta es mi bitácora personal, en la cual trato, sin limitarme a ello, sobre ingeniería de software, ingeniería de sistemas, gestión estratégica, modelado de procesos, metodología, aseguramiento de la calidad, gestión del conocimiento y todos esos asuntos que hacen, desde la gerencia y la técnica, a las empresas que asesoro.

Herramientas

KPI Dashboard

Blogs Amigos

En Otros Blogs

Estas son algunas entradas en otros blogs inscriptos en Bitacoras.com en las cuales me citan:

Leo en la Wikipedia que un oxímoron es «una figura literaria que armoniza dos conceptos opuestos en una sola expresión, formando así un tercer concepto que dependerá de la interpretación del lector. Dado que el sentido literal de un oxímoron —por ejemplo, un instante eterno— es absurdo, se fuerza al lector a buscar un sentido metafórico —en este caso, un instante que, por la intensidad de lo vivido durante el mismo, hace perder el sentido del tiempo». Pues bien, soy de la opinión que, aunque parezca un oxímoron en función de lo que nos tiene acostumbrado el mercado, no tenemos que oponer a los métodos ágiles y al Capability Maturity Model Integration (CMMI) —en su rol de representante de los métodos tradicionales— en una expresión como la del título. Ese aparente oxímoron diría: «¡métodos ágiles y CMMI!». Y digo aparente, porque en realidad no lo es.

Explico. Creo que...

  • la industria está plagada de tecnócratas desorientados, quienes en lugar de hacer ingeniería están más pendientes de apoyar hasta el fin ciertos inexplicables fanatismos personales, lo cual nubla la visión abierta que DEBE tener un ingeniero, y...
  • CMMI puede convivir perfectamente con métodos ágiles —al contrario de cómo se esfuerzan en demostrar, no son para nada opuestos.
Está bien, tal vez fui duro con la afirmación del primero de los puntos, pero la verdad es que ocurre... Veamos... Yo me casé una sola vez, con mi esposa y para toda la vida. Este es el único marco en el que acepto esto de casarse. Hay gente que, literalmente, se «casa» con una tecnología —sin siquiera cobrar por ello— exhibiendo una intolerancia general hacia las ideas de los otros. En todas sus formas, esta actitud de adversarios además de no ser razonable, es contraproducente para la tarea que se tiene entre manos: desarrollar software de la más alta calidad en el menor tiempo posible.

Que software libre, que software propietario, que métodos ágiles, que métodos tradicionales, que enfoque estructurado, que enfoque orientado a objetos, que tecnología de objetos, que Microsoft Visual Basic, que Java, etcétera. Vergonzoso... Las tecnologías están para que nosotros, los seres humanos que incurrimos en la ingeniería —seamos o no ingenieros—, las aprovechemos como mejor nos convenga... Nada más... Cada una de ellas puede convivir perfectamente con otra, si el proyecto lo justifica. No podemos ser fanáticos inquisidores en este marco. El fanatismo está para otras áreas en las cuales la lógica es distinta: fútbol, política, religión, etcétera. Pero no nos podemos permitir fanatismos en términos profesionales e ingenieriles.

Ahora bien, dejo de «hacer amigos» —aunque conozco muchos profesionales que me inspiran el más profundo de los respetos y que concuerdan con lo expresado— para focalizarme en la segunda de las afirmaciones, eso de que «CMMI puede convivir perfectamente con métodos ágiles».

En primer lugar, el Software Engineering Institute (SEI) de la Carnegie Mellon University, que es la entidad titular de los derechos de evaluación del modelo CMMI, no dice que tenemos que hacer todo lo que plantea dicho modelo. A pesar que CMMI puede aplicarse tanto en organizaciones grandes como en pequeñas, estas últimas suelen carecer, en gran medida, de los recursos y el conocimiento requerido para iniciar un proceso de mejora basado en CMMI.

Como CMMI es un modelo, por definición no es perfecto. Las prácticas del modelo necesitan ser interpretadas a la luz del trabajo a realizar y ser escaladas para proveer valor, no sobrecarga. Tenemos que ser lo suficientemente coherentes en nuestras labores de ingenieros para detectar aquellos puntos que nuestra organización no necesita o que en función de sus procesos no le conviene cubrir. Si hacemos esto y lo podemos justificar —cosa que no es negociable—, la evaluación arrojaría que es válido. Por lo tanto, podemos y debemos ajustar el modelo a nuestras necesidades particulares.

Por otro lado, al tiempo que CMMI da ejemplos de procesos y prácticas a nivel organizacional, no provee detalles específicos para los desarrolladores de software y los equipos que integran. Allí es donde entran en juego modelos de un nivel más bajo que ayuden a implementar las prácticas identificadas en CMMI. Ejemplos de ellos serían el Personal Software Process (PSP) y el Team Software Process (TSP), los cuales fueron desarrollados también dentro del SEI allá por 1998 por Watts Humphrey para complementar el «qué hacer» del CMMICMM en ese entonces— y acelerar la adopción proveyendo el «cómo hacerlo». Eso mismo se puede lograr mediante muchos y distintos modelos existentes, o nuevos o híbridos por modelar para el caso.

Además, también conviene complementar o extender CMMI con otras iniciativas de mejor práctica como las prácticas de línea de producto, la gestión del valor ganado —o «Earned Value Management» (EVM)—, sistemas basados en COTS, adquisición, mercadeo, Six Sigma, ISO 9001 y un amplio etcétera.

Más allá de su reputación, CMMI, PSP y TSP cubren el optimismo infundado, la irresolución de cronogramas y las metas no cumplidas en una forma ágil. Esta conclusión surge si comparamos los enunciados del «Manifiesto Ágil» con TSP, por ejemplo. Las relaciones son claras, pero por supuesto: tenemos que saber un poco de CMMI, PSP, TSP y agilidad para notarlo. En próximos artículos detallaré este asunto. Por ahora, lo dejo para que quien lo desee investigue un poco.

6 comentarios

  1. Deoxy  

    En efecto CMMI como modelo puede implementarse y complementarse con los métodos ágiles.

    "Tenemos que ser lo suficientemente coherentes en nuestras labores de ingenieros para detectar aquellos puntos que nuestra organización no necesita o que en función de sus procesos no le conviene cubrir"

    Como modelo, CMMI, debe ser enfrentado con prácticas de Ingeniería de Software y como ingenieros nuestra labor principal (o una de las principales) es la optimización por lo que si nuestra empresa "no necesita cubrir algunos puntos" se debe justificar muy bien, tal como tu lo dices.

    Saludos cordiales.

  2. Pablo Fernando Sanchez  

    J. Rodrigo: Muchas gracias por tu comentario.

  3. Silvia Leonor Vargas  

    Al conocer el modelo de CMMI (Nivel 2) siempre me sentí perdida encuanto a cómo este afectaba las actividades propias del Desarrollo de Software pues veía que este enfocaba sus prácticas a áreas de procesos globales. Con este artículo entendí que para esto el CMMI se complementa con metodologías como PSP, que si es lo que yo esperaba. Incluso para mi opinión una empresa de software debería dominar sus prácticas de Ingeniería de Software (ya sea basados en PSP u otra conocida) antes de asumir el reto de implementar CMMI.

    Gracias, como siempre un tema muy interesante.

  4. Anónimo  

    Dave Thomas, en este paper "The Unnecessary Tension between Process and Programmer" que se puede leer aca http://www.jot.fm/issues/issue_2006_01/column1
    hace una comparación de los modelos de procesos agiles y los modelos CMMI, ISO9001 etc.

    Tambien describe la diferencia de modelos Top-Down vs Botton-Up

    Slds

  5. Pablo Fernando Sanchez  

    Silvia: Gracias por el comentario. En efecto, suele perderse de vista, ante la "inminente necesidad" de muchas empresas de evaluarse en el modelo —como diría un amigo, "obtener la cocarda"—, que el modelo sólo debe ejercer como un nexo coordinante entre las cuestiones metodológicas mediante las cuales las organizaciones encaran su actividad diaria de desarrollo de software. Como tal, es una excelente guía, no lo dudo. Pero es importante tener en cuenta que "el cómo" depende de cada organización. Si se está flojo en estos aspectos, al proyectar la implementación de CMMI deberían tomarse en cuenta estas falencias para presupuestar correctamente —tiempo, inversión, recursos, etcétera.

    Visitante anónimo: Muchas gracias por la referencia del artículo. Muy interesante.

  6. Anónimo  

    Bueno, es cierto que uno se casa con una mujer, pero no quiere decir que dejes de tener amigas, aclaro sin ser infiel. CMMI y Metodologias agiles buscan un buen producto, cada uno con su aporte, porque no unir o mezclar a estas dos señoras?? es interesante.
    Adair

Publicar un comentario

Blog Widget by LinkWithin

Seguime

Suscribite al feed de mi blog Suscribite para recibir las actualizaciones de mi blog por correo electrónico Seguime en twitter

Seguidores

Etiquetas

Últimos Artículos

Herramientas

IBSN