El sentido común del desarrollo de software nos dice que mientras má s tarde se introduzcan cambios en un sistema,éste se volv erá má s caro y complicado. Eventualmente ser má s atractiva la idea de escribir un nuevo sistema en vez de añadir nueva funcionalidad al ya existente. Por lo tanto, deberá llevar a cabo un aná lisis completo para averiguar las necesidades posibles (presentes y futuras) y crear un diseñ o que sea lo suficientemente flexible como para poder incorporarlas. Debido a la velocidad actual de cambios tecnoló gicos y de mercado, tal tarea parece má s apta para un adivino antes que para un ingeniero de software.
Kent Beck nos invita a un mundo distinto: un mundo en el cual a ñadir funcionalidad en la mitad o al final del proceso de desarrollo es solo ligeramente má s caro que hacerlo al principio. Antes de iniciar un debate complicado sobre este proceso de soñ ar despierto, consideremos por un momento cuá les serí an las consecuencias de tal utopí a. Inicialmente, pondría atención en solamente los requerimientos actuales y luego diseñaría una solució n que satisfagaúnicamente dichas necesidades. De esta manera, se detendrí a por fin el proceso de adivinanzas. La solució n producida serí a tan simple como sea posible y como usted sabe, la simplicidad en el diseñ o es la clave deléxito. Entonces, escribirí a el có digo que cumpla con los requerimientos actuales y no incluiría ni una lí nea adicional. Los programas cortos son má s fáciles de comprender, contienen menos errores y en general mejoran la productividad del programador. Finalmente, el cliente recibiría en el menor tiempo posible exactamente lo requerido, que es generalmente exactamente aquello por lo que habí a pagado. Suena grandioso, no?
Los beneficios son tan increí bles que Jim Highsmith dice que, aun cuando la propuesta de Ken Beck no fuera cierta, deberí amos desarrollar sistemas de tal manera que sea verdadera. Pero esto aparentemente es imposible de lograr, ya que hemos notado có - mo un sistema inicialmente simple se vuelve cada vez más complicado mientras se añ aden características, a la vez que el diseñ o se vuelve malo y aumentar la funcionalidad se complica paulatinamente, se vuelve riesgosa, y realmente poco agradable. Cómo podemos evitar este proceso? Martí n Fowler define el "refactoring" como el proceso de cambiar un sistema de software de tal manera que no se altere el comportamiento externo del có digo pero se mejore su estructura interna. Mejor aú n, Fowler no se queda en la propuesta sino que provee consejos detallados en un ejemplo en "Refactoring", que es otro libro de lectura obligada de desarrollo de software. Recuerde la idea consiste en cambiar có digo que ya funciona para convertirlo a má s adaptable a cambios que se presenten en el futuro, y no para que corra más rápidamente ni para ahorrar en su consumo de memoria.
Pero tal vez ahora se sienta desconfiado, ya que todos conocemos lo que ocurre cuando se cambia có digo que funciona: el sistema comienza a fallar en sitios poco esperados y de manera poco esperada. Falla a menos que haya estado programando mediante el mé todo de programació n con pruebas iniciales. Esta té cnica propone que cuando a un programador se le asigna un proyecto, deber desarrollar una serie de pruebas para comprobar si su solució n resuelve el problema. Luego escribe un pequeñ o programa o rutina para correr las pruebas de manera automatizada. Solamente despué s de haber hecho todo esto, el programador comenzará el trabajo de escribir el có digo verdadero de la solució n. Cierto que esto requiere má s disciplina y trabajo que solamente codificar, pero los beneficios son muchos: cuando se crean las pruebas, uno puede pensar tambié n en la solució n, verificar si se han satisfechos los requerimientos y finalmente, cuando se hace "refactoring" uno puede estar seguro de que no se ha "roto" el funcionamiento. El "refactoring" y la programación con pruebas iniciales son ejemplos claros de té cnicas de desarrollo complementarias y son parte de las doce prácticas de la Programación Extrema, o XP según sus siglas, una metodología de desarrollo que promueve un enfoque de regresar a los conceptos básicos.
El XP confronta directamente las metodologías monumentales, también conocidas como metodologí as Gran M, ya que propone un conjunto mí nimo de prácticas dirigidas a impactar directamente en la productividad de los programadores y la calidad de su trabajo en vez de controlar todo el proyecto por medio de documentación e hitos. En el capítulo 10 de "Extreme Programming Explained" (Programación Extrema Explicada), Kent Beck resume las doce prá cticas:
1. El Juego de la Planificació n: determine rá pidamente el alcance de la pró xima versió n al combinar las prioridades de negocio con los estimados té cnicos. Cuando la realidad supere al plan, actualí celo.
2. Pequeñas versiones: ponga en producción a un sistema simple rápidamente, luego lance al mercado nuevas versiones durante un ciclo corto.
3. Metá fora. Guíe todo el desarrollo con una historia simple de cómo funciona todo el sistema.
4. Diseñ o simple: el sistema deber diseñ arse de tal manera que sea lo má s simple posible en cualquier momento dado. La complejidad adicional se retirar tan pronto sea descubierta.
5. Pruebas: los programadores continuamente escribirá n pruebas de unidad, que deben correr sin problemas para que el proceso de desarrollo pueda continuar. Los clientes escribirá n pruebas demostrando que se ha completado la implementació n de las caracterí sticas.
6. "Refactoring": los programadores cambiará n la estructura del sistema sin cambiar su comportamiento para eliminar la duplicación, mejorar la comunicación, simplificar, y añ adir flexibilidad.
7. Programación por pares: todo el código de producción será escrito por dos programadores que compartirá n una sola má quina.
8. Propiedad colectiva: cualquiera puede cambiar có digo de cualquier parte del sistema en cualquier momento.
9. Integració n continua: se integra rá y creará las nuevas versiones del sistema muchas veces por dí a, siempre que se haya completado una tarea.
10. Semanas de 40 horas: solamente se trabajará 40 horas por semana, como regla. Nunca se trabajará horas extras dos semanas seguidas.
11. Cliente en el sitio: incluya un verdadero usuario como parte del equipo, que esté disponible a tiempo completo para contestar las preguntas.
12. Está ndares de codificació n: todos los programadores deberá n escribir có digo que cumplan las reglas y se enfatizar la comunicació n durante su creació n. Algunas de las prá cticas indicadas son de sentido comú n: cliente disponible en el lugar, está ndares de codificació n. En cambio, otras son técnicas redescubiertas: ejecució n de pruebas y simplificació n en el diseño, "refactoring" y el juego de la planificació n. Otras prácticas pueden ser controversiales: programació n por pares, y propiedad colectiva. Beck presenta razones para alentar la aplicació n de estas prá cticas e incluye detalles explí citos sobre có mo emplearlas. El resultado general de la metodologí a: haga lo mí nimo que puede llegar a funcionar, obtenga toda la retroalimentació n que pueda, cambie calendarios y haga "refactoring" libremente. No hay un plan a largo plazo o un horario fijo y se prefiere la comunicació n personal a la escrita. Desde el punto de vista de las metodologí as monumentales, este comportamiento es perezoso (sino se lo puede considerar "malo"). De todas maneras, lo importante es: Se consiguen los resultados esperados de esta manera?
Hace cerca de diez añ os, Alistair Cockburn fue contratado por IBM para que cree una metodologí a para el desarrollo orientado a objetos. Parte de su enfoque fue entrevistar al mayor nú mero posible de miembros de equipos de proyectos, anotando todo lo que decí an contribuí a a suéxito o fracaso. Según sus palabras:
"En el estudio de IBM, todo equipo exitoso "se disculpaba" por no seguir un proceso formal, por no usar una herramienta tipo CASE de alta tecnología, por simplemente mantenerse cerca y analizar cualquier cosa que surgí a. Mientras tanto, una buena cantidad de equipos con problemas no lograban encontrar el motivo de sus fallas a pesar de seguir un proceso formal, tal vez se olvidaron de algú n paso? Finalmente comencé a conocer equipos que se daban cuenta que suéxito se había dado justamente por no seguir procesos elegantes con entregas formales, pero que más bien discutí an con libertad y entregaban software, luego de realizar varias pruebas."
Estos resultados han sido consistentes, desde 1991 a 1999, desde Hong Kong al continente Americano, en Noruega, y en Sud frica, tanto para sistemas en COBOL como Smalltalk, Java, Visual Basic, Sapiens y Synon. Para resumir los resultados podemos decir:
Siempre que pueda reemplazar la documentación escrita con comunicación oral, hágalo. As reducir la dependencia en productos escritos y mejorará la probabilidad de llegar a entregar el sistema.
Mientras má s frecuentemente pueda entregar pedazos del sistema que corran y hayan sido probados, depender menos de "promesas" y podrá entregar el sistema. Las personas son entes que se comunican. Incluso los programadores más introvertidos, funcionan mejor en un ambiente en donde haya comunicación informal llevada a cabo cara a cara que en aquel donde exista solamente comunicaciones escritas. Desde un punto de vista de costos y horarios, el escribir algo toma más tiempo y comunica menos que una discusión con ejemplos en la pizarra blanca.
Aparentemente, comportamientos similares a aquellos propuestos por XP han resultado exitosos en muchos lugares y en muchas pocas. Se acuerda de lo que discutimos sobre agentes en un ambiente no predecible? Mencionamos que los agentes definen sus reglas de comportamiento y los van refinando para poder llevar a cabo su trabajo adecuadamente en su nicho. Aquí podemos observar cómo cada equipo de desarrollo ha descubierto de manera independiente el mismo conjunto básico de reglas que les permite auto-organizarse y del cual surge un orden, en vez de que se imponga desde arriba autoritariamente. Si seguimos la teoría de CAS, deberíamos tratar de incluir estas reglas en nuestros equipos de desarrollo, para poder mejorar sus probabilidades de éxito.
