Desarrollo de Software

Introducción a la Programación Extrema (XP)

La programación extrema o XP es una metodología de desarrollo que se englobaría dentro de las denominadas metodologías Ágiles en la que se da máxima prioridad a la obtención de resultados y reduce la burocracia que se produce al utilizar otras ‘metodologías pesadas’.

Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.

Kent Beck.

El autor de la XP es Kent Beck, entre otros, que con su larga experiencia como programador eligió las mejores características de las metodologías y profundizó en las relaciones de éstas y como se reforzaban unas a otras. Por tanto, la XP no se basa en principios nuevos, sino que todas, o casi todas, sus características ya se conocen dentro de la ingeniería del software, las cuales se complementan para minimizar los tópicos problemas que pueden surgir en todo desarrollo de proyectos software.

Programación Extrema

Objetivos de la programación extrema

El objetivo principal de la XP es la satisfacción del cliente. Se le trata de dar al cliente lo que quiere y cuando quiere. Por tanto, se debe responder rápidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto. Como metodología Ágil que es, se pueden producir modificaciones de los requisitos del proyecto a lo largo de su desarrollo, sin que esto produzca un buen dolor de cabeza.

Otro de los objetivos es el trabajo en grupo. Tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo.

Valores de la programación extrema

Para garantizar el éxito de un proyecto, los autores de XP han considerado como fundamentales cuatro valores:

  • Comunicación. Muy importante. La XP ayuda mediante sus prácticas a la comunicación entre los integrantes del grupo de trabajo: jefes de proyecto, clientes y desarrolladores.
  • Sencillez. Los programas deben ser los más sencillos posibles y tener la funcionalidad necesaria que se indican en los requisitos. No hay que añadir algo que no se necesite hoy. Si se necesita añadir más funcionalidad mañana pues ya se hará entonces.
  • Retroalimentación. Las pruebas que se le realizan al software nos mantiene informados del grado de fiabilidad del sistema.
  • Valentía. Asumir retos, ser valientes ante los problemas y afrontarlos. El intentar mejorar algo que ya funciona. Aunque gracias a las pruebas unitarias no existe el riesgo de ‘meter la pata’.

Algunas voces, añaden además un quinto valor: la humildad. Con la compartición de código, la refactorización y el trabajo de equipo tan estrecho una buena dosis de humildad siempre es de agradecer.

Prácticas de la programación extrema

12 son las prácticas de la XP:

  • El juego de la planificación (the planning game). Es un permanente diálogo entre las partes empresarial (deseable) y técnica (posible).
  • Pequeñas entregas (small releases). Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media característica y lanzar la versión.
    Es mucho mejor planificar para 1 mes o 2 que para seis meses y un año, las compañías que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia.
  • Metáfora (metaphor). Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas «Programa de gestión de compras, ventas, con gestión de cartera y almacén». Las metáforas ayudan a cualquier persona a entender el objeto del programa.
  • Diseño sencillo (simple design). Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuando el sistema te lo pida.
  • Pruebas (testing). No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.
  • Refactorización (refactoring). Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas caracterí­sticas. No debemos de recodificar ante especulaciones si no solo cuando el sistema te lo pida.
  • Programación por parejas (pair programming). Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa mas estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no funcione?, ¿Hay forma de simplificar el sistema global para que el problema desaparezca?
    El emparejamiento es dinámico, puedo estar emparejado por la mañana con una persona y por la tarde con otra, si tienes un trabajo sobre un área que no conoces muy bien puedes emparejarte con otra persona que si conozca ese área. Cualquier miembro del equipo se puede emparejar con cualquiera.
  • Propiedad colectiva (collective ownership). Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. Si hacemos el código propietario, y necesitamos de su autor para
    que lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema, si necesitamos un cambio sobre una parte del código lo hacemos y punto. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.
  • Integración continua (continuos integration). El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%.
  • 40 horas semanales (40-hour week). Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar en algo distinto y volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrada a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.
  • Cliente en casa (on-site costumer). Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo.
  • Estándares de codificación (coding standards). Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.

Algunas de estas prácticas reciben muchas críticas, sobre todo la programación por parejas. Muchos jefes de proyecto no aceptan que dos desarrolladores tengan un único ordenador, ya que creen que esto minimizará la productividad, sin saber que de este modo puede producirse el mismo código que dos personas trabajando en solitario pero con un código de mayor calidad.

Se dice que si no se realizan estas doce prácticas no se está realizando XP. Yo, a mi modo de verlo, creo que nosotros no tenemos que adaptarnos a ninguna metodología, sino que ellas se tienen que adaptar a nosotros dependiendo del tipo de proyecto que estemos desarrollando.

Bueno, esta ha sido una ‘breve’ introducción a la programación extrema. Seguro que algunas de las prácticas que se han visto anteriormente la has utilizado. Como dije al principio, la XP es más una filosofía de trabajo que recoge lo mejor de las distintas metodologías y las junta para que se refuercen unas a otras.

11 comentarios en “Introducción a la Programación Extrema (XP)

    • Hola Miguel, gracias por pasarte por aquí.

      Es complicado determinar la fecha concreta en que comienza una metodología, pues como indico en el post es una unión de características de diversas metodologías. Pero te pongo un par de fechas para localizarlo:

      El primer proyecto con XP se realizó el 6 de marzo de 1996 (http://www.extremeprogramming.org/).

      En 1999, Kent Beck escribió el libro «Extreme Programming Explained: Embrace Change», primer libro en el que se expone esta metodología.

      Un saludo.

  1. Quería saber como es que se divide el trabajo, entiendo que al tener las historias de usuarios, estas se priorizan, y se dividen en tareas, las cuales tambien se definen su duración. Ahora esta es la parte que no la tengo clara: Defino mi Entregable, el cual pueden ser varios entregables hasta que implemente mis historias de usuario. Pero dentro de estos Entregables van mis iteraciones, y dentro de estas iteraciones van mis tareas que parten de las historias, es correcto esto ?

    Gracias y saludos

  2. Pingback The Art of Agile Development « ::everac99

  3. Pingback S5_Actividad 1. Selección y recopilación de información – José Martín

Pon un comentario

Tu dirección de email no será publicada.

Puedes usar estas etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>