Metodología XP para realización de Ajedrez Suicida para celulares

La razón por la que creemos que la metodología XP se adecua bien a nuestro proyecto es
la facilidad que esta provee para adaptarse a proyectos pequeños (como lo es el juego de
ajedrez suicida). Esto sin embargo es una propiedad que tienen todas las metodologías
ágiles. La razón por la que se escogió XP de entre las metodologías ágiles es el concepto
de construir versiones incompletas o más bien parciales de lo que se quiere que sea el
proyecto antes de construir la versión final y el de poder deshechar totalmente las
versiones viejas de ser necesario.

Esto se adecúa mucho a nuestro proyecto ya que encontramos dos dificultades

principales en la realización de este proyecto. La primera es la lógica del sistema que
gobernará tanto el juego como la interfaz del usuario y la segunda es la implementación
de la misma en el celular. Consideramos que viendo a un futuro, de empezar a programar
con el concepto de “cascada” o buscando programar partes útiles del proyecto final
resultaba inpráctico ya que esto no independiza los problemas que puedan surgir a partir
de cada una de las dificultades identificadas en el proyecto. Por lo tanto creemos que
resultaría posible e incluso probable toparnos en con un “bug” en una versión avanzada
del proyecto y no saber si este se debe a un error en el pensamiento de la
implementación lógica o a las restricciones del lenguaje que debemos usar para que el
programa corra en celulares.

En contraste a la metodología de scrum, que usualmente de lo que se vió en la literatura

es más fácil de imlementar, no posee tan reforzado el concepto de rediseño e iteraciones,
con la producción constante de realeses. Así el mayor beneficio de scrum, que es la
cuantización en horas estimadas de las tareas de cada sprint, y la gráfica que permite
calcular muchas proyecciones del trabajo en cuanto a las fechas de el release y de
finalización del sprint, no las consideramos necesarias. Creemos que sería una mala
inversión de tiempo preocuparse poresos calculos mientras es más importante avanzar
con el proyecto. Ambas metodolog;ias tienen reuniones y retroalimentaci;on a el
planeamiento inicial, así su diferencia emás grande es esa. El daily scrum no estan
necesario como lo sería reunirse las veces programadas ya lgunas extras si se desea
afianzar alguna specto del dise;o en las refactorizaciones, pero estas estan contempladas
en XP. Otra razón y un fuerte de XP es fel énfasis en las pruebas de unidad, que son de
enorme imortancia para ir escalando el programa y un detalle que por experiencias
pasadas debemos de darle la precaución necesaria.

Por lo tanto consideramos que resulta conveniente tener antes de programar la versión
final del proyecto para celulares, una versión previa que funcione en computadoras con
Java de manera que podamos resolver los problemas lógicos del programa usando un
lenguaje más conocido antes de intentar aventurarnos sobre las restricciones de
programación que nos forzará la versión Micro de Java. Esta idea va muy en acorde con
el concepto de “refactoring” usado en XP ya que la versión de Java podrá ser
considerablemente distinta a la de JavaME, y de hecho consideramos que sería mejor
iniciar la versión en JavaME a partir de nada usando la versión preva en Java sólo para
conocer los conflictos lógicos de la programación y haberlos resuelto con anterioridad.
Además esto nos permitirá cumplir con el otro objetivo de XP de tener siempre algo
funcional que presentar, aún si no es el producto final que se espera, hasta que el
producto final esté completo.
Se espera que para la revisión del 2 de abril ya se tenga avanzado el proyecto en su
versión para JavaSE, los diagramas de estado y algún caso de prueba. El proyecto en su
versión para Java SE deberá estar completo a más tardar en la semana del 20 al 26 de
abril. Para esta fecha habremos investigado también algunos detalles de la programación
en JavaME para poder iniciar con la producción de la parte lógica del proyecto final. Esta
deberá estar lista para la primera semana de Mayo, dándonos tiempo para concluir en la
semana del 18 al 24 con la parte gráfica y la integración de ambas partes al proyecto final.
Posteriormente sólo quedará realizar las pruebas necesarias para la entrega final del
proyecto en las primeras semanas de junio (antes del 15 como o como se acuerde en
clase).