Buscar en Gazafatonario IT

miércoles, febrero 09, 2005

El Proceso Unificado de IBM Rational - "La Guerra de las Metodologías"

La presentación de RUP que hice en el articulo El Proceso Unificado de IBM Rational - "El Imperio de las Metodologías" suscitó algunos interrogantes. Un amigo, por ejemplo, quiere empezar “desde cero” y comprar una metodología para usar. Mi breve exposición lo inquietó pero y…, siempre hay un pero, la competencia, cuáles están en la lista de posibilidades. Desde mi punto de vista, le dije, una metodología debería, por lo menos, definir roles y responsabilidades específicas, con actividades o procedimientos detallados para cada uno, así como alguna clase de ciclo de vida completo del desarrollo de software y un conjunto de artefactos o entregables con algún tipo de resumen o de plantilla para cada uno de ellos. Por supuesto, debe ser algo aceptado más o menos universalmente y no debe ser solo un cúmulo de ideas de alguien (el metodologista) en un libro. He aquí algunos iniciadores:

RUP (Contendor Obvio, El Imperio.

http://www-136.ibm.com/developerworks/rational/products/rup )

CMMi (No es realmente una metodología, o sí? Parece ser más bien un conjunto de medidas. Todos los detalles en http://www.sei.cmu.edu/cmmi/.

XP ¿Dónde está la definición “real”? Está aquí: http://www.extremeprogramming.org/.

MSF http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/tandp/innsol/msfrl/msfovrvw.asp)

Cascada (dónde esta la mejor y más acordada versión? Vale la pena volver al pasado? Miren este: http://www.idinews.com/waterfall.html)

PMBOK (del PMI – Project Management Institute –Esta no es específica, no proporciona una guía determinada, al desarrollo del software sino más general –es más bien una metodología de manejo de proyectos. El sitio Web oficial es:

http://www.pmi.org/info/default.asp.

ITIL (pero parece más algo sobre servicios que sobre desarrollo de software, http://www.ogc.gov.uk/index.asp?id=2261)

Con esta lista cualquiera pierde el entusiasmo. Pero hay más, un vistazo más detallado al vasto universo metodológico nos obliga a situarnos en un extremo de la Galaxia y a mirar con el Telescopio Espacial Hubble (bueno, si lo arreglan) un poco más allá de nuestras narices. Y así, nuestra lista creció:

Scrum (http://www.controlchaos.com/). Hay que leer y el libro de Alistair Cockburn sobre metodologías ágiles, Agile Software Development, es un muy buen comienzo. Todos los pormenores en http://members.aol.com/acockburn/. Este libro provee guías para seleccionar una metodología, basado en criterios diversos (criticidad del sistema, tamaño del equipo, tamaño del proyecto, entre otros).

Shlaer/Mellor, una de mis favoritas hasta hace unos años, pero que está totalmente renovada. Su casa está en http://www.projtech.com/. Allí encontrarán XTUML, un proceso de desarrollo dirigido por el modelo basado en UML. Los modelos que produce XTUML son ejecutados y probados en las primeras fases del ciclo de vida del software y son traducidos para generar código optimizado de alta calidad.

Iconix (http://www.iconixsw.com/) de Doug Rosenberg, de la cual he aplicado muchos conceptos últimamente. Esta metodología ágil facilita elementos que nos llevan de la mano desde el análisis de requerimientos hasta la producción de código fuente, la recomiendo ampliamente.

Crystal, http://www.crystalmethodologies.org, de Highsmith y Cockburn a quien ya había mencionado, quienes nos presentan una ceremonia de acuerdo al número de personas y a la “criticidad” del software a construir.

EUP –Enterprise Unified Process –que tal esta variante (extensión) del Proceso Unificado de Scott Ambler y compañía? La encuentran en http://www.enterpriseunifiedprocess.info/. El señor Ambler siempre tiene algo interesante que decir y es uno de los mayores colaboradores en la comunidad metodológica IT.

Agile Data, un método que describe filosofías de cómo los profesionales de los datos, los profesionales de la empresa y los desarrolladores pueden trabajar juntos de una forma ágil. La Web es http://www.agiledata.org/.

Agile Modeling o AM, sin duda, una de las más efectivas en cuanto a modelado y documentación, no es un proceso completo pero trabaja muy bien con RUP y decidimos escogerla. La encontramos en http://www.agilemodeling.com/, donde otra vez Scott Ambler nos entrega una gran cantidad de información con la cual iniciar nuestro trabajo. A propósito, en su columna Ad Aperturam Libris, John Alexander nos extiende este tema de Agile Modeling así que pasen por allá y me cuentan que les parece.

Y la lista podría ser interminable. Finalmente sería como saltar de estrella en estrella, a través de una inmensa galaxia de posibilidades. Sin embargo, debemos recordar siempre que la gente es más importante que el proceso, pero este es extremadamente útil para tener éxito en la ejecución de un proyecto. Aun una metodología “liviana” como XP demanda una adherencia estricta a sus principios y prácticas, contrario a lo que sucede con RUP que es más flexible.

Un proceso no es una narrativa; no es una vieja guerra metodológica modernista, Cristianos Vs. Freudianos, por ejemplo, pero sí es un thriller post-moderno. Si uno prefiere, significa ser muy exigente, pero también ambicioso. Uno de los maestros del oficio, a quien ya me he referido, Alistair Cockburn, dice que nosotros deberíamos tomar lo que queramos de las metodologías establecidas, probarlo, sumar nuestras ideas y usar todo para que nos ayude en nuestro propio “contexto específico”. Y yo agrego: es un asunto de adoptar y adaptar la experiencia de otros al medio, a lo que el mercado local nos permite, es un asunto de economía también, RUP, por ejemplo, es dinámico, pero exigente en cuanto a personal y recursos.

Y aquí estamos de nuevo, ante las puertas de un universo ignoto, pletórico de posibilidades y riesgos, pero interesante y, sobre todo, útil.

Comparte tus impresiones conmigo y con todos en la red sobre este y otros temas. Puedes escribirme a mailto:lucho.salazar@gmail.com.

Luis Antonio Salazar Caraballo

Medellín, septiembre 12 de 2003

1 comentario:

  1. "Nosotros deberíamos tomar lo que queramos de las metodologías establecidas, probarlo, sumar nuestras ideas y usar todo para que nos ayude en nuestro propio “contexto específico”." y "Es un asunto de adoptar y adaptar la experiencia de otros al medio, a lo que el mercado local nos permite, es un asunto de economía también"

    Muy de acuerdo que estoy, de hecho uno de los problemas con los que lidiamos al coachear equipos (ágiles o tradicionales) es que se casan con la "metodología", con el proceso y no se adaptan a utilizar las técnicas y herramientas de diversas metodologías o marcos de trabajo que hemos transitado durante nuestra vida como administradores de proyectos. Un consejo que doy es abrirse a probar, nada esta escrito en piedra y si algo te sirve no lo descartes, si una herramienta te es útil no la descartes por que no pertenezca a la metodología que usas, debemos adaptarnos! algo bueno puede salir de ese intento

    ResponderBorrar