Programación extrema XP

1. EXTREME PROGRAMMING (XP)
Hernández Maya Diego Alfredo

2. LA PROGRAMACIÓN EXTREMA
Es una metodología de desarrollo de software que forma parte de las llamadas
metodologías agiles, creada por Kent Beck y que se puede clasificar dentro de
las metodologías evolutivas. Su autor Kent Beck opto por desarrollar una
metodología que combinara las mejores características de otras y reducir las
practicas pesadas de los métodos mas tradicionales.

3. VALORES
 Comunicación. Muy importante. La XP ayuda mediante sus prácticas
a la comunicación entre los integrantes del grupo de trabajo: jefes de
proyecto, clientes y desarrolladores.
 Sencillez. Los programas deben ser los más sencillos posibles y
tener la funcionalidad necesaria que se indican en los requisitos. No
hay que añadir algo que no se necesite hoy. Si se necesita añadir
más funcionalidad mañana pues ya se hará entonces.
 Retroalimentación. Las pruebas que se le realizan al software nos
mantiene informados del grado de fiabilidad del sistema.
 Valentía. Asumir retos, ser valientes ante los problemas y
afrontarlos. El intentar mejorar algo que ya funciona. Aunque gracias
a las pruebas unitarias no existe el riesgo de ‘meter la pata’.

4. PRINCIPIOS
 Realimentación veloz
 Modificaciones incrementales
 Trabajo de calidad
 Asunción de simplicidad

5. PRACTICAS
El juego de la planificación (the planning game). Es un permanente diálogo entre las partes
empresarial (deseable) y técnica (posible).
Pequeñas entregas (small releases). Se entregan pequeñas versiones del programa pero
manteniendo los requisitos primordiales y que funcione como un todo.
Metáfora (metaphor). Una metáfora es una historia que ayuda a que cualquiera pueda
entender lo que hace el programa.
Diseño sencillo (simple design). A la hora de desarrollar el software es necesario tratar de
hacerlo de la manera más simple.

6. PRACTICAS
Pruebas (testing). los programadores escriben pruebas para chequear el correcto
funcionamiento del programa, los clientes realizan pruebas funcionales.
Refactorización (refactoring). Se refiere a tratar de hacer el programa más simple al
implementar nuevas características sin que este pierda su funcionalidad original, a este
proceso se le denomina recodificar o reautorizar (refactoring).
Programación por parejas (pair programming). Todo el código de producción lo escriben dos
personas frente al ordenador, con un sólo ratón y un sólo teclado, uno codifica en el
ordenador y piensa la mejor manera de hacerlo, el otro piensa más estratégicamente.
Propiedad colectiva (collective ownership).Ningún miembro del equipo es propietario del
código. Nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte.

7. PRACTICAS
Integración continua (continuos integration). Hay que integrar todas las partes que se hayan
desarrollado del código al menos una vez al día y hacerle las pruebas correspondientes.
40 horas semanales (40-hour week). Se proponen estas horas para tener un avance
significativo del proyecto sin llegar a la fatiga que se puede generar en el equipo de trabajo.
Cliente en casa (on-site costumer). Un cliente real debe sentarse con el equipo de
programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar
las prioridades.
Estándares de codificación (coding standards). Este sirve para que todos los programadores
conozcan la forma en que está estructurada el código de los demás ya que todos los
integrantes son libres de interactuar con todas las partes del código

8. FASES DE XP
1. Planificación
• Historias de usuario
• Plan de entregas
• Velocidad del proyecto
• Iteraciones
• Rotaciones
• Reuniones
1. Desarrollo
• Disponibilidad del cliente
• Unidad de pruebas
• Programación por parejas
• Integración
1. Diseño
• Metáforas del sistema
• Tarjetas CRC
• Soluciones puntuales
• Funcionalidad mínima
• Reciclaje
1. Pruebas
• Implantación
• Pruebas de aceptación

9. HISTORIAS DE USUSARIO
Tiene el mismo propósito que los casos de uso, siendo pequeñas descripciones
sin mucho nivel de detalle escritas por el cliente en el que dice que quiere del
programa y como lo quiere, estas deben de ser entendibles para todo el equipo
y conllevaran al proceso de creación de los tests de implementación.