eXtreme programming

La metodología XP define cuatro variables para cualquier proyecto de software: costo, tiempo, calidad y alcance. Además, se especifica que, de estas cuatro variables, sólo tres de ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes de proyecto). El valor de la variable restante podrá ser establecido por el equipo de desarrollo, en función de los valores de las otras tres. Este mecanismo indica que, por ejemplo, si el cliente establece el alcance y la calidad, y el jefe de proyecto el precio, el grupo de desarrollo tendrá libertad para determinar el tiempo que durará el proyecto. Este modelo es analizado por Kent Beck, donde propone las ventajas de un contrato con alcances opcionales.

El ciclo de vida de un proyecto XP incluye, al igual que las otras metodologías, entender lo que el cliente necesita, estimar el esfuerzo, crear la solución y entregar el producto final al cliente. Sin embargo, XP propone un ciclo de vida dinámico, donde se admite expresamente que, en muchos casos, los clientes no son capaces de especificar sus requerimientos al comienzo de un proyecto. 

Fase de exploración

Es la fase en la que se define el alcance general del proyecto. En esta fase, el cliente define lo que necesita mediante la redacción de sencillas “historias de usuarios”. Los programadores estiman los tiempos de desarrollo en base a esta información. Debe quedar claro que las estimaciones realizadas en esta fase son primarias (ya que estarán basadas en datos de muy alto nivel), y podrían variar cuando se analicen más en detalle en cada iteración. Esta fase dura típicamente un par de semanas, y el resultado es una visión general del sistema, y un plazo total estimado.

Fase de planificación

La planificación es una fase corta, en la que el cliente, los gerentes y el grupo de desarrolladores acuerdan el orden en que deberán implementarse las historias de usuario, y, asociadas a éstas, las entregas. Típicamente esta fase consiste en una o varias reuniones grupales de planificación. El resultado de esta fase es un Plan de Entregas, o “Release Plan”, como se detallará en la sección “Reglas y Practicas”.

Fase de iteraciones

Esta es la fase principal en el ciclo de desarrollo de XP. Las funcionalidades son desarrolladas en esta fase, generando al final de cada una un entregable funcional que implementa las historias de usuario asignadas a la iteración. Como las historias de usuario no tienen suficiente detalle como para permitir su análisis y desarrollo, al principio de cada iteración se realizan las tareas necesarias de análisis, recabando con el cliente todos los datos que sean necesarios. El cliente, por lo tanto, también debe participar activamente durante esta fase del ciclo. Las iteraciones son también utilizadas para medir el progreso del proyecto. Una iteración terminada sin errores es una medida clara de avance. 

Fase de puesta en producción

Si bien al final de cada iteración se entregan módulos funcionales y sin errores, puede ser deseable por parte del cliente no poner el sistema en producción hasta tanto no se tenga la funcionalidad completa. En esta fase no se realizan más desarrollos funcionales, pero pueden ser necesarias tareas de ajuste (“fine tuning”).  

Roles 

Programador

• Pieza básica en desarrollos XP
• Más responsabilidad que en otros modos de desarrollo
• Responsable sobre el código
• Responsable sobre el diseño (refactorización, simplicidad)
• Responsable sobre la integridad del sistema (pruebas)
• Capacidad de comunicación
• Acepta críticas (código colectivo)

Cliente

• Pieza básica en desarrollos XP
• Define especificaciones
• Influye sin controlar
• Confía en el grupo de desarrollo
• Define pruebas funcionales

Encargado de Pruebas

• Apoya al cliente en la preparación/realización de las pruebas funcionales
• Ejecuta las pruebas funcionales y publica los resultados

   

Encargado de Seguimiento (Tracker)

• Recoge, analiza y publica información sobre la marcha del proyecto sin afectar demasiado el proceso
• Supervisa el cumplimiento de las estimaciones en cada iteración
• Informa sobre la marcha de la iteración en curso
• Controla la marcha de las pruebas funcionales, de los errores reportados, de las responsabilidades aceptadas y de las pruebas añadidas por los errores encontrados

Entrenador (Coach)

• Experto en XP
• Responsable del proceso en su conjunto
• Identifica las desviaciones y reclama atención sobre las mismas
• Guía al grupo de forma indirecta (sin dañar su seguridad ni confianza)
• Interviene directamente si es necesario
• Atajar rápidamente el problema

Consultor

• Apoya al equipo XP en cuestiones puntuales

Jefe del Proyecto

• Favorece la relación entre usuarios y desarrolladores
• Confía en el equipo XP
• Cubre las necesidades del equipo XP
• Asegura que alcanza sus objetivos

Objetivos

• Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos.
• Mejorar la productividad de los proyectos.
• Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.

Ventajas

• Programación organizada.
• Menor taza de errores.
• Satisfacción del programador.

Desventajas

• Es recomendable emplearlo solo en proyectos a corto plazo.
• Altas comisiones en caso de fallar.

Características

• Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
• Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.
• Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe es más importante que la posible pérdida de productividad inmediata.
• Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
• Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
• Refactorización del código, es decir, rescribir 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.
• 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. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
• 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. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
• La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.