Metodología XP : eXtreme Programming

Las metodologías de desarrollo de software ‘Livianas’ ayudan en el Análisis y Diseño Orientados a Objetos y
son ideales en ambientes con herramientas basadas en Java y programación Web. Son llamadas ‘Livianas’
(LightWeight), debido a que no producen demasiado overhead sobre las actividades de desarrollo, y no
impiden el avance de los proyectos, ni obstruyen, poniéndose adelante. De ellas, la mejor –a nuestro criterio-
es la llamada ‘PROGRAMACION EXTREMA’ (XP ó eXtreme Programming), que describimos en este artículo.

Esta metodología se basa en la idea de que existen cuatro variables que guían el desarrollo de sistemas:
Costo, Tiempo, Calidad y Alcance. La manera de encarar los desarrollos avalados por este modelo de
desarrollo es permitir a las fuerzas externas (gerencia, clientes) manejar hasta tres de estas variables,
quedando el control de la restante en manos del equipo de desarrollo. Este modelo hace visibles de manera
más o menos continua estas cuatro variables.

Bajo ciertas circunstancias, el aumento exponencial en los costos de cambiar el software a lo largo del tiempo
puede ser contenido, si convertimos esta curva exponencial en una curva logarítmica, como lo demuestra la
metodología XP (eXtreme Programming), entonces todas las viejas premisas acerca de la mejor manera de
desarrollar software pierden toda validez. Premisas que proponían pensar todo ahora porque luego de
‘terminar’ el análisis y el diseño, los cambios serían mas costosos, y si el sistema ya estaba en producción
serían aún mayores. Esto parte de la premisa falsa de que las etapas se acaban y los sistemas son estáticos.
Lo que dicta XP marca la diferencia que permite realizar hoy el software que cubra las necesidades de hoy,
para que cuando mañana se conozcan mejor las necesidades futuras, se realicen en el momento en que se
necesiten. Utiliza una aproximación minimalista y de mejora continua.

Este modelo parte de la premisa de que los valores de corto plazo de los individuos generalmente colisionan
con los objetivos sociales de mayor plazo. Las sociedades han aprendido a lidiar con este problema
desarrollando sistemas de valores, protegidos por mitos, rituales, castigos y premios. Sin esos valores los
humanos tienden a priorizar sus mejores intereses de corto plazo individuales. En el caso de XP estos valores
son: Comunicación, Simplicidad, Realimentación, Coraje. Este es un conjunto mínimo y consistente de
valores que permitirán hacer la vida más fácil del grupo, la gerencia y los clientes. Sirve tanto a los fines
humanos como a los comerciales.

De estos cuatro valores recién mencionados, XP deriva una docena de Principios Básicos para guiar en su
estilo de desarrollo de sistemas. La derivación de los principios esenciales es clara, desde las premisas
anteriores: Realimentación rápida, Asumir la Simplicidad, El Cambio Incremental, Adherirse (Abrazar) al
Cambio, Trabajo de Alta Calidad (desde ‘trabajo excelente’ hasta ‘trabajo increíblemente sobresaliente’).
Luego podemos mencionar algunos principios no tan evidentes inicialmente como : Enseñar a Aprender, La
Inversión Inicial Debe Ser Pequeña, Jugar Para Ganar, Hacer Experimentos Concretos (reduce la discusión
que lleva a divagar), Comunicación Honesta y Abierta, Trabajar a Favor de los Instintos de la Gente y no
Contra Ellos, Fomentar la Aceptación de Responsabilidad, Adaptarse a las Condiciones Locales, Viajar
Liviano, Mediciones Honestas (por ejemplo, de grado de avance).
XP resuelve volver a lo básico. Al adherirnos a este modelo haremos todo lo que debemos para tener un
desarrollo de software predecible, estable, pero no tendremos tiempo para hacer nada extra. Las cuatro
actividades que guiarán el desarrollo serán : Codificar, Testear, Atender y Diseñar.

A continuación mencionamos las Doce Prácticas de XP que nos permiten realizar desarrollos de Alta Calidad,
en Tiempo y Costo razonables:

I. Jugar el Juego de la Planificación : Rápidamente determinar el alcance del próximo release,

II. Hacer Pequeños Releases : Poner un sistema simple en producción rápidamente, entonces liberar
nuevas versiones del mismo en un ciclo de desarrollo rápido, una por semana a una por mes. Cada
ciclo no debería ser más largo.

III. Hacer Historias y Usar Metáforas : Guiar todo el desarrollo del sistema a través de una Historia
Compartida por el Equipo (o Metáfora) acerca de cómo trabaja (o debería trabajar) el Sistema.

IV. Diseñar Simple : El Sistema debería diseñarse de la manera más simple posible en cualquier
momento dado. La complejidad extra es removida, tan pronto como es descubierta (ver Refactoring
debajo).

V. Probar - Testear : Los Desarrolladores continuamente escriben Testeos Unitarios, los cuales deben
correr sin error para que el desarrollo pueda continuar. Cuando se detecta un error en una corrida, su
reparación pasa a ser la máxima prioridad para el Programador y/o el Equipo. Los Clientes (ayudados
por Desarrolladores) escriben Tests Funcionales para probar qué funcionalidades están terminadas de
acuerdo a sus expectativas.

VI. Rearmar - Refactorizar : Los Desarrolladores reestructuran el sistema sin cambiar su comportamiento
para remover duplicación de código, mejorar la comunicación, simplificar el código, o agregar
flexibilidad.

VII. Programar por Pares : Todo el código desarrollado es escrito por dos desarrolladores sentados frente
a una única estación de trabajo.

VIII. Propiedad Colectiva : Cualquier integrante del Equipo puede cambiar cualquier código de cualquier
parte del sistema en cualquier momento.

IX. Integrar Continuamente : El sistema se integra y se construye (por ejemplo, se compila), es decir, se
unen sus partes, varias veces por día, hasta el extremo de integrar el sistema completo, cada vez que
se termina una tarea.

X. Semanas de 40 Horas : Trabajar no más de cuarenta horas por semana como una regla estándar.
Nunca trabajar sobre-tiempo dos semanas seguidas; si esto es necesario, hay problemas más grandes
que hay que descubrir.
XI. Cliente On-Site: Es condición esencial la inclusión de al menos un Cliente real, vivo, como parte del
Equipo. Debe estar disponible Full-Time para responder preguntas e interactuar con el resto del
Equipo.

XII. Usar Estándares de Codificación : Los Desarrolladores escribirán todo el código de acuerdo a reglas
predeterminadas que enfatizarán la comunicación a través del código. Estos estándares serán simples
de seguir y se seguirán a rajatabla.

Muchos se preguntan cómo pueden estas prácticas seguirse… La realidad es que no es recomendable seguir
algunas de ellas y otras no, ya que cada Práctica soporta a las otras; XP es una unidad. Las debilidades de
una son subsanadas con las fortalezas de otras.

Cómo puede Funcionar este Modelo de Desarrollo ?

El Juego de la Planificación:

No es posible comenzar el desarrollo con sólo un Plan Básico. No es posible modificar continuamente el Plan,
eso tomaría demasiado y haría que los Clientes se enojen.

A menos que…

 Los Clientes actualizan el Plan por sí mismos, basados en estimados provistos por los Desarrolladores.

 Se tiene suficiente del Plan al comenzar, para dar a los Clientes una idea básica de qué será posible para
el próximo año o dos.

 Se hacen releases cortos de manera que cualquier error en el Plan llevaría unas pocas semanas de
remediar, a lo sumo.

 El Cliente se sienta con el Equipo y se siente parte del Equipo, Full-Time, de manera que podrían
identificar cambios potenciales y oportunidades para mejorar el Proyecto rápidamente, agregando valor de
negocio al sistema, de manera temprana.

Entonces quizás sí pueda comenzarse el Desarrollo con un Plan Simple e ir refinándolo continuamente
mientras se avanza en el Proyecto.

Releases Cortos:

No es posible poner el Sistema en Producción después de unos pocos meses. Ciertamente no es posible
hacer Releases del Sistema que van desde un ciclo diario hasta ciclos trimestrales.

A menos que…

 El Juego de la Planificación haya ayudado a trabajar en las metáforas más valiosas, de manera que aún
un pequeño sistema pueda tener buen valor de negocio.
 Se integra continuamente, de manera que empaquetar un ‘Release’ para instalar en Producción, tendrá un
costo mínimo.

 El Testing continuo redujo tanto la tasa de defectos, que no es necesario ir a un lento ciclo de testeo,
antes de permitir al software entrar en producción.

 Puede hacerse un Diseño Simple, de manera de cumplir con los requisitos de este Release, no para
cumplir todas las condiciones que pudieran surgir en un futuro lejano.

Entonces quizás sea posible hacer pequeños Releases, comenzando rápidamente luego que el desarrollo
empezó.

Metáforas :

No es posible comenzar el desarrollo con sólo unas Metáforas, no hay suficiente detalle allí, y qué pasa si la
Metáfora es equivocada ?

A menos que…

 Rápidamente se obtenga feedback concreto de código real y testeos acerca de si la Metáfora está
trabajando en la práctica.

 El Cliente se siente confortable hablando del Sistema en términos de la Metáfora.

 Se Refactoriza continuamente, refinando la comprensión de lo que significa la Metáfora y qué se entiende

Entonces quizás pueda comenzarse el desarrollo con sólo unas Metáforas.

Diseño Simple :

No es posible diseñar sólo pensando en código que sea suficiente para este Release. En ese caso puede
llegarse a un camino sin salida, que no permitiría hacer evolucionar de manera continua el Sistema.

A menos que…

 El Equipo se acostumbre al Refactoring, de manera que hacer cambios no producirá preocupaciones.

 Se tiene una Metáfora clara de manera que los futuros cambios de diseño tenderán a seguir un camino
convergente con esa Metáfora.

 Siempre se Desarrolla con un Socio (programación por pares) de manera que se trabaja con confianza en
un diseño simple, visto y revisado por varios, no en un diseño estúpido.

Quizás entonces se pueda hacer avanzar el Sistema haciendo el mejor diseño para el Hoy.

Testing :
No es posible escribir todos los casos de prueba necesarios. Tomaría demasiado tiempo. Los Desarrolladores
no escriben Tests.

A menos que…

 El Diseño sea tan simple como puede ser, entonces escribir Tests no será tan difícil.

 Siempre se Desarrolla con un Socio, de manera que si uno no puede pensar otro test, quizás su Socio
pueda; y si su Socio está harto de escribir Tests, quizás uno pueda hacerse cargo del teclado otra vez.

 El Equipo se sentirá bien viendo correr -sin cancelaciones- todos esos Tests.

 El Cliente se sentirá bien acerca del Sistema, viendo todas sus Pruebas Funcionales corriendo y sentirá
confianza acerca de los plazos comprometidos.

Entonces quizás los Desarrolladores y los Clientes escriban Tests. Además si los Tests automáticos no son
escritos, XP no funcionará como metodología.

Refactoring :

No es posibe refactorizar el diseño de un Sistema todo el tiempo. Tomaría demasiado. Sería demasiado difícil
de controlar, y seguramente rompería el Sistema.

A menos que…

 El Equipo se acostumbre a la Propiedad Colectiva, de manera que ninguno se atemorizará por hacer
cambios cuando y donde sea necesario.

 Existen Estándares de Codificación, de manera que no es necesario traducir, ni reformatear el código

 Se Programa por Pares, entonces es más fácil tener el Coraje de tomar el toro por las astas, cuando es
necesario Refactorizar, cambiar algo. Así como es menos probable que al hacerlo se rompa otra cosa.

 El Diseño es Simple, entonces Refactorizar no será tan complicado.

 Hay Tests para correr, de manera que si algo se rompe, se sabrá enseguida.

 Hay una Integración Continua, entonces si accidentalmente se rompe algo en otro lado, o el Refactoring
produce conflictos con el trabajo de otros, se sabrá en unas pocas horas.

 Todos están descansados, entonces tendrán más Coraje para Refactorizar y es menos probable que
cometan errores.

Quizás entonces se pueda Refactorizar cada vez que se vea la chance de hacer al Sistema más simple, o
para reducir duplicación de Código, o para comunicar el Código más claramente, o para agregarle flexibilidad.
Programación por Pares :

Es imposible escribir todo el Código de un Sistema en Pares. Sería demasiado lento. Y qué pasa si dos
personas no se llevan bien ?

A menos que…

 Los Estándares de Codificación reduzcan los conflictos de ‘Estilo’.

 Todo el mundo esté fresco y descansado, reduciendo aún más la posibilidad de discusiones ‘no-
productivas’.

 Los Pares escriben los Tests juntos, dándoles la chance de alinear su Entendimiento antes de encarar el
corazón de la implementación.

 Los Pares tienen la Metáfora para ‘bajar a tierra’ sus decisiones acerca del diseño básico y la selección de
nombres.

 Los Pares trabajan sobre un Diseño Simple, de manera que ambos pueden entender qué está pasando.

Entonces quizás podría escribirse todo el código de Producción en Pares. Además la gente que Desarrolla
sola tiende a cometer más errores, a que estos pasen in-detectados, a sobre-diseñar ‘ por si acaso ’
especialmente si no entendieron la Metáfora ‘del todo’. Además tienden a no persistir en las demás prácticas y
volver a viejos hábitos y mañas, aún si no funcionaron antes; especialmente bajo presión.

Propiedad Colectiva :

Es imposible que todo el mundo esté cambiando cualquier cosa en cualquier lado. La gente estaría rompiendo
código ya probado aquí y allá. Y el costo de integración crecería dramáticamente.

A menos que…

 Siempre se Integre luego de un corto lapso de tiempo (diariamente), de manera que las chances de que
haya conflicto bajen.

 Los Tests sean escritos, y corridos continuamente, entonces la chance de romper algo accidentalmente
baja.

 Se Desarrolla por Pares, de manera que sea menos probable romper el código (por aquello de que dos
cabezas piensan más que una). Los desarrolladores aprenden rápidamente que cosa pueden cambiar que
sea redituable.

 Hay una adherencia estricta a Estándares de Codificación, de manera que la gente no se pone a pelear
por ‘dónde tienen que ir las llaves, o el begin y el end’.

Quizás entonces cualquiera podría cambiar código en cualquier parte del Sistema si ve la chance de
mejorarlo. Además sin Propiedad Colectiva, la tasa de evolución del Sistema disminuye dramáticamente.
Integración Continua :

No es posible integrar luego de sólo unas horas de trabajo. La integración toma demasiado tiempo y hay
siempre demasiados conflictos y posibilidades de romper algo accidentalmente.

A menos que…

 Los Tests se puedan correr rápidamente de forma que todos sepan que nada se rompió.

 La programación se realice por Pares, entonces habrá sólo la mitad de flujos de cambio en el Equipo para
Integrar.

 El Equipo hace Refactoring, entonces hay más piezas más chicas, y se reduce la posibilidad de conflictos.

Entonces podría integrarse después de unas pocas horas. Además si no se integra seguido, la posibilidad de
conflictos y la gravedad de los mismos crecerá exponencialmente (y con ello el costo de la Integración).

Semana de 40 Horas :

Es imposible trabajar semanas de sólo 40 horas. No es posible crear suficiente valor de negocios en 40 horas.

A menos que…

 El Juego de la Planificación esté alimentando el Proyecto de manera de identificar el trabajo más valioso a
realizar.

 La combinación del Juego de la Planificación y el testing reduce la frecuencia de sorpresas

 Las Doce Prácticas de XP, vistas como un todo, ayudan a desarrollar a máxima velocidad, no hay
posibilidad de ir más rápido.

Quizás entonces podría producirse suficiente valor de negocios en una semana de 40 horas. Además, si el
equipo no permanece fresco y energético, no ejecutarán el resto de las Prácticas y comenzará la debacle.

Cliente On-Site :

Es imposible tener un Cliente Real en el Equipo, sentado allí todo el tiempo. Seguro puede producir mucho
más valor de negocios en otro lado.

A menos que…

 Pueda producir valor para el Proyecto ayudando a escribir los Tests Funcionales.

 Pueda producir valor para el Proyecto tomando decisiones de prioridad y alcance en pequeña escala, de
manera de guiar a los Desarrolladores diariamente.
Entonces quizás el Cliente pueda producir mayor valor de negocios para la Compañía contribuyendo al
Proyecto. Además, si el Equipo no incluye un Cliente, deberán agregar riesgo al Proyecto planificando sin
feedback y codificando sin realimentación desde el Usuario del Sistema (sin saber exactamente qué Tests son
necesarios para satisfacer los requisitos, y cuáles no son necesarios y pueden ser ignorados).

Estándares de Codificación :

Es imposible pedir a todo el Equipo de Desarrolladores que se adhieran a un estándar común. Los
Desarrolladores son profundamente individualistas y probablemente renuncien a participar en el Proyecto
antes de dejar sus prácticas individuales.

A menos que…

 El conjunto de Prácticas de XP los haga más propensos a ser miembros de un Equipo ganador. Uno que
lleva los Proyectos a un final feliz.

Quizás entonces ellos podrán flexibilizar un poco su posición respecto del ‘Estilo’. Además, sin estándares de
Codificación, fricciones adicionales salen a la luz en la Programación por Pares, que impiden el Desarrollo y
reducen significativamente la velocidad en la Programación y el Refactoring.

Conclusión

Es posible identificarse con eXtreme Programming no sólo desde el punto de vista metodológico, sino casi
filosófico. Existen dos tipos de empresas que desarrollan software, aquellas que venden ‘horas’, y aquellas
que brindan productos funcionando. Si uno tiene la suerte de poder trabajar en Desarrollo de Software y le
divierte hacerlo, no sería posible trabajar de otra forma, sale así. Al fin y al cabo, hay que ponerse del lado del
Cliente que compra un sistema ya que lo que le interesa es verlo funcionar de acuerdo a sus necesidades, y
no una pila de documentos que le explican como ‘será’ en un futuro lejano, siempre y cuando se cumpla la
otra pila de documentos que explica las pre-condiciones para llegar.