La metodología de programación extrema fue introducida por el americano Kent Beck (autor también de la metodología de desarrollo guiado por las pruebas (TDD: Test-driven Development) y coautor de JUnit) en el año 1999, aunque empezó a trabajar en la misma años antes, concretamente desde el año 1996 cuando fue contratado por Chrysler Corporation, para intentar sacar adelante una aplicación para nóminas que hasta entonces tenía importantes problemas en el desarrollo. Cuando empezó a trabajar en el proyecto, detectó una serie de aspectos en el proceso de desarrollo que debían cambiar, aplicando para ello una serie de estrategias, muchas de ellas basadas en buenas prácticas ya contempladas y utilizadas.
La programación extrema se sitúa en una posición diferente a los ciclos de vida tradicionales. Ya no se trata de requisitos que se cierran en etapas tempranas del desarrollo y que constituyen el contrato de lo que posteriormente se va a desarrollar (y que los usuarios no ven hasta mucho después) sino de requisitos que están vivos y que son modificables a lo largo del ciclo de vida.
La programación extrema se centra en cinco principios:
– Simplicidad: Conforme en el proceso de construcción un sistema va creciendo paulatinamente (aplicable también a mantenimientos sobre sistemas ya construidos), la complejidad del código va creciendo de manera proporcional (o incluso exponencial en función del tamaño del proyecto y del número de personas que participen en el proceso).
Mediante la refactorización, se intenta mantener el código en unas condiciones donde la complejidad esté controlada y facilite la escalabilidad del sistema. Esto requiere disciplina y creer que esta metodología produce resultados ya que resulta complicado tomar la decisión de tocar código que ya funciona (esto va en contra de una de las máximas de la programación que consiste en que no toques algo que funciona, aunque también es cierto que la misma viene derivada de las malas experiencias provocadas por la crisis del software).
La integración continua resulta esencial en esta metodología, ya que ofrece la oportunidad de probar con una cierta regularidad la integración de los componentes, de manera que este tipo de problemas se puede detectar lo antes posible.
El control de la calidad del código se complementa con otras estrategias como por ejemplo el intento de que el mismo sea lo más autocomentado posible (sin prescindir de comentarios cuando sean necesarios). ¿Por qué la metodología prioriza la autodocumentación? Como el proyecto es algo que está vivo, el código se modifica con cierta frecuencia (sobre todo en el proceso de construcción), ¿por qué preocuparse en comentar un código que tal vez tenga que modificar muy pronto ya sea por una modificación funcional, por una corrección o por una refactorización? A esto hay que añadirle el peligro de que empiecen a quedarse atrás comentarios que no se han eliminado y que no se correspondan con la realidad del código. Si el código está autodocumentado evoluciona de la misma manera que lo hace el proyecto.
Para esta metodología lo más importante del proceso de desarrollo de software es el código, la base para esto tiene un razonamiento simple, sin código no hay aplicación. Se considera que una aplicación que funciona según las necesidades del cliente tiene mucho más peso que el hecho de que esté documentada al detalle.
Para sostener esta afirmación en sistemas de un cierto tamaño es fundamental un código de mucha calidad. De no ser así, el cambio de un equipo de desarrollo por otro puede provocar un riesgo importante para conseguir una continuidad en el mantenimiento del proyecto ya que se estará caminando por un terreno lleno de trampas y con poca luminosidad.
– Comunicación: Fluida y continua. Para ello se programa por parejas (pair-programming, un ordenador, dos personas) y los usuarios designados por el cliente forman parte del equipo de desarrollo (se eliminan fronteras). Pero la comunicación va más allá de eso, un código comentado (autodocumentado) y con pruebas unitarias definidas expresa información para la comprensión del mismo, es como una caja del tiempo o un mensaje en una botella y que será muy útil cuando se tengan que realizar modificaciones.
Algunos de los críticos de esta metodología comentan que la tendencia de los programadores a considerar el código desarrollado como propio dificulta el proceso de comunicación ya que cada cual considera que sus opiniones y decisiones son y han sido las mejores, que su código es difícilmente superable (o por lo menos que era complicado hacerlo mejor en el tiempo que se ha dispuesto para desarrollarlo) y además no se suelen aceptar de buen grado las correcciones (sobre todo si están relacionadas con la calidad).
Para resolver ese inconveniente la programación extrema considera que el código es colectivo, no hay parcelas, de manera que cualquier integrante del equipo de proyecto puede realizar contribuciones a cualquier parte del mismo.
Las pruebas unitarias resultan esenciales, ya que permiten automatizar la revisión del funcionamiento de cada módulo y así tener la posibilidad de realizar este tipo de tareas con frecuencia. Hay que tener en cuenta también que el código está en continua evolución por lo que las pruebas de regresión cobran importancia. El objetivo es detectar posibles errores lo antes posible. La detección tardía de errores es más costosa y su corrección además tiende a ensuciar el código (cuando el tiempo aprieta lo importante es apagar el fuego).
Aunque no es obligatorio, se recomienda incluso que las pruebas unitarias de cada componente estén construidas antes de desarrollarlo.
Otro aspecto característico de la metodología son las reuniones diarias, que se realizan de pie y en círculo (stand-up meetings) y que tienen una duración aproximada de quince minutos. En las mismas se habla sobre el estado actual del proyecto y sobre contingencias, problemáticas o dudas que se produzcan en el mismo.
Para favorecer la comunicación se aconseja que todo el equipo de trabajo se encuentre en la misma ubicación física y en entornos despejados.
– Retroalimentación: La participación y proximidad de los usuarios permite resolver dudas casi de forma instantánea, pueden ver funcionalidades concretas construidas parcialmente y opinar sobre ellas. Se comparten opiniones sobre cuál puede ser la mejor solución (es importante lo funcional pero hay que equilibrar lo que se quiere con la complejidad de realizarlo, como dijo Voltaire, lo perfecto es enemigo de lo bueno)
El desarrollo iterativo incremental permite que en cada evolución el usuario pueda expresar su opinión sobre los resultados obtenidos y si es necesario corregir algo, planificarlo para la siguiente o próximas iteraciones.
– Coraje: Optar por esta metodología no es sencillo por muchos factores, por muchos interrogantes. ¿Es sencillo admitir que se programe por parejas?, es decir, ¿puede todo el mundo entender que en cada momento uno toque el teclado y el otro mire?, ¿se puede comprender que esta estrategia no tiene por qué afectar a la productividad?.
La programación en parejas tiene una serie de ventajas:
Las decisiones en la codificación no son algo unilateral de la persona que programa el componente (los arquitectos o analistas orgánicos no pueden llegar a todo el detalle de la programación, ya que ellos determinan el armazón de la aplicación que librerías utilizar, su división en capas, etc…, es decir, establecen el marco general).
El código es revisado en tiempo real, disminuyendo la probabilidad de error e incrementando la calidad del código.
Pero no es solo lo anterior, ¿puede ser admisible que se retoque software que ya funciona con el objeto de mejorar su calidad (simplicidad)?, ¿se puede vivir en un proyecto donde los requisitos están siempre en el aire?, ¿es sostenible un proyecto orientado a entregas continuas cada poco tiempo donde el cumplimiento de los plazos resulta de gran importancia?.
Sobre esto último algunos de los críticos con la metodología consideran que el equipo de trabajo está vendido a las entregas y que al haber muchas y frecuentes, los errores en la planificación provocarán numerosos picos de trabajo con el consiguiente overtime para los distintos integrantes del equipo de proyecto.
Sin embargo los defensores sostienen que el mismo Kent Beck considera que es necesario evitar el cansancio de los componentes del equipo de proyecto, debiéndose respetar su jornada laboral, situándose esta en cuarenta horas semanales. De hecho considera que no se debe haber overtime dos semanas consecutivas. Aplica por tanto el principio de responsabilidad en el sentido de que hay que tener disciplina con las entregas pero que eso no puede estar por encima de un continuo sobreesfuerzo de los integrantes del equipo de trabajo. ¿Por qué defiende esto? Pues porque los programadores cansados escriben código de peor calidad y además son menos productivos.
– Respeto: Algo complicado de encontrar en los proyectos de desarrollo de software y en un mundo tan ombliguista como es este. Se basa en el hecho de que todos los participantes en el equipo de proyecto suman y que es importante que se tenga en cuenta que para que todo vaya bien, todos tienen que dar lo mejor de sí y para que esto se pueda producir hay que crear un ambiente que lo propicie. Las críticas deben ser constructivas, siempre para mejorar, siempre para ir hacia adelante. Es importante que se tenga en cuenta que para que el barco vaya hacia adelante todos tienen que remar y que si se hunde se hunden todos.
Por otro lado cada participante debe asumir su responsabilidad, cada cual tiene su rol y debe entender que tras él hay una serie de tareas que se tienen que realizar, gustén más o gusten menos.
En el siguiente artículo sobre este tema se tratará sobre el ciclo de vida/metodología de la programación extrema.
Jummp 