Software y la teoría del caos, un enfoque despreocupado - Programación extrema y centros de desarrollo virtual

Para nosotros, es especialmente relevante analizar có mo se puede aplicar XP a los CDV(Centros de Desarrollo Virtual) que son aquellos equipos que está n geográ ficamente separados y que pueden llegar a tener varias docenas de desarrolladores. Kent Beck señ ala que XP asume que los grupos son pequeñ os (de 20 personas má ximo) que trabajan en el mismo lugar, por lo que resulta interesante preguntarnos qué ocurre con grandes proyectos y con grupos que trabajan en diferentes lugares. Analicemos primero el problema del tamañ o de grupo. A pesar de que XP recomienda usar todas sus prá cticas, si es posible usar solamente un subconjunto deéstas. Ademá s se puede modificarlas un poco para obtener todos los beneficios del XP puro. En la Conferencia "JavaOne 2001", Michael Lauer presentó una conferencia sobre el uso de XP para grandes proyectos de J2EE. Describió los detalles de un proyecto exitoso que excedí a considerablemente el tamañ o recomendado por Beck. En resumen, Lauer propuso lo siguiente:

1. Contar con un diseño serio desde el inicio en vez de concentrarse en la metá fora propuesta por XP.

---

2. Contar con un grupo principal de arquitectos senior para desarrollar una serie de patrones de arquitectura de componentes, por ejemplo patrones de persistencia de objetos o patrones en cuanto a la interfaz de usuario MVC. Se entregará n estos patrones a los desarrolladores.

---

3. Usar un subconjunto de prácticas de XP. Algunas de las excluidas fueron: programació n por pares obligatoria, la semana de 40 horas (qué pena !) y, lo más sorprendente, el cliente disponible en el mismo local.
Lauer afirma que de esta manera logró :

1. Mantener contentos a los gerentes, ya que un arquitecto administraba de 20 a 40 desarrolladores. 2. Disminuir los costos de entrenamiento (aun cuando solo 1 o 2 de cada 10 solicitantes tení an el perfil correcto para el proyecto).

---

3. Acortar los ciclos de desarrollo.

---

4. Crear software m s robusto.

---

5. Capacitació n continua

---

6. Eliminació n del mito del mes-hombre, logrando un gran grado de paralelismo en el desarrollo.
Y por supuesto, Lauer y sus clientes estaban contentos y sentí an que habí an logrado algo importante. Entonces, parece que el factor del tamañ o de equipo podrí a eliminarse si se varí a en cierto grado a XP.

---

Cuando se analiza la dispersió n geográ fica del equipo, tenemos que recordar que lo que requiere XP es que exista comunicació n fluida de persona a persona. Debido a las mejoras continuas de las telecomunicaciones y las herramientas de Internet que van desde las má s simples ("chat") a las má s sofisticadas (reuniones virtuales), estar presentes electró nicamente en el mismo ambiente es casi igual a estar fí sicamente en el mismo cuarto. La experiencia se está mejorando cada vez má s. Sin embargo, el hecho de estar en diferentes husos horarios sí podr a afectar la comunicació n, sin importar que tan buena sea la infraestructura de comunicaciones.

---

Kent Beck trata de delimitar claramente d nde funciona y en qué condiciones no funciona XP. Por ejemplo, funciona muy bien cuando se trata de equipos localizados en un sitio y el proyecto a desarrollarse no es un sistema de misión crí tica. Y que pasa si su proyecto cumple con todas las especificaciones? Serí a interesante poder iniciar el trabajo con el modelo XP (o algo equivalente) y luego adaptarlo durante la ejecució n para que satisfaga las demandas del proyecto. Pero parece difí cil cambiar la metodologí a de desarrollo en medio del proyecto. Usando terminologí a de la metodologí a CAS, lo que necesitamos es no solo descubrir y emular el comportamiento de los agentes exitosos pero tambié n conocer los procesos que usan los agentes para intentar encontrar y adoptar nuevas reglas. Si logramos esto y podemos emular dichos procesos, podremos crear equipos que no solo creen buen software sino que tambié n adapten los procedimientos a su ambiente especí fico. De esta manera su rendimiento mejorará cada vez má s yésta es justo la idea detrá s de la metodologí a de Desarrollo de Software Adaptable (o ASD segú n sus siglas en inglé s) que es nuestro siguiente tema.