Metodologia XP

1. Planeacion

1.1. Historias de Usuario

1.1.1. En XP, el proyecto inicia con la definición de historias de usuario junto con el cliente.

1.1.2. Son descripciones cortas y simples en lenguaje no técnico.

1.1.3. No incluyen detalles sobre algoritmos o bases de datos.

1.1.4. Se usan para estimar tiempos de desarrollo y validar el software.

1.1.5. Antes de implementarlas, se detallan en reuniones con el cliente.

1.1.6. El desarrollo de cada historia debe tomar entre 1 y 3 semanas.

1.2. Realese Plan

1.2.1. Secrea un Release Plan (plan de publicaciones).

1.2.2. Se indican qué historias se implementarán en cada versión y sus fechas de publicación.

1.2.3. Se establecen tiempos ideales, prioridades y distribución de historias por versión.

1.3. Iteraciones

1.3.1. En XP, los proyectos se dividen en iteraciones de aproximadamente 3 semanas.

1.3.2. Al inicio de cada iteración, el cliente selecciona las historias a implementar.

1.3.3. Se incluyen historias que no pasaron el test de aceptación anterior.

1.3.4. Las historias se dividen en tareas de 1 a 3 días de duración.

1.3.5. Las tareas se asignan a los programadores para su desarrollo.

1.4. Velocidad del proyecto

1.4.1. Mide la rapidez del desarrollo.

1.4.2. Se calcula contando las historias de usuario completadas en una iteración.

1.4.3. Permite estimar cuántas historias se pueden desarrollar en futuras iteraciones.

1.4.4. Ayuda a controlar que las tareas se completen dentro del tiempo disponible.

1.4.5. Se debe reevaluar cada 3 o 4 iteraciones.

1.5. Programacion en parejas

1.5.1. XP recomienda la programación en parejas para mejorar productividad y calidad

1.5.2. Dos programadores trabajan en el mismo equipo

1.5.2.1. Codificacion y Calidad

1.5.2.2. Analisis e implementacion

1.6. Dayli meeting

1.6.1. XP recomienda reuniones diarias para conocer los problemas, soluciones e ideas de forma conjunta

2. Diseño

2.1. Diseño simple

2.1.1. XP promueve diseños simples y sencillos.

2.1.2. Se debe evitar la complejidad innecesaria.

2.1.3. Un diseño claro y fácil de entender facilita su implementación.

2.2. Glosario de terminos

2.2.1. XP recomienda usar glosarios de términos y nombres claros en métodos y clases.

2.2.2. Mejora la comprensión del diseño.

2.2.3. Facilita futuras ampliaciones y la reutilización del código.

2.3. Riesgos

2.3.1. XP sugiere utilizar una pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese problema

2.4. Funcionalidad extra

2.4.1. Nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será utilizada

2.5. Refactorizar

2.5.1. Mejorar y modificar la estructura y codificación de códigos ya creados sin alterar su funcionalidad.

2.5.2. Supone revisar de nuevo estos códigos para procurar optimizar su funcionamiento

3. Codificacion

3.1. El cliente es parte del equipo de desarrollo y su presencia es clave.

3.2. Es esencial durante la codificación de historias de usuario.

3.3. Define las historias y negocia los tiempos de implementación.

3.4. Antes del desarrollo, debe especificar los detalles de cada historia.

3.5. Debe estar presente en los test de verificación.

3.6. La codificación debe seguir estándares, asegurando consistencia y escalabilidad.

4. Prueba

4.1. Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo específico para test.

4.2. Hay que someter a tests las distintas clases del sistema omitiendo los métodos más triviales.

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

4.4. Un punto importante es crear test que no tengan ninguna dependencia del código que en un futuro evaluará.

4.5. Como se comentó anteriormente los distintos test se deben subir al repositorio de código acompañados del código que verifican.

4.6. Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas tareas en las que ha sido dividida una historia de usuario.

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