Se ha optado por la programación extrema XP ya que ésta se ajusta mejor a las características del proyecto.
Más concretamente, se cumplen las recomendaciones para emplear XP en un proyecto [Wells03] [Ferrer03]:
Interés sincero por todas las partes en que el proyecto tenga éxito.
El equipo de trabajo es pequeño.
No existe un contrato fijo previo especificando tiempo, recursos y alcance.
El equipo dispone de una formación elevada (esa es la finalidad) y capacidad de aprender.
El proyecto tiene un riesgo alto en cuanto a lo innovador de la tecnología.
También se ha tenido en cuenta el éxito que ha tenido extreme programming en proyectos open source, cuyas características hacen que se adapte especialmente bien esta metodología.
Como es evidente no todas las prácticas son aplicables al presente proyecto, por lo que a continuación se especifica para cada una de ellas su aplicación en ONess:
Planificación incremental
Se ha decidido realizar cuatro releases con sus respectivas iteraciones. Cada una de ellas proporcionando un valor de negocio claro, a grosso modo serán:
party: gestión de clientes y proveedores
user: gestión de usuarios
inventory: gestión de inventario
order: gestión de pedidos, albaranes y facturas
En el Capítulo 7, Planificacion de las entregas se detallará cada una de estas iteraciones.
En cuanto a la valoración de los costes de usar distintas opciones tecnológicas dado el fin principalmente de innovación no se ha utilizado para realizar una comparación, si bien se ha sido consciente de que el uso de nuevas tecnologías supone un coste importante de aprendizaje. Este coste se convierte en beneficios posteriores, como son un inferior tiempo de desarrollo al añadir nueva funcionalidad una vez que el núcleo del sistema ha sido realizado y, aunque no relacionado específicamente con este proyecto, una gran experiencia para su autor.
Testing
Una de las principales aportaciones de esta metodología es el concepto de desarrollo dirigido por tests (Test Driven Development). Los tests son realizados a priori con el fin de prevenir errores, no de solucionarlos. Esto confiere una gran calidad al software resultante. Los tests son ejecutados automáticamente cada día para asegurar que el sucesivo desarrollo del sistema no afecta a su estabilidad. Dado que los tests son creados a priori fallarán hasta que la funcionalidad esté implementada, en el proceso que comúnmente se llama rojo a verde. En caso de que se encuentren fallos no detectados previamente, es requisito escribir un test que falle para posteriormente solucionar el problema.
La automatización de los tests proporciona una gran seguridad, por ejemplo en las pruebas del sistema con distintos gestores de base de datos se tiene la certeza de que si los tests se ejecutan correctamente la compatibilidad existe.
Programación en parejas
Dado el impuesto carácter individual del proyecto esta práctica no ha sido aplicada.
Refactorización
En las sucesivas iteraciones ha sido necesario refactorizar partes del núcleo del sistema y este proceso ha sido realmente sencillo, a lo que ha contribuido en gran parte la cantidad de tests realizados.
Diseño simple
El diseño se ha mantenido sencillo, desde luego pasando los tests, sin código duplicado y con un mínimo de código gracias al núcleo del sistema que proporciona un gran dinamismo y evita la necesidad de implementación de operaciones repetitivas.
Propiedad colectiva del código
A pesar de que en este proyecto no ha existido un grupo de desarrolladores como tal, gracias a su licencia open source y al sitio web que se ha puesto a disposición de toda la comunidad en [Sourceforge], se ha llevado a la práctica esta propiedad colectiva, donde cualquier desarrollador puede examinar el código y realizar las modificaciones que consideren pertinentes, pudiendo revertirse estas contribuciones en el proyecto.
Integración continua
La integración es permanente gracias a los tests de integración y la automatización con la herramienta Maven.
Cliente en el equipo
Aunque esto estrictamente no se realiza dada la naturaleza del proyecto, la experiencia del autor en el ámbito empresarial tratado hace que se tengan en todo momento presentes los intereses y visión de negocio.
Releases pequeñas
Se ha seguido esta práctica, liberando nuevas versiones según la funcionalidad se ha ido implementando.
Semanas de 40 horas
No es aplicable a este proyecto.
Estándares de codificación
Se ha seguido el estándar de codificación Java, definido por Sun en [JavaCodeConventions].
Uso de Metáforas
Se ha utilizado el vocabulario de negocio en inglés por su mayor alcance a nivel mundial. Para facilitar la comunicación con los posibles usuarios se han establecido mecanismos como listas de correo y un weblog para facilitar la lectura de las noticias que genera el proyecto.