Extreme Programming revisitado

Timothy Fisher publica en su blog soportado por Sys-Con, un artículo comentando pros y contras de XP. Probablemente, como dice el artículo, dando una visión imparcial del alcance y valía de su práctica. Recuerdo haberme interesado en XP hace alrededor de cuatro años, inicialmente con entusiasmo por algunos de sus principios, y luego con mayor moderación en cuanto conocía más el conjunto de reglas que recomendara, y en tanto conocía mejor las opiniones y actitudes de sus mentores. Con el tiempo, tomé el camino de adoptarlo como un conjunto de prácticas, algunas de las cuales me parecen excelentes, y otras que dejo para sus integristas, que parece que los tiene. Adhiero casi por completo al balance de Timothy, y quizá le pusiera el acento a algún otro elemento, especialmente a su visión de los proyectos como "historias sin fin", y a su desapego al modelado del proyecto (dos puntos vinculados sin duda).
Los "pros"de Timothy:

Testeo

Unit testing has certainly been around for many, many years, but it's certainly not unreasonable to say that we owe a great deal of today's increased emphasis on unit testing to XP. Unit testing was promoted as one of XP's core practices. Along with the recognition of unit testing as a powerful aid to developers came the methodology of test-driven development. This is a development style in which unit tests are always written prior to the code which they are testing.

Plan de trabajo

What XP refers to as the "planning game", is another good practice that can be carried over into other methodologies. XP does a very good job in maintaining schedules, plans, and keeping the plan very current. The iteration and build strategies advocated by XP are very good strategies for any project. Amongst these strategies, XP advocates frequent releases, short and well defined development iterations, frequent builds, and emphasis on build automation. Whether you choose to practice XP or not, these are strategies that add value to any methodology.

En este caso, el plan es referido al corto plazo. En este terreno, XP es muy interesante, y quisiera aplicar tanto como pudiera especialmente el objetivo de releases cortos: Ciclo corto de desarrollo tanto como se pueda.

...
Otros aspectos en pro no son mencionados, sino brevemente agrupados en el punto anterior. Quisiera agregar un "pro" apenas indicado al comienzo de su artículo: la propiedad común, o quizá mejor comunitaria, del código. Seguramente no llevado al extremo de la rotación diaria en la escritura de código, pero la rotación en la construcción del código es un elemento fuerte para lograr un mejor dominio del producto en el que se trabaja. Todo lo contario a la práctica usual, donde cada participante de un proyecto suele estar especializado en una actividad. En realidad, Timothy critica como uno de los "cons" de XP este concepto:

XP also does not believe in the need for "experts". Their philosophy is that all programmers should be well balanced on all technologies employed by the application. While this sounds admirable as a goal, the reality of this is that you kill the enthusiasm of an expert, and encourage a mediocre understand of all technologies in all your programmers. It is simply not realistic for all programmers to become experts in all of a project's technologies. Individuals who want to gain expertise in a specific technology, such as security, GUI design, databases, etc. are discouraged.

Creo que aquí coexisten dos aspectos: uno, que también veo, es el poco acento puesto en el análisis global o de largo plazo, dando primordial importancia a la escritura de código. El otro aspecto es la rotación en la elaboración del trabajo: Es cierto que un especialista no debe ser reemplazado, y que su trabajo tiene su cualidad propia, pero, en primer lugar, rotar entre pares es posible y recomendable, para mejorar el conocimiento global del producto en construcción, al menos lo suficiente para que un área no dependa de una sola persona. Adicionalmente, la visión global cohesiona y posibilita incluso la mejora a través de la observación del par.

Los "cons" de Timothy (the not so good):

El cliente en el equipo

Another core practice of XP asks you to keep a customer representative onsite with your development team so that you are able to quickly work out requirements confusion, get answers to questions, and get feedback on your progress. This sounds great, but it’s the practice I usually refer to as the fantasy practice. We'd all love to have James Gosling onsite also in case we run into any Java problems, but it's simply not realistic, just as having an onsite customer is not realistic in most cases. When you are able to achieve this, absolutely go for it. It's a grand idea, but not one that a software development methodology should rely on as a core practice.

Hacer las cosas simples

XP also tends to be full of short catch phrases summarizing its core principles. One of those is "Do the Simplest thing Possible." Here they are advocating that you should always implement the simplest, least complicated solution to the task at hand. They specifically warn against coding for anticipated future extensibility and add-ons that may or may not actually happen. While in general, this may not be bad advice, I think making this a core principle of XP is going too far with this attitude. Often, it does make a great deal of sense to spend the time to implement something that, while not necessarily the simplest solution, is a smarter and better solution. Remember this; the simplest solution is not always the best solution. This tenet seems to be born out of programmers who are adverse to strategic design, analysis, and modeling and simply want to code.(El subrayado es mío)

Aquí adhiero en tanto la simplicidad tenga relación con la oposición a un desarrollo de visión estratégica. Por lo demás, la simplicidad es recomendable.

Programación de a pares:

En este punto adhiero por completo a su criterio, al que remito. Sólo le agrego una especialización "local". Quisiera saber cuántos equipos de trabajo de Latinoamérica podrían disponer equipos de pares para escribir código en una máquina...

El código es toda la documentación:

While not an official XP practice, it is a common belief in the XP community that source code alone can serve as the developer documentation for a project. This may be fine for the developers currently working on the project, but have you ever tried joining a project in progress with a large code base and being told that the only documentation for what they've created so far is the source code? Believe it or not, many XPers would say that is perfectly fine, and this is how they document their projects. Again here, we have a failure to consider the future and what is strategically best for the organization as a whole.

En resumen...

The best way to view XP is as a collection of principles which may be applied to your software development project individually or in sets. You should not be dogmatic in your views about XP and believe that it is an all or nothing methodology. I'd go a step further even and refer to XP as a methodology toolbox, rather than a methodology

De acuerdo, Timothy. La mejor actitud sería tener una cartilla de XP a mano, y releerlas para reconsiderar el trabajo de la próxima semana, pero como auxiliar de tu método predefinido de trabajo...