Percepciones acerca de la programación ágil y XP

Hace unos días visité una página de una empresa mexicana que entre sus servicios ofrece el desarrollo de software a la medida. En la descripción de sus servicios mencionaban la existencia de la programación ágil y la calificaban como una forma descuidada y riesgosa de hacer software, aunque le reconocían el mérito de ser iterativa.

Sin el ánimo de pretender ser un experto en la materia y con la conciencia clara de que mi posición al respecto es sin duda sesgada pues soy promotor de estas metodologías, quisiera entrar en defensa de las metodologías ágiles contra la percepción que algunas empresas aún tienen.

Las iteraciones de las iteraciones

Si usted es un desarrollador de software o conoce el medio, seguro habrá oído más de una vez acerca de las metodologías iterativas en el desarrollo de software, una de las más conocidas es el RUP (Rational Unified Process) del grupo Rational de IBM.

El RUP ha demostrado ser una metodología eficiente, pero para algunos de nosotros es demasiado protocolaria, es decir, requiere una documentación exhaustiva en muchos casos difícil de llevar.

En el caso de grandes proyectos, sin duda el RUP junto con las herramientas de Rational que ofrece IBM es una excelente opción, siempre y cuando los involucrados en el proyecto comprendan bien de qué se trata el asunto. El RUP no es una receta para hacer software, es una metodología muy sería acerca del proceso de creación del software, y como la mayoría de las cosas serías, es difícil de aprender.

Una de las características que hacen del RUP una metodología muy exitosa es sin duda su enfoque iterativo, esto es, la metodología parte del supuesto de que se trabajará en iteraciones cortas en tiempo y con metas muy claras. Cada iteración tiene entregables claros y en la medida de lo posible, el sistema debe ser funcional desde las primeras iteraciones de desarrollo. Si una funcionalidad no puede terminarse en una iteración, se terminará la iteración sin ella, es más importante terminar la iteración con un sistema funcional y sin errores o detalles incompletos que un sistema que no puede ser evaluado.

Sin embargo, para proyectos pequeños o empresas que no cuentan con un gran departamento de desarrollo, el RUP es una alternativa costosa tanto en dinero como en tiempo. Incluso si se utilizan formas menos comprometidas con IBM como el OpenUP.

Con los años, han surgido alternativas a este enfoque protocolario sin descuidar la parte iterativa. Una rama de estas alternativas es el grupo de las metodologías ágiles que se enfocan más en el desarrollo que en su documentación. Y no me malentienda, dar prioridad al desarrollo (al código y la funcionalidad) no es olvidar por completo la documentación o la planeación.

Tanto en RUP como en las metodologías ágiles existe documentación, la diferencia está en la cantidad de esfuerzo que se destina a la misma en cada una. Por ejemplo, mientras que en metodologías ágiles la fotografía del pizarrón después de un taller de desarrollo es parte de la documentación, en RUP tendríamos que integrar nuestros diagramas a uno de los tantos artefactos que establece la metodología, dibujándolos con alguna herramienta de dibujo de UML y con el mayor detalle posible (esto sólo si no se están usando las herramientas de Rational que tienen un entorno integrado para preparar todos los artefactos de documentación).

En las metodologías ágiles la documentación incluye artefactos menos elaborados, desde el escaneo de un diagrama en una hoja de cuaderno, hasta la grabación de audio de una reunión. Aunque también existe la documentación más tradicional, como los casos o historias de uso (o escenarios de uso como les llama Microsoft) y las cartas de requerimientos.

Uno de los principios de las metodologías ágiles es que la documentación formal debe estar incluida en el código siempre que sea posible, pues es allí donde se necesita. Esto es quizá otra sutil diferencia, para las metodologías protocolarias, la documentación no sólo es para ser usada por los desarrolladores sino también por otras personas que quieren ver el progreso del proyecto así como la “eficiencia” del equipo de desarrollo. Para las metodologías ágiles, la documentación es para los desarrolladores, son ellos quienes la necesitan durante su trabajo diario, tanto en periodos de desarrollo como de mantenimiento.

Así pues, el desarrollo ágil favorece el uso de documentación XML dentro de los archivos de código, no sólo para permitir a los IDE’s presentar “tooltips” descriptivos en el editor de código, sin para que los desarrolladores puedan ver claramente qué hace y para qué está cierto código. Otra ventaja de hacer esto es la posibilidad de usar generadores de código que obtienen estos comentarios desde los archivos fuente y construyen documentos PDF o de hipertexto listos para impresión. Pero esta forma de documentar ni es nueva ni es exclusiva de las metodologías ágiles.

Agilidad al extremo

En el mismo sentido de que la documentación es para y por los desarrolladores, las metodologías ágiles usan el mismo código como documentación. En este sentido, el enfoque de la XP es uno de los más conocidos y el que a un servidor más le gusta.

La metodología XP o Extreme Programming es una de las variantes de las metodologías ágiles con más aceptación en la comunidad internacional de desarrollo. Su creador, Kent Beck la comenzó a gestar junto con Ward Cunningham en 1990 y tomó su forma final en 1996.

Los fundamentos de la XP según Beck son: mejorar la comunicación, buscar la simplicidad, buscar retroalimentación en que tan bien va nuestro trabajo y siempre hay que proceder con valentía.

En consistencia con sus valores, una de las formas de crear documentación en la XP es mediante el mismo proceso de desarrollo, y esto se logra mediante las pruebas unitarias.

Una de las herramientas más importantes de la XP es el desarrollo orientado a pruebas, que utiliza las pruebas unitarias como eje de todo desarrollo. Siendo una directriz de esta herramienta no escribir código para el que no tengamos previamente una prueba unitaria, no sólo mejoramos la seguridad del desarrollo, sino que también documentamos el código de producción con el código de pruebas. Las pruebas unitarias nos dicen qué código existe, qué se espera que haga y cómo se usa, al mismo tiempo que permiten un apoyo imprescindible en “refactoring” (otro pilar de la XP y de la orientación a pruebas) y mantenimiento del código.

Así pues, la documentación “ágil” puede no ser lo más convencional del mundo, pero está enfocada a ser funcional, exhaustiva, formalmente descriptiva, actualizada y de desarrollo concurrente con el código que documenta.

El inconveniente que pudiera tener este enfoque es al momento de comunicarnos con los usuarios o con los gerentes de producto, más preocupados por la “usabilidad” del sistema que por las entrañas del mismo. Pero incluso aquí la XP no tiene problemas.

Aunque no es indispensable para a XP, se puede utilizar documentación de usuario como cartas de requerimientos, historias de uso, cartas de responsabilidad y otros artefactos para apoyar a los miembros del equipo que no tienen ni necesitan un conocimiento profundo sobre el código del sistema.

En este sentido, uno de los grupos de artefactos de documentación que mejor conjuntan las dos necesidades: agilidad en la elaboración y documentación protocolaria, son los definidos por el MSF (Microsoft Solution Framework).

La XP combina de manera muy eficiente una buena práctica de documentación (aunque poco convencional) con un enfoque iterativo mucho más agresivo.

Las iteraciones en XP suelen ser muy cortas y se promueve que los programadores busquen soluciones y experimenten con ellas, programar sin miedo a descomponer el sistema permite un trabajo mucho más ágil y creativo. Por supuesto, esto no sería posible sin buenas prácticas de “versionamiento” que para la XP son indispensables.

Al igual que otras metodologías ágiles, en XP se procura trabajar en parejas, dos desarrolladores por máquina piensan mejor que uno sólo. Al igual que esta técnica, las reuniones diarias del equipo para discutir avances y un continuo trabajo de talleres favorecen una integración mayor en el equipo de desarrollo, una mejor y más eficiente comunicación y un desarrollo más rápido.

Otras prácticas como la integración continua y el monitoreo de las métricas del código apoyan a la XP para conseguir resultados rápidos con software muy seguro, resistente a “refactoring” y fácil de mantener.

8 thoughts on “Percepciones acerca de la programación ágil y XP

  1. Tu post me gusta, pues demuestra que conoces bastante más que aquellos de esas empresa mexicana que suponen que las metodologías express son descuidadas, los descuidados suelen ser los desarrolladores. (Lástima que no mencionas quienes son para no caer es sus garras).
    Pero creo que si queda muy evidente que eres un defensor casi incondicional de las metodologías express, pues si bien tienen grandes ventajas también tiene sus puntos débiles. Todas las metodologías tienen puntos buenos y malos, y creo que la metodología que un equipo de desarrollo elija debe depender no solo de los artefactos y herramientas para esa metodología, sino que además debe tomar en cuenta el proyecto particular y al cliente que lo solicito.
    Kudos en tu primer post!, saludos.

  2. Estoy convencido de que la metodología XP puede utilizarse independientemente del tamaño del proyecto. Entiendo que no a todos los clientes les agrade la idea de utilizar metodologías ágiles, pero creo que esto se debe al desconocimiento que se tiene de ellas, además de que el nombre de “agiles” o “extremas” está un poco cargado de prejuicios.
    Como todo, la XP no es perfecta, pero dadas las opciones, creo que es una de las mejoes metodologías para el desarrollo serio de software, y aquí podríamos abrir otro tema, ¿cuando una empresa quiere desarrollar un sistema, es realmente necesario desarrollar un sistema en lugar de adaptar uno ya existente, sabe en lo que se está metiendo, sabe el costo y el tiempo que implicará?

  3. Saludos de nuevo!

    Este artículo tuyo no lo había leído hasta hoy, cuando lo he encontrado en una madrugada con insomnio. Me alegra sin embargo la noche, fue un lectura en verdad interesante.

    Ya hemos conversado sobre estas cosas antes, pero si me permites decirte las ideas de hoy, tengo dos puntos para poner en la mesa:

    1. Los programadores de XP deben ser experimentados… y hasta ahora no me había dado cuenta de un detalle que se desprende de la visión RUP/UP del mundo: los profesionales comienzan programando pero al crecer y adquirir experiencia dejan de hacerlo.

    Entonces, en la banca ágil se pone a la gente más capacitada a escribir código mientras que nosotros colocamos a esta misma gente en otras cosas, como crear diagramas UML o tratar con el cliente.

    Tenemos entonces, diferencias de enfoque en la evolución del profesional.

    2. RUP/UP nos da un marco para enfrentar otro tipo de proyectos: la adquisición de software por ejemplo, no tiene un componente de código nuevo significativo, ¿es aplicable XP a este tipo de proyecto? Pienso que no. En tal caso que enfoque se sugiere que sea compatible con XP?

    Cuando lo que queremos es instalar y configurar un software obtenido de un proveedor, desarrollar la visión y contar con un diagrama de despliegue siguen siendo útiles pero el refactoring y la programación en parejas no tienen cabida.

    RUP en su versión 7.0 introduce la idea de un marco común de prácticas y capacidades, a partir del cual se pueden configurar procesos específicos, donde el desarrollo de software es solo uno de los posibles. ¿Ya lo habíamos comentado cierto? Recuerda que tengo insomnio, cualquier redundancia me la has de perdonar.

    Te comento por ultimo sobre un extracto de tu artículo:

    “Si una funcionalidad no puede terminarse en una iteración, se terminará la iteración sin ella, es más importante terminar la iteración con un sistema funcional y sin errores o detalles incompletos que un sistema que no puede ser evaluado.”

    Si lo interpreto bien, dices que la capacidad de evaluar el software es incluso más importante que el de tener la funcionalidad completa, es decir: es necesario cumplir con el punto de control. Retrasar este unos días para terminar con una sección del código no es lo correcto.

    Si lo he interpretado bien, entonces no puedo estar más de acuerdo.

    Estamos hablando.

  4. Iván,

    Me da gusto volver a saber de ti y de tus “diferencias” :)

    Vamos punto por punto. En cuanto al desarrollo profesional y el tipo de roles de los desarrolladores experimentados, creo que has tomado mis palabras un poco demasiado al pie de la letra y las has hecho decir cosas que no he querido decir. Me explico:

    No es que en XP tomemos a los mejores programadores y los dejemos siempre programando, en espera de que se conviertan en unos apéndices de sus computadoras o que les aparezcan puertos USB en algún lado.

    De hecho, los desarrolladores más experimentados tienen varias tareas específicas en XP, la primera, es monitorear y trabajar en pareja con los más inexpertos para entrenarlos, liderar los talleres de arquitectura y participar muy activamente en las reuniones con los clientes para guiar el descubrimiento del dominio y de los procesos.

    En cuanto al UML, mi posición es la misma que la de Martin Fowler, creo que el UML es una herramienta de comunicación entre humanos. La uso para expresar mis ideas en los talleres de arquitectura o para indicar a un colega una idea o una pregunta, pero no uso herramientas de dibujo de UML a no ser que el cliente pida los diagramas. Sin embargo, mantengo la idea de que en el equipo todos deben dominar al menos los diagramas de estructura y los diagramas de secuencia para poder comunicarse fácilmente con los demás. Creo que el dominio del lenguaje UML y de los patrones más utilizados es importante para comunicarnos en el equipo, más que para poder realmente programar.

    Por ejemplo, si sugiero el uso de un “Unit of Work” en cierto sistema, sé que no tengo que explicar exactamente qué quiero que haga el sistema, los demás saben a qué me refiero porque conocen el patrón. Lo mismo con UML, no me la paso explicando qué quieren decir las flechitas, porque sé que mis colegas dominan lo necesario del UML para poder entendernos.

    En resumen, creo que los desarrolladores más experimentados, en efecto terminan más en reuniones con los clientes para descubrir dominio y requerimientos, así como liderando talleres de arquitectura (donde dibujan UML) pero también participan directamente en el desarrollo y en la formación de los más jóvenes. ¡Nuevamente, parece que nuestras diferencias no lo son tanto!

    El punto dos, en donde te refieres al Outsourcing o la compra y adquisición de software o sistemas externos. En efecto tienes razón, en XP no tenemos manera de manejar estas adquisiciones, pero como bien sugieres, existen metodologías y estrategias para realizar estos procesos:

    Es cierto que la metodología XP no tiene un proceso para la adquisición de software o código externo, pues es una metodología de desarrollo y no una metodología de apoyo gerencial como lo es RUP/UP, sin embargo, en este tipo de procesos, podemos fácilmente tomar mano de Scrum o de la misma RUP para llevar a cabo el proceso de adquisición de manera controlada. Ya lo he dicho antes, soy un promotor de la XP, no un enemigo del RUP/UP.

    La conclusión aquí sería que en efecto la XP no maneja adquisiciones externas, pero que es compatible con metodologías de apoyo gerencial que si tienen estos procesos descritos, como Scrum y RUP/UP.

    Tu último punto que has dejado sin número es sobre la prioridad de la evaluación del sistema contra la implementación de funcionalidad sin pruebas. En efecto, me has entendido bien. Los puntos de control, el tener la funcionalidad realmente funcional, el tener las pruebas y las evaluaciones con focos verdes es más importante que la funcionalidad incompleta o la codificación a medias. Así mismo, las fechas de fin de iteración no debieran ser negociables, para mantener el control del proceso de desarrollo y mejorar la estimabilidad del proyecto completo.

    Un gusto, como siempre, saludar a un miembro de la trinchera vecina del RUP/UP.

  5. Hola, estimado una consulta, (se que este tema es bastante antiguo), cuales serian los diagramas(diagrama de contexto, dfd, se pueden ocupar casos de uso?) a utilizar si se aplica xp para un proyecto pequeño?.

    Saludos.

  6. Daniel, el tamaño del proyecto no debería determinar el tipo de diagramas. Los diagramas son instrumentos de comunicación y, en ese sentido, los diagramas más adecuados para un proyecto particular son aquellos que el equipo mejor entienda. Usualmente en XP se prefieren los diagramas UML a los DFD, pero eso es una decisión del equipo. En UML el diagrama por elección sería el de “Caso de uso”. Un diagrama de contexto podría ser una alternativa. Lo más importante, en todo caso, es tatar de mantener el caso de uso lo más independiente de implementación que sea posible. Mi recomendación es no preocuparse por los diagramas, comenzar con “historias de usuario” de una oración y promoverlas a “caso de uso” (con narrativa) donde se requiera mayor clarificación o flujos alternativos explícitos.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s