Programación Extrema (XP)

“La Programación Extrema o Extreme Programming es una de las metodologías de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained. Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad” (Pressman, 2010, pág. 61).

“Aunque las primeras actividades con las ideas y los métodos asociados a XP ocurrieron al final de la década de 1980, el trabajo fundamental sobre la materia había sido escrito por Kent Beck. Una variante de XP llamada XP industrial se propuso en una época más reciente. IXP mejora la XP y tiene como objetivo el proceso ágil para ser usado específicamente en organizaciones grandes”

(Pressman, 2010, pág. 61).

La meta principal de la XP es la satisfacción del cliente. Se le trata de proporcionar a los clientes lo que desean y para cuando los quieren. Por lo tanto, se debe responder inmediatamente a los cambios que el cliente realiza en cualquier momento de la elaboración del proyecto.

2.2.6.1. Características generales de XP

Una de las características más importante de XP que comparte con algunas metodologías ágiles “Es que de alguna manera representa la antítesis de lo que es el tradicional proceso de desarrollar un software. XP es deliberadamente una metodología “liviana” que pasa por alto la utilización de elaborados casos de uso, la exhaustiva definición de requerimientos y la producción de una extensa documentación. Todo lo anterior puede parecer caótico según el enfoque tradicional de la ingeniería de software, aunque no hay que olvidar que XP tiene asociado un ciclo de vida y es considerado a su vez un proceso” (Gonzáles Campos

& Fernándes Martínez, 2006, pág. 56).

“La tendencia de entregar software en lapsos cada vez menores de tiempo y con exigencias de costos reducidos y altos estándares de calidad, hace

20 que XP sea una opción a considerar. En términos generales XP parece ser una metodología adecuada para proyectos medianos y pequeños, donde los equipos de desarrollo no pasan de 10 programadores y donde la constante es que los requerimientos cambien, a veces radicalmente, durante la etapa de desarrollo” (Gonzáles Campos & Fernándes Martínez, 2006, pág. 56).

“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. Por esto, se trata de realizar ciclos de desarrollo cortos, con entregables funcionales al finalizar cada ciclo. La siguiente figura esquematiza los ciclos de desarrollo en cascada, iterativos comparados con el de XP” (Joskowicz, 2018).

Figura 4 Ciclos de desarrollo en cascada, iterativos y XP Fuente: Tomada de (Joskowicz, 2018)

Elaboración: Propia

En la Figura 4 se puede observar que la programación extrema (XP) es un hibrido de cascada y de iterativo, en cada ciclo se realiza un periodo completo de análisis, de diseño, desarrollo y pruebas, pero utilizando un conjunto de normas y prácticas que le caracterizan a XP.

2.2.6.2. Valores en XP

“En el desarrollo de una idea de software, los cambios serán algo inevitables, los requerimientos cambiarán, las reglas del negocio, el equipo de trabajo y la tecnología, entre otros elementos involucrados en el proyecto. Por esta

21 razón XP propone valores, que permitirán afrontar y sortear de una manera más efectiva los cambios en el proyecto” (Perez A., 2011).

En la siguiente figura se muestra los cuatro valores esenciales, que deben estar presentes en el equipo de desarrollo para que el proyecto tenga éxito.

Figura 5. Los Cuatro valores esenciales en XP Fuente: (Beck, 2005)

Elaboración: Propia

A continuación se describen los valores de acuerdo con la propuesta original de Beck.

 Simplicidad: Los programadores se interesan por desarrollar el código muy simple aumentando el valor del software.

 Comunicación: Todos laboran en conjunto a lo largo del proyecto.

 Retroalimentación: Mejorar el software después de las entregas con los nuevos requisitos.

 Coraje: Responder a los cambios quesucedan.

2.2.6.3. Las 12 Prácticas de XP

“La metodología XP especifica ciertas prácticas concretas de programación que deben llevarse a cabo al implementar este modelo. Estas prácticas deben ser coherentes con los valores fundamentales y los principios básicos mencionados anteriormente. Estas prácticas de programación son las siguientes” (Gonzáles Campos & Fernándes Martínez, 2006).

22 Figura 6. Las 12 Prácticas de XP

Fuente: (Beck, 2005) Elaboración: Propia

En la Figura 6 se observa las doce prácticas de XP propuesto por Kent Beck en su primera edición del libro con que presenta la metodología XP.A continuación se describen cada una de ellas.

 La planeación: El cliente y el equipo de desarrollo interactúan para obtener los requerimientos del software.

 Iteraciones pequeñas: La implementación del software se divide en partes para facilitar su ejecución.

 Manejo de metáforas: Ayuda a que los desarrolladores comprendan el funcionamiento del sistema.

 Diseño simple: Tener el código lo más simple posible.

 Pruebas continuas: Los programadores realizan pruebas para revisar el buen funcionamiento del programa y el cliente participe en pruebas funcionales.

 Refactorización: Buscar la manera de hacer lo más simple sin que pierda su funcionalidad.

 Programación en parejas: Todo el código se escribe en parejas de programadores, uniendo sus conocimientos y experiencia.

 Propiedad colectiva del código: No existe propietario del código, cualquiera puede hacer cambios en el código.

23

 Integración contínua: El código se debe integrar y probar sobre la totalidad del sistema cada un día como minimo.

 Semana de 40 horas: XP afirma que las condiciones de trabajo óptimo es de 40 horas a la semana. Las horas extras o fines de semana trabajados solo desgastan al equipo de programación.

 El cliente debe estar disponible localmente: El cliente debe sentarse con los desarrolladores, estar disponible para contestar a su pregunta y ayudar en el desarrollo de pruebas funcionales.

 Estándares de codificación: Establecer los estándares de codificación aprobado por los desarrolladores.

2.2.6.4. Roles XP

“Los miembros de un equipo trabajan mejor cuando hay roles establecidos, cada rol tiene consigo responsabilidades que tienen como finalidad cumplir con los objetivos del proyecto. Algunos proyecto necesitan de múltiples roles como tésteres o probadores, ingenieros de calidad, analista de requerimientos, administrador del proyecto, administrador del producto, profesionales de marketing. El número de roles varía de acuerdo con el proyecto” (Perez A., 2011).

En la Figura 7 se visualiza los roles de la Programación Extrema. A continuación, se describen cada una ellas.

Figura 7. Los Roles de la Programación Extrema Fuente: (Beck, 2005)

Elaboración: Propia

24

 Programador: “Una vez que se han comprendido las historias de usuario, el XP adjudica a los programadores la responsabilidad de tomar decisiones técnicas. Los desarrolladores estiman el tiempo que les va a tomar cada historia. Escribe las pruebas unitarias y produce el código del sistema” (Perez A., 2011).

 Cliente: “Es el responsable de escribir historias de usuarios y determinar las pruebas funcionales que validan su implementación.

Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. El cliente es el responsable de conducir el proyecto. Define el proyecto y sus objetivos. Cuanto más preciso es su trabajo y cuanto mayor sea su involucración, mayores serán las oportunidades de éxito”

(Perez A., 2011).

 Encargado de pruebas (Tester): “Realiza las pruebas funcionales, colabora con el cliente para establecer y registrar las pruebas de aceptación de historias del usuario. Este rol en un equipo XP también es responsable realizar test periódicamente e informar de los resultados al equipo. A medida que el volumen de pruebas aumenta, el encargado de pruebas necesitará una herramienta para crear y mantener la batería de pruebas, ejecutarlas y obtener los resultados más rápidamente”

(Perez A., 2011).

 Encargado de seguimiento (Tracker): “Hace el seguimiento de acuerdo a la planificación. La métrica más importante para XP es la velocidad del equipo, que se define como el tiempo ideal estimado para las tareas frente al tiempo real dedicado. Esta métrica ayuda a determinar si el proyecto está dentro del tiempo de la reiteración” (Perez A., 2011).

 Entrenador o Coach: “Tiene a su cargo la gestión de todo el proceso en su conjunto. Su función es facilitar al equipo guías para que se apliquen en las prácticas XP de manera que el proceso siga correctamente” (Perez A., 2011).

 Consultor. “Es un integrante externo al equipo con conocimiento de un tema específico y transfiere sus conocimientos a los miembros del equipo para que resuelvan el problema” (Perez A., 2011).

 Gestor o “Big boss”: “Es el nexo de programadores con clientes que, es la persona que asiste a las reuniones del equipo, asegura que se sigue el proceso de reunión acordado y toma nota de los resultados de

25 la reunión, que luego son entregados al tracker. Es el gerente del proyecto, debe tener una idea general del proyecto y estar familiarizado con su estado. El cliente puede asumir este papel” (Perez A., 2011).

2.2.6.5. Artefactos XP

En toda fase de desarrollo de software se origina prototipos de información.

“En XP se generan varios artefactos como las tarjetas de historias de usuario, las tarjetas de tareas para la descarga de documentos, el código, las pruebas unitarias y de integración y las pruebas de aceptación. Los artefactos son importantes para conocer cuál fue el proceso de desarrollo del software y lograr entender cómo está construido el sistema, así como la ruta a seguir para agregar funcionalidad al sistema” (Perez A., 2011).

A. Historias de Usuarios: “Representan una breve descripción del comportamiento del sistema, emplea terminología del cliente sin lenguaje técnico, se realiza una por cada característica principal del sistema, se emplean para hacer estimaciones de tiempo y para el plan de lanzamientos, reemplazan un gran documento de requisitos y presiden la creación de las pruebas de aceptación” (Perez A., 2011).

La Plantilla a utilizarse para la elaboración de las historias de usuario se muestra en la Figura 8.

Figura 8 Modelo de Tarjeta: Historia de Usuario Fuente: (Perez A., 2011)

Elaboración: Propia

“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. Las historias de usuario son más “amigables” que los casos de uso formales” (Perez A., 2011).

26 Las Historias de Usuario tienen tres aspectos:

a. Tarjeta: en ella se almacena suficiente información para identificar y detallar la historia.

b. Conversación: Cliente y programadores discuten la historia para ampliar los detalles.

c. Pruebas de Aceptación: Permite confirmar que la historia ha sido implementada correctamente. La Figura 9 muestra la plantilla a utilizarse para la elaboración de las pruebas de aceptación y cada uno de sus componentes.

Figura 9 Modelo de Tarjeta: Prueba de Aceptación Fuente: (Perez A., 2011)

Elaboración: Propia

B. Task Card (Tareas de ingeniería): “Dichas tarjetas tienen como fin identificar las tareas, llevar un registro de inicio y fin, dejar constancia de quién es el encargado del trabajo, el tipo de tarea, junto a una breve descripción y los puntos estimados que costará llevarla a cabo. En la Figura 10 se muestra el formato a utilizarse para su elaboración” (Perez A., 2011).

Figura 10 Modelo de Tarjeta: Tarea de Ingeniería Fuente: (Perez A., 2011)

Elaboración: Propia

C. Tarjetas CRC (Clase-Responsabilidad-Colaborador): “Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la

27 clase, sus responsabilidades y sus colaboradores. En la Figura 11 se muestra cómo se distribuye esta información” (Perez A., 2011).

Figura 11 Modelo de Tarjeta: CRC Fuente: (Perez A., 2011)

Elaboración: Propia

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte.

Las responsabilidades de una clase son las cosas que conoce y las que realizan, sus atributos y métodos. Los colaboradores de una clase son las demás clases con las que trabaja en conjunto para llevar a cabo sus responsabilidades.