Extreme Programming - XP

Metodologia de Desarrollo - eXtreme Programming

La Mejor Metodología ‘Liviana’ de Desarrollo de Software: 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, combinando las prioridades de negocios con los estimados técnicos. Cuando la realidad sobrepasa el Plan, adaptar el Plan.

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 de ella, y haciendo de ésta un mapa cada vez más cercano a la realidad.

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 antes de Refactorizar.

· 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 desagradables, donde el Equipo pasaría más tiempo del que se piensa.

· 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.

Resumen preparado y traducido por Javier Blanqué

Segmentos del Libro “Extreme Programming Explained” – Kent Beck