Me da gusto volver a saber de ti y de tus “diferencias” :)

Vamos punto por punto. En cuanto al desarrollo profesional y el tipo de roles de los desarrolladores experimentados, creo que has tomado mis palabras un poco demasiado al pie de la letra y las has hecho decir cosas que no he querido decir. Me explico:

No es que en XP tomemos a los mejores programadores y los dejemos siempre programando, en espera de que se conviertan en unos apéndices de sus computadoras o que les aparezcan puertos USB en algún lado.

De hecho, los desarrolladores más experimentados tienen varias tareas específicas en XP, la primera, es monitorear y trabajar en pareja con los más inexpertos para entrenarlos, liderar los talleres de arquitectura y participar muy activamente en las reuniones con los clientes para guiar el descubrimiento del dominio y de los procesos.

En cuanto al UML, mi posición es la misma que la de Martin Fowler, creo que el UML es una herramienta de comunicación entre humanos. La uso para expresar mis ideas en los talleres de arquitectura o para indicar a un colega una idea o una pregunta, pero no uso herramientas de dibujo de UML a no ser que el cliente pida los diagramas. Sin embargo, mantengo la idea de que en el equipo todos deben dominar al menos los diagramas de estructura y los diagramas de secuencia para poder comunicarse fácilmente con los demás. Creo que el dominio del lenguaje UML y de los patrones más utilizados es importante para comunicarnos en el equipo, más que para poder realmente programar.

Por ejemplo, si sugiero el uso de un “Unit of Work” en cierto sistema, sé que no tengo que explicar exactamente qué quiero que haga el sistema, los demás saben a qué me refiero porque conocen el patrón. Lo mismo con UML, no me la paso explicando qué quieren decir las flechitas, porque sé que mis colegas dominan lo necesario del UML para poder entendernos.

En resumen, creo que los desarrolladores más experimentados, en efecto terminan más en reuniones con los clientes para descubrir dominio y requerimientos, así como liderando talleres de arquitectura (donde dibujan UML) pero también participan directamente en el desarrollo y en la formación de los más jóvenes. ¡Nuevamente, parece que nuestras diferencias no lo son tanto!

El punto dos, en donde te refieres al Outsourcing o la compra y adquisición de software o sistemas externos. En efecto tienes razón, en XP no tenemos manera de manejar estas adquisiciones, pero como bien sugieres, existen metodologías y estrategias para realizar estos procesos:

Es cierto que la metodología XP no tiene un proceso para la adquisición de software o código externo, pues es una metodología de desarrollo y no una metodología de apoyo gerencial como lo es RUP/UP, sin embargo, en este tipo de procesos, podemos fácilmente tomar mano de Scrum o de la misma RUP para llevar a cabo el proceso de adquisición de manera controlada. Ya lo he dicho antes, soy un promotor de la XP, no un enemigo del RUP/UP.

La conclusión aquí sería que en efecto la XP no maneja adquisiciones externas, pero que es compatible con metodologías de apoyo gerencial que si tienen estos procesos descritos, como Scrum y RUP/UP.

Tu último punto que has dejado sin número es sobre la prioridad de la evaluación del sistema contra la implementación de funcionalidad sin pruebas. En efecto, me has entendido bien. Los puntos de control, el tener la funcionalidad realmente funcional, el tener las pruebas y las evaluaciones con focos verdes es más importante que la funcionalidad incompleta o la codificación a medias. Así mismo, las fechas de fin de iteración no debieran ser negociables, para mantener el control del proceso de desarrollo y mejorar la estimabilidad del proyecto completo.

Un gusto, como siempre, saludar a un miembro de la trinchera vecina del RUP/UP.

Este artículo tuyo no lo había leído hasta hoy, cuando lo he encontrado en una madrugada con insomnio. Me alegra sin embargo la noche, fue un lectura en verdad interesante.

Ya hemos conversado sobre estas cosas antes, pero si me permites decirte las ideas de hoy, tengo dos puntos para poner en la mesa:

1. Los programadores de XP deben ser experimentados… y hasta ahora no me había dado cuenta de un detalle que se desprende de la visión RUP/UP del mundo: los profesionales comienzan programando pero al crecer y adquirir experiencia dejan de hacerlo.

Entonces, en la banca ágil se pone a la gente más capacitada a escribir código mientras que nosotros colocamos a esta misma gente en otras cosas, como crear diagramas UML o tratar con el cliente.

Tenemos entonces, diferencias de enfoque en la evolución del profesional.

2. RUP/UP nos da un marco para enfrentar otro tipo de proyectos: la adquisición de software por ejemplo, no tiene un componente de código nuevo significativo, ¿es aplicable XP a este tipo de proyecto? Pienso que no. En tal caso que enfoque se sugiere que sea compatible con XP?

Cuando lo que queremos es instalar y configurar un software obtenido de un proveedor, desarrollar la visión y contar con un diagrama de despliegue siguen siendo útiles pero el refactoring y la programación en parejas no tienen cabida.

RUP en su versión 7.0 introduce la idea de un marco común de prácticas y capacidades, a partir del cual se pueden configurar procesos específicos, donde el desarrollo de software es solo uno de los posibles. ¿Ya lo habíamos comentado cierto? Recuerda que tengo insomnio, cualquier redundancia me la has de perdonar.

Te comento por ultimo sobre un extracto de tu artículo:

“Si una funcionalidad no puede terminarse en una iteración, se terminará la iteración sin ella, es más importante terminar la iteración con un sistema funcional y sin errores o detalles incompletos que un sistema que no puede ser evaluado.”

Si lo interpreto bien, dices que la capacidad de evaluar el software es incluso más importante que el de tener la funcionalidad completa, es decir: es necesario cumplir con el punto de control. Retrasar este unos días para terminar con una sección del código no es lo correcto.

Si lo he interpretado bien, entonces no puedo estar más de acuerdo.

Estamos hablando.