Con mucho, el desarrollo de software es una actividad ca�tica, frecuentemente caracterizada por la frase "codifica y corrige". El software se escribe con un plan subyacente m�nimo, y el dise�o del sistema se adoquina con muchas decisiones a corto plazo. Esto realmente funciona muy bien si el sistema es peque�o, pero conforme el sistema crece llega a ser cada vez m�s dif�cil agregar nuevos aspectos al mismo. Adem�s los bugs llegan a ser cada vez m�s frecuentes y m�s dif�ciles de corregir. La se�a t�pica de tal sistema es una larga fase de pruebas despu�s de que el sistema ha sido "completado". Tal fase larga de pruebas hace estragos con los planes de pruebas y depurado llegando a ser imposible de incluir en el programa de trabajo.
Hemos vivido con este estilo de desarrollo por mucho tiempo, pero tambi�n hemos tenido una alternativa desde hace mucho: Metodolog�a. Las metodolog�as imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo m�s predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte �nfasis en planificar inspirado por otras disciplinas de la ingenier�a.
Las metodolog�as ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. A�n menos por su popularidad. La cr�tica m�s frecuente a estas metodolog�as es que son burocr�ticas. Hay tanto que hacer para seguir la metodolog�a que el ritmo entero del desarrollo se retarda.
Como una reacci�n a estas metodolog�as, un nuevo grupo de metodolog�as ha surgido en los �ltimos a�os. Durante alg�n tiempo se conoc�an como metodolog�as ligeras, pero el t�rmino aceptado ahora es metodolog�as �giles. Para mucha gente el encanto de estas metodolog�as �giles es su reacci�n ante la burocracia de las metodolog�as monumentales. Estos nuevos m�todos buscan un justo medio entre ning�n proceso y demasiado proceso, proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena.
El resultado de todo esto es que los m�todos �giles cambian significativamente algunos de los �nfasis de los m�todos ingenieriles. La diferencia inmediata es que son menos orientados al documento, exigiendo una cantidad m�s peque�a de documentaci�n para una tarea dada. De muchas maneras son m�s bien orientados al c�digo: siguiendo un camino que dice que la parte importante de la documentaci�n es el c�digo fuente.
Sin embargo yo no creo que �ste sea el punto importante sobre los m�todos �giles. La falta de documentaci�n es un s�ntoma de diferencias mucho m�s profundas:
- Los m�todos �giles son adaptables en lugar de predictivos. Los m�todos ingenieriles tienden a intentar planear una parte grande del proceso del software en gran detalle para un plazo largo de tiempo, esto funciona bien hasta que las cosas cambian. As� que su naturaleza es resistirse al cambio. Para los m�todos �giles, no obstante, el cambio es bienvenido. Intentan ser procesos que se adaptan y crecen en el cambio, incluso al punto de cambiarse ellos mismos.
- Los m�todos �giles son orientados a la gente y no orientados al proceso. La meta de los m�todos ingenieriles es definir un proceso que funcionar� bien con cualquiera que lo use. Los m�todos �giles afirman que ning�n proceso podr� nunca maquillar las habilidades del equipo de desarrollo, de modo que el papel del proceso es apoyar al equipo de desarrollo en su trabajo. Expl�citamente puntualizan el trabajar a favor de la naturaleza humana en lugar de en su contra y enfatizan que el desarrollo de software debe ser una actividad agradable.
En las secciones siguientes explorar� estas diferencias m�s a detalle, para que usted pueda entender lo que es un proceso adaptable y centrado en la gente, sus beneficios y desventajas, y si es algo que deber�a usar: sea como desarrollador o como cliente de software.