Metodología de desarrollo XP

Ciclo de la metodología

1. Planificación. Escuchar las necesidades del Cliente, hacerlo parte del equipo, pero explicar lo que es fácil de obtener y lo que no
2. Diseño. Es importante usar patrones de diseño.
3. Desarrollo. Hacer que el propio código comunique lo que está haciendo.
4. Pruebas. Realizar pruebas unitarias, puedes usar frameworks muy conocidos como JUnit y DBUnit.

Valores que promueve : | Comunicación | Coraje | Simplicidad | Retroalimentación |

Ventajas:

• Es un diseño simple
• Obliga a que funcionen todas las pruebas unitarias, todo el tiempo.
• Muchos comentan que no tiene, pero yo creo que solo se reduce la lógica duplicada.
• Suele tener menor número de clases y métodos. Aunque esto depende de la modularidad de la aplicación y que el desarrollador realice un diseño claro, simple y use patrones.
  

Desventajas:

• La documentación suele ser pobre.

Buenas prácticas:

• Realizar un diseño simple
• Pequeñas versiones. Hacer entregas constantes para que el Cliente perciba el avance y retroalimente las necesidades de negocio que afinen la funcionalidad efectiva de la aplicación.
• Pruebas. Cada funcionalidad en la aplicacion (front, back, web-services, DAOs, VOs, Utilerías, etc.) debe ser probada.
• Recodificar. Siempre que veamos código al que se puede aplicar un refactoring, aunque no sea nuestro, es conveniente avisar al equipo y planear su reestructuración a medida que la propia aplicación lo pida.
• Programar en parejas. Un solo teclado, un solo ratón, una persona codifica, ambos piensan, se logran ideas más estratégicas (es importante que ambos estén abiertos a escuchar las ideas del otro con el fin de mejorar las propuestas planteadas y por consiguiente la aplicación).
• Integrar una vez al día. Obviamente antes de integrar implica ejecutar las pruebas para validar que todo siga funcionando como lo esperan las pruebas unitarias.
• 40 hrs por semana máximo permiten estar fresco, descansar 2 días para pensar en nuevas ideas y aplicarlas al inico de semana. Estaría bien disponer de un tiempo a medio día para descansar (siesta, break, tomar un pequeño postre) o despejar la mente realizando otras actividades (juegos de mesa, videojuegos, salas de lectura, reuniones de convivencia). Es parte del modelo laboral japonés y les funciona.
• Establecer estándares de codificación. Usar un checkstyle y practicar revisiones en parejas del código de otros resulta bastante bueno para la aplicación pues ayuda a detectar posibles errores de estilo e incluso de lógica, de forma que cualquier nuevo integrante que llegue al equipo se familiarice más rápido con el código.
  

XP Xtreme Programming: reglas

Reglas del XP

Planning

1. User stories are written (o Casos de Uso).
2. Release planning creates the schedule.
3. Make frequent small releases.
4. The Project Velocity is measured.
5. The project is divided into iterations.
6. Iteration planning starts each iteration.
7. Move people around.
8. A stand-up meeting starts each day.
9. Fix XP when it breaks.

Designing

1. Simplicity (mantener las cosas simples siempre ayuda!!!).
2. Choose a system metaphor.
3. Use CRC cards for design sessions.
4. Create spike solutions to reduce risk.
5. No functionality is added early.
6. Refactor whenever and wherever possible (muy importante!!).

Coding

1. The customer is always available.
2. Code must be written to agreed standards.
3. Code the unit test first (<- TDD).
4. All production code is pair programmed.
5. Only one pair integrates code at a time.
6. Integrate often.
7. Use collective code ownership.
8. Leave optimization till last.
9. No overtime.

Testing (http://www.agiledata.org/essays/tdd.html)

1. All code must have unit tests.
2. All code must pass all unit tests before it can be released.
3. When a bug is found tests are created.
4. Acceptance tests are run often and the