Apuntes de XP

Recientemente he estado leyendo el libro de Kent Beck "Extreme Programming Explained" y, lo que presento es este post, es el resumen que he hecho sobre el mismo.

XP es una metodología ligera para el desarrollo proyectos de software con requisitos variables o poco definidos. Pone énfasis en el código e introduce prácticas que permiten entregar el software a tiempo, reducir el riesgo, mejorar la respuesta al cambio, aumentar la productividad y hacer más divertido el trabajo en grupo.

El problema del desarrollo de software

El principal problema del desarrollo de software es el riesgo. XP propone soluciones para luchar contra los distintos tipos de riesgo que pueden existir en un proyecto:

• Las iteraciones cortas permiten planificar mejor y reaccionar a los cambios.
• Desarrollar primero las tareas de mayor valor acelera el retorno de la inversión.
• Asegurar la calidad introduciendo pruebas automáticas permite hacer modificaciones de forma segura.
• Probar constantemente el sistema permite encontrar defectos más rápido.
• Involucrar al cliente mejora la especificación del sistema y las expectativas sobre él.
• Otorgar mayor responsabilidad y respeto al programador reduce su frustración. Promueve el espíritu de equipo y crea un mejor ambiente de trabajo.

La Economía del Software

Se debe obtener el mayor valor haciendo la mínima inversión para obtener beneficios de la forma más rápida e incrementar la vida del proyecto.

Para ello, se estudian las distintas opciones de cada funcionalidad del proyecto (implementarla ya, descartarla o posponerla) y se calcula su valor según el beneficio original, el precio de la opción, el beneficio si se ejecuta la opción, el periodo de tiempo durante el que se puede ejecutar la opción y la certeza en el valor final.

Las cuatro variables que permiten gestionar un proyecto son: coste, tiempo, calidad y alcance. El alcance es la variable más potente. XP reduce el riesgo de retrasar el desarrollo de una funcionalidad y juega con el alcance centrándose en realizar aquello que está definido. Se puede modificar el alcance a medida que el proyecto avanza y el conocimiento sobre el producto deseado aumenta.

Se asume que el coste que implica un cambio en el proyecto aumenta exponencialmente según avanza el proyecto. Sin embargo, combinando tecnología y buenas prácticas, se puede conseguir un aumento prácticamente lineal del coste del cambio. Esta es la premisa principal de XP, según la cual las decisiones se deben retrasar hasta obtener la mayor certeza.

Para reducir el coste del cambio se debe usar un diseño simple, pruebas automáticas que puedan ejecutarse en cualquier momento y refactorización para modificar el diseño cuando sea necesario. Se pueden así realizar ajustes durante el desarrollo, de la misma manera que se realizan correcciones al volante cuando se conduce.

Valores, principios, actividades y prácticas de XP

Los 4 valores que dirigen el proceso de XP son:

• Comunicación: la información debe fluir entre el equipo.
• Sencillez: hay que hacer las cosas de la forma más sencilla posible.
• Realimentación: hay que conocer el estado del proyecto en todo momento.
• Coraje: ser capaz de tomar decisiones difíciles cuando sea necesario.

Los valores anteriores inspiran los principios que guían a XP:

• Realimentación rápida: acelerando es el aprendizaje.
• Sencillez: resolver los problemas de forma sencilla.
• Cambio incremental: los cambios son más sencillos si se realizan poco a poco.
• Abrazar el cambio: abierto a lo que depare el futuro.
• Trabajo de calidad: si el trabajo no se hace bien, se pierde la motivación.
• Enseñar a aprender: demostrar todo aquello sobre lo que no haya certeza.
• Pequeña inversión inicial: manejando el alcance, no hacen falte grandes presupuestos.
• Jugar para ganar: la confianza en la propia capacidad ayuda al éxito del proyecto.
• Experimentos concretos: probar cada decisión para asegurar que es correcta.
• Comunicación abierta y honesta: hablar del proyecto de forma directa y sincera.
• Trabajar con los instintos de las personas, no contra ellos: a la gente le gusta hacer un buen trabajo. Hay que ayudar a que esto ocurra.
• Aceptar la responsabilidad: A nadie le gusta que le digan lo que tiene que hacer. Es preferible que cada persona lo elija, pero como miembro del equipo, también debe asumir la responsabilidad de hacer lo que el equipo estime necesario.
• Adaptarse de forma local: decidir qué cosas funcionan mejor en cierto entorno.
• Viajar ligero: mantener pocas cosas, que sean simples y de valor.
• Medida honesta: usar medidas significativas que reflejen el estado del proyecto.

Las actividades principales del proceso de desarrollo en XP son codificar, probar, escuchar y diseñar:

• El código sirve para plasmar ideas y aprender sobre ellas a través de la comunicación.
• El código puede ser probado para ver si cumple con lo esperado. Las pruebas automáticas permiten realizar estas pruebas una y otra vez asegurando el funcionamiento del sistema.
• Para implementar las pruebas, el desarrollador escucha al usuario, que dice cómo debe funcionar el sistema, y al propio sistema, que da realimentación sobre el sistema y sus problemas.
• A medida que el conocimiento evoluciona y se amplían las funcionalidades se revisa el diseño del sistema para poder satisfacer las nuevas necesidades sin afectar a las anteriores. El diseño consiste en organizar el sistema de forma que los cambios lo afecten lo menos posible.

Las actividades anteriores se realizan mediante las siguientes prácticas:

• El Juego de la Planificación: en cada iteración los desarrolladores estiman las tareas y el cliente decide las prioridades, para seleccionar el conjunto de tareas a realizar.
• Entregas cortas: entregar el mayor valor en producción lo más rápidamente posible.
• Metáfora: se utiliza una historia sobre el funcionamiento del sistema, que comparte todo el equipo, para describir el funcionamiento del sistema y guiar el desarrollo.
• Diseño simple: el sistema debe ser lo más simple posible en cada momento.
• Pruebas: se crean pruebas unitarias y funcionales.
• Refactorización: el sistema se reestructura constantemente, sin cambiar su comportamiento, para mejorar el diseño o la comunicación.
• Programación en pareja: el código se escribe en pareja, aumentando la comunicación entre los miembros del equipo y otorgando realimentación inmediata.
• Propiedad colectiva: cualquier miembro del equipo puede modificar el código.
• Integración continua: el código se integra cada vez que se completa una tarea para mantenerlo estable.
• Jornada de trabajo estable: XP supone un esfuerzo y se debe permitir el descanso necesario.
• Contacto directo con el cliente: el cliente debe estar disponible en todo momento para responder preguntas sobre el sistema.
• Estándares de codificación: se programa en base a reglas de codificación que mejoran la comunicación.

No son prácticas novedosas, sin embargo, al llevarlas a cabo de manera conjunta, unas se refuerzan a otras aumentando su potencia.

Gestión de proyectos en XP

La gestión del proyecto no puede ser cosa de una sola persona, nadie tiene conocimiento total del sistema. XP permite una estrategia de gestión descentralizada en la que el gestor sólo debe intervenir en situaciones que no se puedan resolver de forma distribuida.

A la hora de gestionar un proyecto debe existir tanto un perfil administrativo como uno técnico. El perfil administrativo se encarga de que se realice el Juego de la Planificación, de recoger métricas sobre el seguimiento del proyecto y mostrárselas a los interesados. El perfil técnico hace de consejero (coach). No toma decisiones técnicas, sino que ayuda a los de demás a tomarlas y colabora con ellos en el desarrollo. También es el encargado de velar por la buena marcha del proceso de desarrollo.

A la hora de realizar la planificación hay que separar las responsabilidades. Negocio decide el ámbito del proyecto y de las iteraciones, y las prioridades de las tareas. Desarrollo informa sobre las estimaciones de las funcionalidades y las alternativas técnicas. Desarrollo decide el proceso que va a seguir para el desarrollo y las prácticas que llevará a cabo.

La planificación se basa en las estimaciones que los desarrolladores hacen sobre las tareas que el cliente ha priorizado. Sólo se debe planificar en detalle la iteración actual, pero se puede planificar a largo plazo con menor detalle el resto de las tareas.

El objetivo de la planificación es el de maximizar el valor entregado al cliente en cada iteración. Para ello, el equipo de desarrollo deberá invertir lo mínimo posible poniendo el mayor valor en producción lo más rápidamente posible.

La planificación se realiza en las siguientes fases:

• Exploración: trata de descubrir lo que debe hacer el sistema. Se escriben historias que describen lo que debe realizar el sistema, se estiman y, si fuesen demasiado grandes, se dividen en historias más pequeñas.
• Compromiso: las historias se priorizan. A partir de la velocidad de desarrollo del equipo se elije el alcance del proyecto según el tiempo que se disponga.
• Dirección: se realizan iteraciones de alcance restringido durante las que se pueden detectar nuevas historias que pueden ser incorporadas a la planificación. Se vuelve a estimar teniendo en cuenta la velocidad obtenida durante las iteraciones anteriores.

Desarrollo en XP

Durante el desarrollo, las prácticas principales son la integración continua, la propiedad colectiva del código y la programación en parejas.

La integración continua consiste en que los desarrolladores integren sus cambios cada pocas horas, manteniendo la corriente principal del desarrollo en sincronía. Gracias a las pruebas automáticas se verifica en todo momento que el sistema sigue funcionando, y gracias a la refactorización se transforma el sistema en elementos cada vez más pequeños e independientes, de forma que los cambios a realizar están mucho más localizados.

La propiedad colectiva del código hace que cualquiera pueda modificar cualquier parte del código cuando lo necesite. Para ello es preciso atenerse a unas reglas de codificación comunes que faciliten la comprensión del código a todo el equipo.

La programación en pareja obliga a programar, analizar, diseñar y probar de forma conjunta. Esto favorece la comunicación y el aprendizaje. Uno de los miembros se centra en programar, mientras que el otro piensa de una manera más estratégica. Hace que la gente se mantenga fiel a las prácticas de XP, puesto que hay cierta supervisión.

La disposición del entorno de trabajo debe favorecer el trabajo en equipo. Es importante tener espacios comunes donde el equipo pueda reunirse a debatir o donde programar en pareja.

Diseño en XP

En XP se procura tener en todo momento un diseño lo más simple posible. Se realiza una inversión inicial pequeña para proporcionar valor rápidamente, haciendo cosas simples que permitan evolucionar el diseño fácilmente.

El diseño comienza por el desarrollo de pruebas que verifiquen lo que tiene que hacer el sistema. Se irán desarrollando nuevas pruebas que verifiquen más requisitos. Si en el proceso se ve la posibilidad de simplificar lo ya hecho, hay que hacerlo. Así, la primera vez que nos encontremos con un problema, lo solucionaremos de la manera más rápida posible. Las siguientes veces, se trata de flexibilizar la solución para acomodarla a nuevas necesidades.

Lo más simple posible es aquello que comunique su función, no contenga código duplicado y tenga el menor número de clases y métodos.

En el diseño se pueden usar gráficos, pero hay que ser conscientes de que entrañan el riesgo de que la funcionalidad del sistema que definen pueden ser comprobada a través de ellos. Se pueden usar gráficos en los primeros pasos de un diseño y luego convertir el diseño a código para eliminar este riesgo lo antes posible.

La arquitectura del sistema se expresa a través de una metáfora que permite hablar sobre el sistema. Para obtener esta arquitectura se recoge un conjunto básico de historias y se cambiará a medida que el conocimiento sobre el sistema aumente.

Pruebas en XP

XP propone realizar las pruebas a la vez que el desarrollo. Antes de codificar una funcionalidad se debe crear una prueba que valide su funcionamiento. Como las pruebas son automáticas se pueden ejecutar en cualquier momento y verificar que el sistema sigue funcionando.

Las pruebas permiten aprender sobre el sistema. Son realizadas por los desarrolladores, pero también por los clientes, que escriben pruebas que verifican si el sistema cumple con el funcionamiento descrito en sus historias de usuario.

Comenzar con XP

A introducir XP en un nuevo entorno se debe hacer paso a paso, comenzando por aquello que suponga el mayor problema. Normalmente se empieza por las pruebas y la planificación. Es importante reorganizar el espacio de trabajo para favorecer la comunicación desde el primer instante.

Hay que cambiar la estrategia en las siguientes áreas:

• Pruebas: las pruebas otorgan confianza en el código. Hay que ir introduciendo pruebas en el código existente a medida que sea necesario modificarlo por cualquier razón.
• Diseño: XP provocará un aumento en la refactorización. No se debe realizar al mismo tiempo que se añade una nueva funcionalidad. Los objetivos de la refactorización deben ser identificados cuanto antes y ser abordados antes de avanzar en funcionalidades nuevas.
• Planificación: se debe educar al cliente en las nuevas reglas que guían la planificación y convencerle para que escriba historias de usuario.
• Gestión: una de las partes más difíciles es el cambio de mentalidad sobre la gestión del equipo. El gestor debe de dejar de tomar las decisiones que son responsabilidad de los programadores. Los programadores deben asumir la responsabilidad de su trabajo.
• Desarrollo: se debe aprender a desarrollar en pareja y el entorno debe facilitarlo.

Ciclo de vida del proyecto en XP

El ciclo de vida de XP trata de adelantar cuanto lo máximo posible la puesta en producción de valor para el cliente, aunque sólo sea una parte de la funcionalidad. A partir de ahí, se irá incrementando el valor en las siguientes iteraciones.

En una primera fase de exploración se debe analizar la viabilidad del proyecto y estudiar su utilidad y si tenemos las capacidades necesarias para llevarlo adelante. Esta fase termina en el momento en que existen suficientes historias de usuaria para una puesta en producción.

En esta fase se explora la arquitectura del sistema a través de varias alternativas. Se exploran las tecnologías a usar para conocer sus límites y rendimiento. El cliente también debe aprender en esta etapa a escribir historias de usuario. Para ello debe recibir realimentación por parte de los desarrolladores hasta llegar al nivel adecuado.

En la fase de planificación se recogen las historias más valiosas que puedan servir para una primera puesta en producción y se trata de estimar la fecha. A partir de este punto se realizan varias iteraciones. En la primera iteración se tratará de asentar la arquitectura del proyecto y en las subsecuentes iteraciones se irán incluyendo las historias de usuario seleccionadas.

Posteriormente se pasará producción, para lo cual puede ser necesario hacer pruebas de rendimiento del sistema y refinarlo en base a los resultados.

A partir de este momento el proyecto está en la fase de mantenimiento, que es el estado natural de un proyecto en XP. En esta fase se incorpora nueva funcionalidad manteniendo la existente, manejando las altas y bajas en el equipo.

Cada nueva versión necesitará de una fase de exploración que puede implicar la refactorización de parte del sistema. También hay que responder a los problemas que puedan surgir en el funcionamiento normal del sistema, lo que puede disminuir la velocidad del equipo para aportar nueva funcionalidad.

El día en que el cliente ni tiene nuevas historias es el momento en que se debe redactar el funcionamiento del sistema para la posteridad. Este es el fin del proyecto. También se puede llegar al fin del proyecto porque éste no reporte la rentabilidad esperada.

Roles en XP

En un equipo XP existen los siguientes roles:

• Programador: programa y comunica sobre lo que hace. Debe buscar la sencillez del sistema. Es miembro de un equipo que le ayuda a mejorar.
• Cliente: decide lo que debe hacer el sistema en función de la información de que dispone y la que le da el avance del proyecto. También se encarga de escribir las historias que debe cumplir el sistema y crea pruebas para comprobarlo.
• Probador (tester): ayuda al cliente a escribir y ejecutar las pruebas funcionales. Puede ser un programador.
• Rastreador (tracker): recoge las estimaciones, verifica su cumplimiento e informa al equipo.
• Consejero (coach): vela por el cumplimiento del proceso. Su trabajo disminuye a medida que el equipo madura y se hace responsable del proceso.
• Consultor: aporta conocimiento técnico al equipo en un determinado momento, pero no resuelve el problema por ellos.
• Jefe: responde a las necesidades del equipo para la realización el proyecto. Debe pedir explicaciones al equipo sobre su forma de trabajar y, si algo no tiene sentido, hacerlo saber para que el equipo lo corrija.

Observaciones generales

En XP es necesario realizar moderadamente bien el conjunto de todas las prácticas para empezar a obtener resultados notables. Esto es porque las prácticas se apoyan unas en otras y es esta conjunción lo que asegura el buen funcionamiento de XP.

Las prácticas de XP son simples, pero es difícil realizarlas de forma conjunta. Cuando hay problemas, se tiende a relajar la aplicación de las prácticas más exigentes y el proceso se desequilibra si no se corrige rápidamente. También se requiere humildad y coraje para reconocer lo que uno no sabe y preguntar por ello. Hay que estar dispuesto a colaborar.

En ciertas condiciones hay que descartar XP, como cuando tratamos con equipos grandes, clientes desconfiados o tecnología que no soporta el cambio. Estos casos dificultan o imposibilitan la aplicación de algunas de las prácticas de XP, desestabilizando el proceso de desarrollo.

Esto último es muy importante, puesto que por más que nos gusten las ideas que XP propone, puede ser contraproducente adoptar XP a ciegas en determinados entornos en los que pueden llevar al caos. Sin embargo, aunque introducir el conjunto de prácticas de XP no sea una buena opción, algunas de ellas son recomendables en sí mismas en el desarrollo de software, como la integración continua (hasta cierto grado), el uso de estándares de codificación y las pruebas auto

Referencias:

• Extreme Programming Explained (Kent Beck)