1ª experiencia XP
Métodos Ágiles
Métodos Ágiles para el Desarrollo de Software es una materia electiva del segundo cuatrimestre de 4º año de Ingeniería en Sistemas de Información en la la facultad dónde estudio (UTN-FRSF). Yendo al grano: estudia los llamados Métodos Ágiles, en particular eXtreme Programming.
La idea de estas metodologías, a diferencia de las tradicionales es evitar la tortuosa y burocrática documentación, a la vez que se enfocan en las personas y en los resultados.
XP: Programación eXtrema
Dentro de este contexto, la Programación eXtrema (una de las metodologías más exitosas del rubro) se presenta como una diciplina de desarrollo de software basada en valores como simplicidad, comunicación, retroalimentación y valor. Trabaja poniendo a todo el equipo ante práctica simples, con suficiente retroalimentación para permitirle ver dónde está y cómo encarar un problema particular.
En XP, cada contribuidor al proyecto es una parte integral del Equipo. El equipo se forma al rededor de un representante del negocio, llamado El Cliente, el cual se sienta y trabaja con el equipo diariamente (cliente in-situ).
Nuestro trabajo práctico consistía en desarrollar la primer versión de un sistema de gestión de socios de un club en base a una lista de historias provistas por la prfesora. Las historias son la forma en la que XP define los requisitos para el sistema.
Para realizarlo llevamos a cabo algunas de las prácticas que XP propone (las escribo sin un orden específico), bold significa que aplicamos conscientemente la práctica:
- Cliente in-situ
- Juego de la planificación
- Metáfora
- 40 hs semanales
- Diseño sencillo
- Recodificación
- Programación en parejas
- Pruebas
- Versiones cortas
- Propiedad colectiva
- Estándares de codificación
- Integración continua
Puede ser que el listado de prácticas no sea novedoso para algunos, de hecho son todas prácticas existentes. XP lleva su nombre por llevar todas estas prácticas al extremo. Si hacer pruebas es bueno, se escribirán pruebas para todos los métodos que lo ameriten y luego se escribirá el código que pase esas pruebas. Si integrar es bueno, se integrará continuamente. Si la retroalimentación del cliente es buena, se sumará este al equipo de desarrollo.
Se puede leer más sobre XP en:
Programación en parejas
Una de las prácticas que conscientemente llevamos a cabo fue la de programar en parejas. En el grupo eramos 4 y tuvimos la suerte de trabajar siempre en una casa con dos computadoras, por lo que las parejas podían ir rotando y hacerse consultas entre ellas. A mi parecer es una de las prácticas más importantes de XP, y es un tema tan amplio que hasta tiene su propio sitio web:
Pruebas (de unidad)
El lenguaje de programación utilizado fue Java. También usamos un framework para mapear objetos en memoria a una base de datos relacional (Hibernate) y uno para generar reportes (JasperReports). Elegimos estas herramientas por que ya las habíamos usado para un trabajo práctico previo, lo que nos permitió poner foco en la metodología y no en la herramienta.
Para trabajar con pruebas, también utilizamos un framework (JUnit), desarrollado originalmente por Erich Gamma y Kent Beck (creador de XP). Trabajar de esta forma nos gustó muchos a todos los miembros de grupo, saber que luego de ese cambio el software sigue pasando las pruebas es alentador y refuerza uno de los valores de XP, la valentía.
Básicamente lo que hacíamos era:
1) Pensar en un método que se necesitaba.
2) Crear una prueba para ese método.
3) Correr la prueba. Fallaba.
4) Escribir código que haga pasar la prueba.
5) Correr la prueba. Si fallaba volvíamos al punto 4.
JUnit te provee de métodos parecidos a:
assertEquals(valorEsperado, valorCalculado);
Esa última línea puede fallar o puede pasar. A la vez se crea un árbol de pruebas con todas las que hallamos escrito y cuando lo ejecutamos, a medida que las pruebas van pasando una barra verde se va completando. Si la barra se completa de color verde significa que todas las pruebas pasaron. Si alguna prueba falla, la barra se vuelve roja.
Una de las prácticas es la recodificación (esta nos ayuda a mantener un diseño simple), pero.. como recodificar y saber que no hemos cometidos errores? Luego de realizar un cambio corremos nuevamente las pruebas. Si obtenemos una barra verde estamos listos para el siguiente cambio. Rigurosamente la barra verde nos indica que el sistema sigue pasando las pruebas que antes pasaba, no que no tenga errores, pero en la práctica parece ser una buena aproximación.
ClubXP
Además, como refuerzo para la Integración continua utilizamos Subversion para mantener ordenas las revisiones que ibamos haciendo del código: clubxp en code.Google.
Saludo
Bueno, fue algo de lo que quería contar. En estas fechas de finalización de cursado no escribo casi nada en el blog, así que les dejo un saludo y Hasta la próxima!