Tutoriales
Enlaces
Licencia
Esta obra está bajo una licencia de Creative Commons.
Para reconocer la autoría debes poner el enlace https://old.chuidiang.org
En los tiempos en que la informática empezó a hacerse popular, en el que sólo había pantallas de texto, no había entornos de ventanas y las impresoras usaban papel con agujeros a los lados y rayas horizontales, las aplicaciones eran bastante más sencillas que las actuales. Bastaba uno o dos programadores, que totalmente a su aire y en un plazo razonable de tiempo eran capaces de hacer programas útiles. Para imprimir una lista de clientes, bastaba pulsar en el menú el "1" de imprimir, luego el "3" de clientes y echarle un ojo a la impresora para ver si imprimía o no. El programador era una especie de "mago" que hacía su aplicación y sólo él sabía cómo funcionaba. Si acaso, y para cubrir el expediente, después de hacer el programa hacía un "flujograma" de los antiguos, no había UML, orientación a objetos ni cosas por el estilo.
Con el tiempo, las aplicaciones fueron siendo cada vez más exigentes, los ordenadores disponían de más memoria y aparecieron los entornos de ventanas. Ahora para imprimir la lista de clientes, había que arrastrar el icono del "señor gordo con bigote" sobre el icono de la impresora, haciendo que caminara "como un egipcio" mientras lo arrastrabamos con el ratón (otro invento nuevo). La impresora debía imprimir gráficos, con negritas, cursivas y 32 fuentes simultáneamente. Además, hay que hacer que los altavoces estereos toquen música polifónica mientras se arrastra al "gordo del bigote".
Todas estas complicaciones hicieron que los programas se agrandaran y complicaran enormemente, que hicieran falta varios desarrolladores y tiempos de desarrollo más largo. Todo esto llevó consigo la necesidad de más organiazación y más papeleo. Aparecieron las metodologías de desarrollo más pesadas (las que se basan en escribir mucha documentación). Antes de hacer un programa, fue necesario escribir qué es lo que se quería hacer, de forma que asegurábamos que el cliente y los desarrolladores estaban de acuerdo en lo que se iba a hacer. Luego había que escribir qué se iba a hacer, para que los muchos programadores trabajaran más o menos con un objetivo común y organizados, etc, etc.
De alguna forma, toda esta organización y papeleo quitó parte del encanto de la programación. Los programadores, en vez de dedicarse a lo que se supone que les gusta, programar, debían dedicar bastante de su tiempo a hacer y leer documentos, reuniones, etc.
Tratando un poco de recuperar los viejos tiempos, en el que había menos papeleo, las cosas eran más sencillas y los programadores hacían lo que les gustaba, nació una nueva metodología de desarrollo, la programacion extrema.
En la programación extrema se da por supuesto que es imposible prever todo antes de empezar a codificar. Es imposible capturar todos los requisitos del sistema, saber qué es todo lo que tiene que hacer ni hacer un diseño correcto al principio. Es bastante normal hacer un diseño, ponerse a codificar, ver que hay faltantes o errores en el diseño, empezar a codificar fuera del diseño y al final el código y el diseño, o no se parecen, o hemos echado un montón de tiempo en cambiar la documentación de diseño para que se parezca al código.
En vez de tratar de luchar contra todo eso, lo asume y busca una forma de trabajar que se adapte fácilmente a esas circunstancias. Básicamente la idea de la programación extrema consiste en trabajar estrechamente con el cliente, haciéndole mini-versiones con mucha frecuencia (cada dos semanas). En cada mini-versión se debe hacer el mínimo de código y lo más simple posible para que funcione correctamente. El diseño se hace sobre la marcha, haciendo un mini-diseño para la primera mini-versión y luego modificándolo en las siguientes mini-versiones. Además, no hay que hacer una documentación para el diseño, no hay mejor documentación que el mismo código. El código, por tanto, también se modifica continuamente de mini-versión en mini-versión, añadiéndole funcionalidad y extrayendo sus partes comunes.
En un proyecto usando programación extrema se siguen más o menos los siguientes pasos:
El cliente junto al equipo de desarrollo definen qué es lo que se quiere hacer. Para ello utilizan las "historios de usuario". Una historia de usuario en un texto de una o dos frases en las que se dice algo que debe hacer el sistema. Es más extensa que un requisito (que suele ser una frase corta) y menos que un caso de uso (que puede ser de una o dos páginas). Se evalua para cada historia de usuario el tiempo que puede llevar, que debe ser corto, de aproximadamente una semana. Un programador puede estimar con cierta fiabilidad un trabajo que le lleve unos días, pero la estimación es menos fiable si es de un plazo superior a una semana. Si es más largo, hay que partir la historia en otras más pequeñas. Luego se ordenan en el orden en que se van a desarrollar y se establecen las mini-versiones, de forma que cada mini-versión implementa varias de las historias de usuario.
Toda esta planificación va a ser, por supuesto, inexacta. No se puede saber todo lo que va a ser necesario ni evaluar los tiempos correctamente. La planificación deberá revisarse y modificarse continuamente a lo largo del proyecto. Las historias de usuario se modificarán, se quitarán o se añadirán nuevas sobre la marcha. Puesto que el cliente estará presente día a día durante todo el proyecto, verá el efecto y el esfuerzo necesario para las modificaciones pedidas y sabrá evaluar si merecen o no la pena.
Para las primeras historias que se van a implementar, se define una prueba para ver si la versión cumple perfectamente con la historia. Estas pruebas deben ser automáticas, de forma que haya un programa de pruebas que ejecutemos y nos diga si la mini-versión es o no correcta.
Los programadores se ponen por parejas (dos personas en el mismo ordenador) para codificar esas historias. Primero codifican el programa de pruebas y ven que falla ( ¡ El código todavía no está hecho ! ). Luego piensan cómo van a implementar la historia y hacen sus propios programas de prueba (también automáticos). Codifican sus programas de prueba y ven que también fallan. Luego se ponen a codificar hasta que se pasen con éxito todas las pruebas. En su código hacen de la forma más sencilla posible lo mínimo imprescindible para que se pasen las pruebas automáticas.
Las parejas de programadores se intercambian con frecuencia, de forma que todos acaban trabajando con todos. El trabajo por parejas haciendo intercambios tiene las siguientes ventajas:
Cuando una nueva pareja va a realizar un nuevo código para una historia de usuario, puede que uno de ellos recuerde haber hecho un trozo de código en otro lado que podría reutilizar. Esta pareja irá a ese trozo de código y lo reutilizará, modificándolo si es necesario. Después de modificarlo, deben asegurarse que se siguen pasando las pruebas automáticas que se hicieron en su momento, así como añadir nuevas pruebas para comprobar las modificaciones que han hecho.
Si una pareja al reutilizar código ya hecho ve que es mejorable, lo mejoran, pasando las pruebas automáticas después. Si al reutilizar el código ya hecho descubren un error que las pruebas automáticas no detectan, añaden pruebas capaces de detectar el error y lo corrigen.
El código, por tanto, no es de nadie. Cualquier pareja puede tocar el código ya hecho por otras personas si lo necesita, con la condición de que después de tocarlo las pruebas automáticas sigan pasándose correctamente y que añadan sus propias pruebas automáticas para las correcciones realizadas.
Todos los días se hace una pequeña reunión a primera hora de la mañana con todo el equipo en la que se comentan problemas, código que se está realizando, historias de usuario terminadas, etc.
Cada vez que se consigue codificar y que funcione una historia de usuario, se le da al cliente para que la vea, la pruebe y añada las posibles modificaciones para las siguientes mini-versiones. Cuando se realiza un mini-versión completa (compuesta por varias de las historias de usuario), incluso se entrega al usuario final para que empiece a trabajar con ella y reportar inicidencias o mejoras.
Este ciclo se va repitiendo una y otra vez hasta que el cliente se de por satisfecho y cierre el proyecto. Cómo se ve, no se ha hecho documentación. En algún sitio he leido que incluso la planificación inicial debe hacerse escribiendo cada historia de usuario en un tarjeta, haciendo dos montones, las que ya están hechas y las que no. Se pueden tirar las tarjetas, añadir nuevas o cambiar las que ya hay. El número de tarjetas en cada montón nos da una idea exacta de cuánto hay hecho del proyecto.
Para que todo esto funcione, la programación extrema se basa en trece "prácticas básicas" que deben seguirse al pie de la letra. Dichas prácticas están definidas (en perfecto inglés) en www.xprogramming.com/xpmag/whatisxp.htm. Aquí tienes un pequeño resumen de ellas
Lástima que estén en perfecto inglés, pero ahí los tienes www.xprogramming.com y www.extremeprogramming.org