Teniendo en cuenta el corto tiempo que teníamos para entregar nuestro proyecto, decidimos aplicar la metodología XP, la cual se basa en la simplicidad, la comunicación y la realimentación o reutilización del código generado.
Primero que todo, en base a la fecha de entrega realizamos un plan de iteraciones, en el cual se especifican cuales requisitos generales iban a ser desarrollados para cada semana.
Para la primera entrega que fue únicamente el requisito de gestionar usuarios, todos trabajamos en conjunto, retroalimentándonos con información que cada uno encontraba y leyendo el manual del framework kumbia, ya que para este requisito apenas nos estábamos acostumbrando a trabajar con el kumbia de modo que para esta primera entrega se trabajo más que todo en paralelo, comunicándonos constantemente las cosas que íbamos entendiendo y logrando desarrollar. Esta primera parte puede decirse que fue una especie de adaptación al framework, debido a que nunca lo habíamos utilizado.
Después de la primera entrega prácticamente teníamos que replantear todo el requisito de gestión de usuarios, ya que no lo habíamos hecho muy usable y el cliente en este caso el ingeniero Libardo Pantoja nos dio las siguientes sugerencias:
- Listar todos los usuarios existentes, cada uno con la opción de eliminar o modificar.
- Al modificar un usuario deben aparecer los datos existentes del mismo en los campos del formulario.
- Utilizar los helpers que brinda kumbia.
Teniendo en cuenta todo lo anterior nos repartimos el trabajo de la segunda entrega que eran los requisitos: gestión de usuarios y gestión de contactos, de tal manera que dos personas (Martha y Andrea) se centraban en la parte de gestión de usuarios y los otros dos (Edinson y Claudia) se centraban en la autenticación del usuario. Decidimos repartirnos el trabajo de esta manera, debido a que la gestión de contactos era muy similar a la gestión de usuarios, por lo que solo seria adaptar lo de la gestión de usuarios a la gestión de contactos. Para lograr terminar a tiempo, poníamos una fecha máxima para entregar lo que a cada uno le tocaba y nos reuníamos con el fin de acoplar todo en una sola carpeta y despejar las dudas que surgieran del código generado. Por último, nos dedicamos a la parte de la apariencia o look and feel de nuestra aplicación, obteniendo al final una aplicación usable y en la cual aplicamos todas las sugerencias que nos dio el usuario en la primera entrega.
En la segunda entrega el día miércoles 12 de Mayo le mostramos el funcionamiento de la aplicación al cliente (ingeniero Libardo Pantoja), el cual una vez más nos dio algunas sugerencias:
- Adaptarle a la paginación los números de página.
- Al imprimir que muestre las ñ y las tildes.
- Para las acciones de editar y eliminar, usar iconos en vez de enlaces de texto.
- Indicar los campos que son obligatorios en los formularios.
Para esta segunda entrega ya habíamos realizado un gran avance y logramos hacer uso de los helpers que provee kumbia al documentarnos sobre su uso en internet y reutilizando código que encontrábamos y que veíamos que nos podría ser útil para nuestra aplicación.
Para la tercera entrega debemos presentar los requisitos: calendario y administración de archivos, de manera que decidimos repartirnos cada requisito de la siguiente forma:
Martha y Andrea trabajarán en paralelo el requisito calendario, Edinson y Claudia trabajarán en paralelo el requisito administración de archivos.
Finalmente, en cuanto a los roles pensábamos que iban a tener roles muy definidos para cada persona del grupo, pero al momento de la práctica todos hicimos de todo, ya que primero todos desarrollábamos en paralelo y al final nos reuníamos y discutíamos sobre la parte de la apariencia de la aplicación.
De lo anterior rescatamos las siguientes características de la metodología XP:
- Programación en Parejas: Para cada entrega se tuvo la filosofía de la programación en parejas propia de la metodología XP, haciendo un trabajo más ágil y en paralelo.
- Posesión Colectiva del Código (Collective Code Ownership): Nadie es dueño de un modulo. Cualquiera de nosotros como desarrolladores de la aplicación podía cambiar cualquier parte del sistema en cualquier momento, a pesar de la división del trabajo.
- Integración continua (Continuous Integration): Los cambios se integraron en el código base varias veces, de acuerdo a las entregas y a la finalización de cada una de las labores de las parejas.
