Skip to Content

eXtremme Programing

Este post estará dedicado a presentar algúnos tópicos que encontramos al utilizar la programación extrema como metodología para el desarrollo de aplicaciónes, amplimente utilizada en este tiempo, por ser agil, flexible y no exigir una documentación ampulosa y estricta.

eXtreme Programming (XP) es una metodología ágil de de desarrollo de software que fue propuesta por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre. A continuación se presenta las características especiales de XP. Esta metodología define cuatro variables para proyectos de software: coste, tiempo, calidad y ámbito. Beck propone que sólo tres puedan ser establecidas por las fuerzas externas (jefes de proyecto y clientes), mientras que el valor de la cuarta variable debe ser establecido por los programadores en función de las otras tres. Adicionalmente esta metodología promueve cuatro valores: comunicación, la comunicación directa entre personas; coraje, se debe de tener el coraje de exponer dudas, miedos, experiencias sin "embellecer" éstas de ninguna de las maneras; simplicidad, programación extrema intenta mantener el software lo más sencillo posible; feedback, el feedback se toma del cliente, de los miembros del equipo, en cuestión de todo el entorno en el que se mueve un equipo de desarrollo ágil.

1.1 Principios Básicos
La Programación Extrema se basa en 12 principios básicos agrupados en cuatro categorías:

Retroalimentación a escala fina.
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.
Proceso de planificación: el usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema. Se creará un documento llamado Historias del usuario (User Stories), Estas deben proporcionar sólo el detalle suficiente como para poder hacer razonable la estimación de cuánto tiempo requiere la implementación de la historia, difiere de los casos de uso porque son escritos por el cliente, no por los programadores, empleando terminología del cliente.
El cliente in-situ (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. Programación en parejas: requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina.
Proceso continuo en lugar de por lotes.
Integración continua: permite al equipo hacer un rápido progreso implementando las nuevas características del software.
Refactorización: permite a los equipos de programadores XP mejorar el diseño del sistema a través de todo el proceso de desarrollo.
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.
Entendimiento compartido.
Diseño simple: se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos.
Metáfora: La metáfora expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema, debe comunicar intensiones y resultar descriptivas, enfatizando el qué por delante del como. Las tarjetas CRC (Clase, Responsabilidad y Colaboración) también ayudarán al equipo a definir actividades durante el diseño del sistema. Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la clase, sus responsabilidades y sus colaboradores.
Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo.
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.
Bienestar del programador.
La semana de 40 horas: la programación extrema sostiene que los programadores cansados escriben código de menor calidad.
Todas estas prácticas son y fueron utilizadas en el pasado y presente pero XP las integra de una forma efectiva y las complementa con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.
1.2 Fases del proceso XP
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
1.El cliente define el valor de negocio a implementar.
2.El programador estima el esfuerzo necesario para su implementación.
3.El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
4.El programador construye ese valor de negocio.
5.Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración.
Según Beck El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.
Fase I: Exploración
En esta fase, los clientes plantean las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.
Fase II: Planificación de la Entrega
En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos días.
Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración.
Fase III: Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en producción.
Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración anterior. Todo el trabajo de la iteración es expresado en tareas de programación, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores.
Fase IV: Producción
La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase.
Fase V: Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.
Fase VI: Muerte del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.