El colegio era un gran edificio amarillento con los cristales opacos. [...] El primer día tuve una entrevista con el padre rector [...]. Allí en su despacho me contó una larga historia de ovejitas que vagabundeaban sin el menor control y sobre qué hermoso era en cambio estar todos unidos en rebaño y qué sabio es el uso del bastón.
Susana Tamaro -- Para una voz sola
Siempre he sido escéptico frente a las metodologías, las reglas o cualquier tipo de especificación de cómo deben hacerse las cosas. No existen soluciones fáciles en la vida, y cada uno debe encontrar su propio camino y su forma de resolver sus problemas. Por eso, la ingeniería de software me ha sido siempre sospechosa, con tendencias a un formalismo extremo y bastante contraria a los estilos de los buenos programadores y desarrolladores de software.
Hacer especificaciones detalladas, fijar la funcionalidad y el diseño durante largos meses, hasta terminar con un producto de demostración en que los usuarios cambian todas sus visiones e ideas, debiendo reformular el sistema, sumado a los cambios tecnológicos que nos implican más cambios aun, no parece la mejor forma de enfrentar estos sistemas.
Sin embargo, cayó en mis manos el libro de programación extrema (Extreme Programming Explained (Embrace Change), de Kent Beck) durante el verano y me pareció realmente motivante para utilizarlo. Las ideas son muy simples y básicas, por lo que muchas de ellas ya las hemos utilizado en distintas versiones. Lo que lo hace distinto es la idea de usarlas todas juntas, de forma de solventar las debilidades de una con las fortalezas de otras. En resumen, la base es evitar los grandes diseños detallados y largos reemplazándolos por implementaciones rápidas de lo que hoy se requiere pero en un ambiente donde los costos de agregar cambios a futuro sea muy bajo.
Lo que me atrae de la idea en general es que se adapta muy bien a grupos pequeños de programadores (unos diez), evita las jerarquías divisorias (analista, programador, etc) y requiere gran capacidad de improvisación y adaptabilidad de parte de los programadores. ¿Qué mejor para un chileno?
Acá somos todos maestros chasquillas, preguntones, metetes y resistentes a las jerarquías. Por otro lado, tenemos dificultad para planificar a largo plazo, por lo que la metodología parece hecha para nosotros.
La idea más rara que propone es lo que llaman Pair Programming (programación en pareja) que consiste en programar de a dos pero con un solo teclado. Mientras uno escribe el código, el otro mira por sobre el hombro, pensando en general (¿he visto este código en otra parte? ¿se podría hacer de otra forma? ¿cómo se integra con el resto del sistema?). Yo he jugado antes a hacer cosas así y he notado que funciona extremadamente bien.
Esto permite que todo el grupo vaya entendiendo todo el código y que no exista propiedad sobre partes de él. El concepto de la documentación es que el código es la documentación y debe ser escrito como tal.
La propiedad compartida del sistema me parece vital como idea base. Eso permite la flexibilidad en los roles, de modo que todos diseñan, programan y conocen el sistema completo.
La teoría es que todo esto permite ir modificando el sistema en producción en forma simple y permanente, un especie de programación permanente, que es la realidad práctica de la mayoría de los sistemas en explotación.
Les recomiendo la lectura del libro. Por mi parte, me voy a dedicar a probarlo.