Barrapunto

No he tenido la oportunidad de poner en práctica en un proyecto real la programación extrema, sin embargo sí que la he aplicado de forma parcial.

La programación extrema [wikipedia.org] la idearon Kent Beck, Ward Cunningham, y Ron Jeffries. Aunque también Martin Fowler [martinfowler.com] ha hecho divulgación de esta metodología. Algunas prácticas que incluye la programación extrema son el refactoring [refactoring.com] y el test-driven development [wikipedia.org].

Una idea interesante de la programación extrema es que no tiene porqué adoptarse totalmente las metodologías extremas, si no que pueden ir adoptándose según interese. En este aspecto sí que he aplicado la programación extrema, usando ampliamente tests, usando moderadamente la programación a pares, ¿quién no hace refactoring?, etc.

Algunas de las prácticas que propone son criticables, se podrían mejorar, o pueden tener efectos negativos si se aplican de una determinada forma, pero también puedo decir que algunos aspectos como los test de unidad y el refactoring han sido indiscutiblemente positivos.

Saludos.

Por ejemplo en lo de programación por parejas.
Si el ahorro en tiempos en del 20% lo que antes costaba hacer 100 horas ahora costará 80, pero tendra un coste económico de 160, porque hay que pagar a dos programadores. Eso no hay empresa que lo soporte.
Lo que si se puede hacer es trabajar uno al lado del otro y cuando uno se atasque preguntar. a mi me ha pasado un millón de veces, se acerca el compañero y dice 'quita ese punto y coma' o algo similar. Y se ahorra mucho porque la mayoría de veces siempre es un fallo obvio que nos obcecamos en no ver.

En general la XP me gusta. Pero como con todo no hay que ser integrista.

"Eso de la programación extrema es una rebelión de los programadores, que se han montado una paja mental para defender sus intereses por encima de los del proyecto haciéndole creer al empresario y al cliente que si el equipo de desarrollo se pasa media semana haciendo el idiota las cosas van a ir mejor.
¿Qué mierda es esa de que un programador no puede hacer horas extras? ¿Cómo se atreven a decirme que un tío tecleando y otro mirando no significa un 50% de la mano de obra tocándose los cojones? ¿Es que no se pierde bastante tiempo en reuniones ya como para ahora ir haciéndolas todos los putos días? ¿Qué clase de metodología es esa que va esquivando la planificación? ¿Qué jeta es esa de cubrir los requerimientos estipulados y nada más? ¿Eso es calidad? ¿Desde cuando los obreros controlan su forma de trabajar?
Implantaré una metodología como esa cuando se decrete la Navidad permanente."

Sin ánimo de trollear, creo honestamente que, desde la perspectiva de un empresario conservador, la valoración que os comento es bastante dura de rebatir. Estoy seguro de que muchos directivos no van a permitir que la XP salga adelante: no les suena nada bien. Parece una metodología poco seria. Son postulados que no pueden defenderse fácilmente ante un Consejo de Administración.

Vamos, que mis jefes no ven porqué los métodos de la XP les vayan a aportar ventajas competitivas. Les parece una cuestión sindical. Así de claro.
Y todo es porque la XP mezcla técnicas de trabajo con condiciones laborales en un mismo discurso. Y esa no es la forma de dirigirse a un Project Manager. Al menos no en España.

¿Alguien sabe de una empresa grande con oficinas en este país que emplee XP en sus proyectos pequeños?
Yo no.

pero para que funcione, desde el principio hay que tener en cuenta unas cuantas cosas para que el asunto no se desmadre:

1) Los proyectos necesitan de un contrato firmado antes de empezar, con requisitos que permitan verificar que el proyecto está acabado (y listo para cobrar la pasta). Es necesario que el cliente sepa, desde el primer momento, fijar ese marco de referencia: si no los proyectos con XP no acaban nunca, empiezan siendo un huevo y acaban siendo una castaña.

2) La formalización de los requisitos se hace vía User Stories. El cliente debe comprometerse, una vez acordada cada una, a no andarla cambiando de nuevo: una cosa son requisitos flexibles y otra cambiar de idea cada día.

3) Dado que no se usa una documentación de diseño medianamente formal, requiere que el grupo de trabajo sea capaz de transmitir ese conocimiento de forma oral. Es decir: no más de 10 personas y todos trabajando juntos. Pero hay muchos proyectos que requieren la colaboración de diferentes empresas, con lo que unos están trabajando aquí y otros en la conchinchina. En estos casos ojo con XP que acabará en un cristo.

4) Pruebas unitarias... Xp se suele usar para trabajar rápido, y cuando se va rápido se tiende a pasarse por el forro las pruebas unitarias. Sin pruebas unitarias el refactoring acaba irremisiblemente en un cristo. Y sin refactoring no hay XP: hay code & fix, que resulta en la KK a que estamos acostumbrados en este mundillo.

Así que... XP si, pero sabiendo lo que te traes entre manos. Si no, acaba en un cristo del 15. Vaya, como con todas las metodologías: si al final lo que hacen falta son buenos programadores, que la metodología buena para cada proyecto la acaban definiendo ellos.

Para andar por casa, pues lo que hacemos todos.

Sí, yo me siento a programar a menudo con el gato ayudándome. Luego cuando teclea él, le corrijo yo. Mientras, mi canario y mi perro van preparando los módulos de pruebas. Lo único que no puedo cumplir libremente es con la rotación de los grupos, porque no puedo poner al gato con el canario ni al perro con el gato, por lo demás está claro que es lo que hacemos todos para andar por casa...