Xp Para Ajedrez En Javame

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).