Palabras Clave:programación extrema, metodología de desarrollo.

[English]

Problemas con el software

El desarrollo de software es riesgoso y difícil de controlar. Por más que en los últimos años han evolucionado diversas metodologías para asegurar un mejor control del proceso, los clientes quedan frecuentemente insatisfechos con el re-sultado, mientras que los desarrolladores no quedan menos insatisfechos. La figura 1 muestra una relación del éxito/fracaso de los proyectos de software, de 1994 a la fecha (ver reporte completo en The Standish Group, 1995). Los proyectos "en problemas" son los que se salen del presupuesto, tienen importantes retrasos o, simplemente, no cumplen con las expectativas del cliente.

Figura 1

La mayoría de estos proyectos han seguido una metodología de desarrollo tradicional. Dicha metodología exige, en general, cumplir con estas actividades:1. Levantamiento exhaustivo de requerimientos.2. Detección de defectos en las fases iniciales.3. Reducción en el número de cambios, tanto como sea posible.4. Análisis y diseño, tan completo como sea posible.5. Diseño genérico, intentando anticiparse a futuras necesidades.

En la mayoría de los casos, las metodologías tradicionales hacen uso de la experiencia de otras áreas de la ingenería, cuya tradición en cuanto a proyectos exitosos es mucho más antigua. Sin embargo, el software tiene una característica especial que lo hace intrínsecamente distinto a un puente o un edificio. Esa diferencia viene señalada, precisamente, en el prefijo soft.

El costo del cambio

Uno de los principales problemas que enfrenta un proyecto de desarrollo de software, es la casi imposibilidad de precisar los verdaderos requerimientos del sistema al inicio del desarrollo. Por más exhaustivo que sea el levantamiento de requerimientos y más detallado el análisis y el diseño inicial, en cualquier etapa del ciclo de vida del proyecto siempre van a aparecer necesidades imprescindibles.

En la curva superior de la figura 2 se muestra el costo del cambio en relación al tiempo, es decir, la etapa del ciclo de vida del proyecto. Tradicionalmente, entre más tarde aparezca la necesidad de un cambio, el costo de implementación de éste se elevará exponencialmente.Aplicada correctamente, la programación extrema mantiene dicho costo en un nivel prácticamente independiente con respecto a la etapa del ciclo de vida, como puede observarse en la curva inferior. En las siguientes secciones se intentará mostrar por qué.

Figura 2

El estilo XP

La programación extrema, XP por sus siglas en inglés, es una metodología ágil para desarrollar software (Fowler, 2000). En contraste con las metodologías tradicionales, burocráticas y poco ágiles, la XP tiene las siguientes características (Beck, 1999):1. Está orientada a quien produce y usa el software.2. Reduce el costo del cambio en todas las etapas del cliclo de vida del sistema.3. Combina las que han demostrado ser las mejores prácticas para desarrollar software, y las lleva al extremo.

Como se muestra en la figura 2, cuando se aplican los principios de la XP, el costo del cambio, idealmente, se mantiene constante. La XP puede describirse someramente por los siguientes puntos:1. Empieza en pequeño y añade funcionalidad con retroalimentación continua.2. El manejo del cambio se convierte en parte sustantiva del proceso.3. El costo del cambio no depende de la fase o etapa.4. No introduce funcionalidades antes de que sean necesarias.5. El cliente o el usuario se convierte en miembro del mismo equipo.

La XP prescribe un conjunto de valores y prácticas, que permite a los desarrolladores dedicarse a lo que hacen mejor: programar. La XP elimina la necesidad de dedicar tiempo a labores tediosas y burocráticas, prescritas por los procesos no ágiles, tales como: exhaustivos documentos de proyecto, diagramas de Gantt, enormes volúmenes de listas de requerimientos, juntas de revisión interminables, etcétera.

Los Valores

Kent Beck definió los valores fundamentales de la XP en su libro blanco (Beck, 1999). Estos pueden resumirse de la siguiente manera:

Comunicación

Algunos problemas en los proyectos tienen su origen cuando alguien no dice algo importante en su momento. XP hace casi imposible la falta de comunicación.

Simplicidad

En relación al proceso y la codificación, XP propone el principio de hacer la cosa más simple que pueda funcionar. Es mejor hacer hoy algo simple, que hacerlo complicado y sin probabilidades de uso mañana.

Retroalimentación

La retroalimentación concreta y frecuente del cliente, el equipo y los usuarios finales, da una mayor oportunidad para dirigir el esfuerzo eficientemente.

Coraje

El coraje como valor, existe en el contexto de los otros 3 valores.

Para la XP, la definición de simplicidad es la siguiente: 1. El sistema (código y pruebas) comunica claramente todo lo que necesita ser comunicado en el instante mismo de desarrollo. Esto significa que corren todas las pruebas y que el código fuente revela su intención a cualquiera.2. El sistema no contiene código duplicado, a menos que se viole (1).3. El sistema contiene el mínimo número de clases, a menos que se violen (1) y (2). 4. El sistema contiene el menor número de métodos posible, consistente con (1), (2) y (3).

El coraje, en su acepción de valor, existe en el contexto de los otros 3 valores. Cada uno de ellos se apoya en los demás:1. Se requiere valor para comunicarse con los demás, cuando eso podría expo-ner la propia ignorancia.2. Se requiere valor para mantener el sistema simple, dejando para mañana las decisiones.3. Se requiere coraje para confiar en que la retroalimentación, durante el camino, es mejor que tratar de adivinar todo con anticipación.4. Sin un sistema simple, una comunicación constante y una retroalimentación, es difícil mantenerse en una postura valerosa.

Las Prácticas

Las prácticas de la XP traducen estos valores en actividades que un programador debe realizar diariamente. La mayoría de estas prácticas no son nuevas. Han sido reconocidas por la industria como mejores prácticas durante años. En la XP dichas prácticas son llevadas al extremo para obtener más que la suma de las partes. Las 12 prácticas pueden agruparse en cuatro categorías:1. Retroalimentación a escala fina2. Proceso continuo en lugar de por lotes3. Entendimiento compartido4.

Bienestar del programador

En las siguientes subsecciones se enumeran dichas prácticas. Más adelante se explicarán algunas de ellas. Retroalimentación a escala fina1. Desarrollo guiado por pruebas, vía Pruebas de Unidad y Pruebas de Aceptación. Juego de Planeación, donde los clientes y los programadores negocian el alcance de una iteración del proyecto y los tiempos estimados de desarrollo.2. Cliente presente (On site Customer)3.

Programacion en pares

Proceso continuo en lugar de por lotes1. Integración continua2. Refabricación sin Piedad3.

Liberación Pequeña

Entendimiento compartido1. Diseño Simple. Lo que sea más simple, que aporte la funcionalidad deseada, elimine lo que no sea estrictamente necesario, es decir, simplificar vigorosamente.2. Metáfora del Sistema, equivalente a arquitectura.3. Propiedad Colectiva del Código. No hay personas que sobresalgan más que otras, pues el código es de todo el equipo. Todos los programadores pueden modificar cualquier parte del código.4. Convenciones de Código. Si el código es colectivo, todos los programadores deben seguir las mismas convenciones, de modo que sea difícil distinguir quién escribió cualquier parte del código.

Bienestar del programador1. Cubrir una semana de cuarenta horas. Está demostrado que la productividad no se incrementa con horas extras, pues los programadores cansados son menos productivos y más propensos a errores.

Pruebas de Unidad

Las pruebas de unidad son una herramienta clave para el control de cambios. Son programas no interactivos, escritos para correr en lotes y probar clases. Típicamente consisten en verificar que el resultado de un método, de una clase específica, corresponda con un resultado esperado. Se prueba cualquier aspecto de la clase que pudiera alterar el comportamiento o estado interno de la misma. No se prueban métodos de accesos (los típicos gets).Se recomienda escribir primero las pruebas, antes de escribir propiamente el código que va a verificarse. Cada vez que se hace un cambio, es requsito correr una sesión de pruebas, a modo de verificar que los cambios no han afectado el comportamiento del sistema, es decir, que no han introducido defectos o bugs.

Programación en Pares

La programación en pares requiere que dos desarrolladores participen en un proyecto, en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento. Los estudios demuestran (Williams, 2002) que, contra lo que pudiera pensarse, dos programadores son más eficientes que uno solo en una tarea determinada: el resultado es mayor que la suma de las partes.

De alguna manera se aplica el principio de que dos cabezas piensan más que una. Mientras uno se concentra en escribir el código, el otro puede percatarse de problemas potenciales al tener una mejor visión del asunto. Una analogía útil es el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa y dirige. Otro resultado útil de la programación en pares, es que se retoma el antiguo esquema de maestro-aprendiz. El programador más experimentado transmite su experiencia al novato y lo hace aplicar su experiencia por medio de la práctica supervisada.

Refabricación

Es el proceso de modificación del código en un sistema de software, de modo que no se altere su comportamiento externo, pero se mejore su estructura interna. Es una técnica disciplinada de restructuración de código. Refabricación es un neologismo en inglés, por lo que su traducción al español no es fácil. Algunas personas opinan que refactorización es una traducción correcta, ya que se asocia a la operación aritmética de factorizar los términos de una expresión para hacerla más simple, por ejemplo: ab+ac= a(b+c). Sin embargo, eso aún está en discusión (Sierra, 2002).La principal referencia sobre refabricación sigue siendo el libro que escribió Martin Fowler en 1999 (Fowler, 1999). El mismo autor mantiene un catálogo bien organizado, en el que a cada refactorización se le asigna un nombre y se incluyen ejemplos. Puede verse en: http://www.refactoring.com/.

Un solo equipo

Como hemos visto, el cliente y el programador forman parte de un mismo equipo. Para entender mejor este concepto, ilustraremos los roles del cliente y el programador, a través de las declaraciones de sus derechos. Derechos del Cliente1. Decidir qué se implementa.2. Saber el estado real y el progreso del proyecto.3. Añadir, cambiar o quitar requerimientos en cualquier momento.4. Obtener lo máximo de cada semana de trabajo.5. Obtener un sistema funcionando cada 3 ó 4 meses. Derechos del Programador1. Decidir cómo se implementan las cosas.2. Crear el sistema con la mayor calidad posible.3. Pedir al cliente, en cualquier momento, aclaraciones a los requerimientos.4. Estimar el esfuerzo para implementar el sistema.5. Cambiar las estimaciones con base en nuevos descubrimientos.

Por dónde empezar

La XP no es una metodología sencilla. Se requiere mucha disciplina, así como la capacidad para integrar un equipo con todos los involucrados en el proyecto, incluido el cliente.1. Pruebas Unitarias.2. Refabricación.3. Programación en pares.

Lo principal es documentarse a fondo sobre esta metodología. Al final ofrecemos las referencias esenciales, siendo Beck, 1999 y Fowler, 1999 las más importantes.

Quién es quién en la XP

Algunas de las personalidades más importantes en el desarrollo de la XP, son las siguientes:

Los gurús1. Kent Beck. Gurú de la XP y autor de los libros más influyentes sobre el tema, principalmente XP Explained. Es editor de la serie XP de AW.
2. Martin Fowler. Gurú de la refabricación y autor de numerosos libros (Refactoring), artículos y el sitio http://www.refactoring.com/.
3. Erich Gamma. Coautor de JUnit y del famoso libro sobre patrones de diseño Design Patterns.
Los practicantes y divulgadores: 1. Ronald Jeffries. Primer discípulo y promotor, autor de un sitio web y el segundo libro de la serie XP Installed. 2. Laurie Williams. Ha hecho de la Programación en Pares su especialidad, tema de su tesis doctoral. Ver http://pairprogramming.com/. 3. William Wake. Autor de maneras originales de explicar la XP, entre ellas los juegos. Es autor de uno de los libros de la serie XP: XP Explored. 4. Joshua Kerievsky. Experto en patrones y XP, actualmente escribe un libro sobre Refactoring to Design Patterns. Entre sus estrategias de capacitación en XP, también se incluyen los juegos.

Conclusiones

La XP es una metodología aún joven. No es la panacea y, por supuesto, no brinda ninguna garantía de éxito al aplicarse indistintamente a cualquier proyecto. No obstante, la experiencia ha demostrado que puede dar resultados sorprendentes. Véase por ejemplo Jeffries, 2002 y Kerievsky, 2002.

Invitamos a todos los lectores a visitar nuestra página Wiki (Sierra, 2002), donde encontrarán más documentación y referencias en español sobre el tema. Además, recomendamos visitar las siguientes referencias en línea:

Welles, 2002; Brewer, 2002; Jeffries, 2002; Kerievsky, 2002, y Wake, 2002.Beck, Kent (1999) Extreme Programming Explained.Brewer, John (2002) [en línea].

http://www.jera.com/techinfo/xpfaq.html.Fowler, Martin (1999) Refactoring: Improving the design of existing code.Fowler, Martin (2000) The new methodology [en línea].

http://www.martinfowler.com/articles/newMethodology.html, 2000. The Standish Group (1995) [en línea].

http://www.standishgroup.com/sample_research/chaos_1994_1.php, 1995.Jeffries, Ron (2002) [en línea].

http://www.xprogramming.com/.Kerievsky, Josh (2002) [en línea]

http://www.industriallogic.com/xp/. Sierra, Aguilar, Alejandro (2002) [en línea]

http://www.programacionextrema.org/, 2002.Wake, William (2002) [en línea]

http://xp123.com/.Welles, Don (2002) [en línea]

http://www.extremeprogramming.org/.Williams, Laurie (2002) Pair Programming Illuminated.

Dirección General de Servicios de Cómputo Académico-UNAM
Ciudad Universitaria, México D.F.