La metodología que se
utilizara para el desarrollo de este proyecto es la XP (eXtreme Programming),
la cual es una metodología de desarrollo de la ingeniería de software formulada
por Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de
desarrollo de software. Al igual que éstos, la programación extrema se
diferencia de las metodologías tradicionales principalmente en que pone más
énfasis en la adaptabilidad que en la previsibilidad. La metodología XP tiene
un conjunto importante de reglas y prácticas. En forma genérica, se pueden
agrupar en:
1. Planificación.
2. Diseño.
3. Desarrollo.
4. Pruebas
Fase I: Planificación
La metodología XP plantea
la planificación como un diálogo continuo entre las partes involucradas en el
proyecto, incluyendo al cliente, a los programadores y a los coordinadores o
gerentes. El proyecto comienza recopilando “Historias de usuarios”, las que
sustituyen a los tradicionales “casos de uso”. Una vez obtenidas las “historias
de usuarios”, los programadores evalúan rápidamente el tiempo de desarrollo de
cada una.
Si alguna de ellas tiene
“riesgos” que no permiten establecer con certeza la complejidad del desarrollo,
se realizan pequeños programas de prueba (“spikes”), para reducir estos
riesgos. Una vez realizadas estas estimaciones, se organiza una reunión de
planificación, con los diversos actores del proyecto (cliente, desarrolladores,
gerentes), a los efectos de establecer un plan o cronograma de entregas
(“Release Plan”) en los que todos estén de acuerdo. Una vez acordado este
cronograma, comienza una fase de iteraciones, en dónde en cada una de ellas se
desarrolla, prueba e instala unas pocas “historias de usuarios”.
Según Martín Fowler (uno
de los firmantes del “Agile Manifesto”), los planes en XP se diferencian de las
metodologías tradicionales en tres aspectos:
1. Simplicidad del plan.
No se espera que un plan requiera de un “gurú” con complicados sistemas de
gerenciamiento de proyectos.
2. Los planes son
realizados por las mismas personas que realizarán el trabajo.
3. Los planes no son
predicciones del futuro, sino simplemente la mejor estimación de cómo saldrán
las cosas. Los planes son útiles, pero necesitan ser 16 cambiados cuando las
circunstancias lo requieren. De otra manera, se termina en situaciones en las
que el plan y la realidad no coinciden, y en estos casos, el plan es totalmente
inútil.
Fase II: Diseño
La metodología XP hace
especial énfasis en los diseños simples y claros. Los conceptos más importantes
de diseño en esta metodología son los siguientes:
1. Simplicidad: Un diseño simple se implementa más rápidamente que uno
complejo. Por ello XP propone implementar el diseño más simple posible que
funcione. Se sugiere nunca adelantar la implementación de funcionalidades que
no correspondan a la iteración en la que se esté trabajando.
2. Soluciones “spike”: Cuando aparecen problemas técnicos, o cuando es difícil de
estimar el tiempo para implementar una historia de usuario, pueden utilizarse
pequeños programas de prueba (llamados “spike”), para explorar diferentes
soluciones. Estos programas son únicamente para probar o evaluar una solución,
y suelen ser desechados luego de su evaluación.
3. Recodificación: La recodificación (“refactoring”) consiste en escribir
nuevamente parte del código de un programa, sin cambiar su funcionalidad, a los
efectos de hacerlo más simple, conciso y/o entendible. Muchas veces, al
terminar de escribir un código de programa, pensamos que, si lo comenzáramos de
nuevo, lo hubiéramos hecho en forma diferente, más clara y eficientemente. Sin
embargo, como ya está pronto y “funciona”, rara vez es rescrito.
4. Metáforas: Una “metáfora” es algo que todos entienden, sin necesidad de
mayores explicaciones. La metodología XP sugiere utilizar este concepto como
una manera sencilla de explicar el propósito del proyecto, y guiar la
estructura y arquitectura del mismo. Por ejemplo, puede ser una guía para la
nomenclatura de los métodos y las clases utilizadas en el diseño del código.
Tener nombres claros, que no requieran de mayores explicaciones, redunda en un
ahorro de tiempo.
Fase III: Desarrollo o Codificación
El cliente es una parte
más del equipo de desarrollo; su presencia es indispensable en las distintas
fases de XP. A la hora de codificar una historia de usuario su presencia es aún
más necesaria. No olvidemos que los clientes son los que crean las historias de
usuario y negocian los tiempos en los que serán implementadas. Antes del
desarrollo de cada historia de usuario el cliente debe especificar
detalladamente lo que ésta hará y también tendrá que estar presente cuando se
realicen los test que verifiquen que la historia implementada cumple la
funcionalidad especificada. La codificación debe hacerse ateniendo a estándares
de codificación ya creados. Programar bajo estándares mantiene el código consistente
y facilita su comprensión y escalabilidad.
Fase IV: Pruebas
Uno de los pilares de la
metodología XP es el uso de test para comprobar el funcionamiento de los
códigos que vayamos implementando.
El uso de los test en XP
es el siguiente:
·
Se deben crear las aplicaciones que
realizarán los test con un entorno de desarrollo específico para test. Hay que
someter a test las distintas clases del sistema omitiendo los métodos más
triviales.
·
Se deben crear los test que pasarán los
códigos antes de implementarlos; en el apartado anterior se explicó la
importancia de crear antes los test que el código.
·
Un punto importante es crear test que no
tengan ninguna dependencia del código que en un futuro evaluará.
·
Como se comentó anteriormente los distintos
test se deben subir al repositorio de código acompañados del código que
verifican.
·
Test de aceptación. Los test mencionados
anteriormente sirven para evaluar las distintas tareas en las que ha sido
dividida una historia de usuario.
·
Al ser las distintas funcionalidades de
nuestra aplicación no demasiado extensas, no se harán test que analicen partes
de las mismas, sino que las pruebas se realizarán para las funcionalidades
generales que debe cumplir el programa especificado en la descripción de requisitos.
