METODOLOGÍA PROGRAMACIÓN EXTREMA (XP)

1. PRINCIPIOS BASICOS LOS CIASUALES SON 12 PRINCIPALES DIVIDIDOS EN CUATRO CATEGORIAS

1.1. RETROALIMENTACION A ESCALA FINA

1.1.1. 1. El principio de pruebas: se tiene que establecer un período de pruebas de aceptación del programa (llamado también período de caja negra) donde se definirán las entradas al sistema y los resultados esperados de estas entradas.

1.1.2. 2. Proceso de planificación: en esta fase, el usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema.

1.1.3. 3. El cliente en el sitio: se le dará poder para determinar los requerimientos, definir la funcionalidad, señalar las prioridades y responder las preguntas de los programadores. Esta fuerte interacción cara a cara con el programador disminuye el tiempo de comunicación y la cantidad de documentación, junto con los altos costes de su creación y mantenimiento.

1.1.4. 4. Programación en parejas: uno de los principios más radicales y en el que la mayoría de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina.

1.2. PROCESO CONTINUO EN LUGAR DE POR LOTES

1.2.1. 1. Integración continua: permite al equipo hacer un rápido progreso implementando las nuevas características del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su código y reconstruir el sistema varias veces al día.

1.2.2. 2. Refactorización: permite a los equipos de programadores XP mejorar el diseño del sistema a través de todo el proceso de desarrollo. Los programadores evalúan continuamente el diseño y recodifican lo necesario.

1.2.3. 3. Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se actualiza de forma rápida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como máximo.

1.3. ENTENDIEMIENTO COMPARTIDO

1.3.1. 1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos.

1.3.2. 2. Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia de cómo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language).

1.3.3. 3. Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo.

1.3.4. 4. Estándar de codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos.

1.4. BIENESTAR DEL PROGRAMADOR

1.4.1. 1. La semana de 40 horas: la programación extrema sostiene que los programadores cansados escriben código de menor cualidad.

2. PROCESO DE DESARROLLO

2.1. La programación extrema parte del caso habitual de una compañía que desarrolla software normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o diseño), uno de desarrollo y los clientes finales

2.2. La relación entre el equipo de diseño, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologías tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validación posterior al mismo.

3. ITERACCION CON EL CLIENTE

3.1. En este tipo de programación el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificación.

3.2. Tiene un papel importante de interacción con el equipo de programadores, sobre todo después de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de programación existirán pruebas de aceptación de la programación que ayudarán a que su labor sea lo más provechosa posible.

4. DEFINICION

4.1. Es una metodología de desarrollo ligero (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.

5. CARACTERISTICAS

5.1.  Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

5.2.  Pruebas unitarias: frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.

5.3.  Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto.

5.4.  Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

5.5.  Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la Refactorización no se ha introducido ningún fallo.

5.6.  Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario.

5.7.  Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto.

6. PLANIFICACION DEL PROYECTO

6.1. En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán diferentes iteraciones. Para hacerlo será necesaria la existencia de reglas que se han de seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se sientan realmente partícipes de la decisión tomada.

7. DISEÑO, DESARROLLO Y PRUEBAS

7.1. El desarrollo es la parte más importante en el proceso de la programación extrema. Todos los trabajos tienen como objetivo que se programen lo más rápidamente posible, sin interrupciones y en dirección correcta.

7.2. También es muy importante el diseño, y se establecen los mecanismos, para que éste sea revisado y mejorado de manera continuada a lo largo del proyecto, según se van añadiendo funcionalidades al mismo.

7.3. Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir: Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir una prueba sencilla, y después escribir el código para que la pase.