Algunas interrogantes sobre XP

 El siguiente artículo responde interrogantes acerca de la metodología XP.

Las preguntas fueron realizadas por compañeros de la clase Gestión de Calidad de Software del Diplomado de de la Universidad Gabriel René Moreno, cabe recalcar que las preguntas a continuación están escritas tal cual fueron redactadas.

1.      ¿Cuál es la disposición  física u orden de trabajo como deberían de estar organizados?

XP propone involucrar a todo el equipo a lo largo de todo el desarrollo del proyecto. Esto requiere una disposición física de los integrantes del equipo muy cercana, de modo que la prácticamente toda la comunicación sea verbal. El objetivo es que el tiempo que transcurre entre que se realiza una pregunta y esta es respondida sea casi cero, así como que haya comunicación total entre todos los integrantes del equipo.

XP también propone la Programación en pares: Esta técnica consiste en que el trabajo de implementación debe ser realizado por dos programadores sentados en la misma máquina. Uno de los programadores se dedica a escribir el código, compartiendo ideas con el otro, que se dedica a diseñar como debería implementarse el código, siempre desde una perspectiva más alejada que el que está escribiendo el código. Esta práctica alienta a los programadores a esforzarse en realizar la tarea actual, diseminando el conocimiento por todo el equipo, especialmente si se cambian los pares frecuentemente.

A continuación algunos escenarios de trabajo en XP:

2.      ¿Qué elementos actuarían de manera negativa a la aplicación de esta metodología en el contexto local?

Esta metodología propone :

40 horas por semana: Esta práctica establece que se debe trabajar un máximo de 40 horas por semana. No se deben asimismo trabajar horas extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificación para cambiar el ámbito del proyecto o la fecha de entrega.

Programación en pares: Esta técnica consiste en que el trabajo de implementación debe ser realizado por dos programadores sentados en la misma máquina. Uno de los programadores se dedica a escribir el código, compartiendo ideas con el otro, que se dedica a diseñar como debería implementarse el código, siempre desde una perspectiva más alejada que el que está escribiendo el código. Esta práctica alienta a los programadores a esforzarse en realizar la tarea actual, diseminando el conocimiento por todo el equipo, especialmente si se cambian los pares frecuentemente.

Cliente on-site: En esta práctica se establece que el cliente debe estar presente y disponible en todo momento para el equipo de desarrollo. Gran parte del éxito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio y de esta forma, los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicación oral es más efectiva que la escrita, ya que esta última toma mucho tiempo en generarse y puede tener más riesgo de ser mal interpretada.

Las anteriores prácticas representan en cierta forma una desventaja en el contexto actual debido a que en nuestra sociedad es difícil realizar cambios de lo tradicional a algo más radical como la programación en parejas que requiere el esfuerzo de dos personas en una misma tares, también cabe recalcar que la ley general del trabajo establece 48 horas de trabajo semanal  dicha norma está bastante arraigada en las empresas privadas en Bolivia (con algunas excepciones por supuesto), y con respecto a las disponibilidad del cliente esta es una práctica que podría ser un problema en nuestro medio ya que la mayoría de los mismos no disponen de tiempo y no comprenden a cabalidad la importancia de esta práctica.

3.      ¿XP cumple con los requisitos que estipula la norma ISO 9000, en su apartado de desarrollo de software?

Relacion entre XP y ISO 9000:

Características de aplicación del software

ISO:

- Software predecible, estable, confiable y de alta calidad.

- Por lo regular hay grandes equipos y proyectos.

- Requerimientos y proyectos con estabilidad.

XP:

- Software que es capaz de responder rápidamente a requerimientos cambiantes.

- Pequeños y medianos equipos al igual que los proyectos.

- Requerimientos y proyectos inestables.

Características de gestión

ISO:

- Los clientes se enfocan en negociaciones.

- Compartimiento y transferencia del conocimiento explícita, con documentación.

XP:

- Usuarios enfocados en prioridades.

- Compartimiento y transferencia del conocimiento tácita, sin mucha documentación.

Características técnicas

ISO:

- Definición de requerimientos formales y documentación formal de los mismos.

- Diseños grandes, iteraciones largas y refactorización tardía.

- Plan de pruebas documentado con procedimientos formales.

XP:

- Definición informal de requerimientos, por medio de las historias de usuario.

- Diseño simple que responde a las necesidades del cliente, con iteraciones pequeñas y constante refactorización.

- Pruebas frecuentes, plan de pruebas antes de la codificación por último la ejecución de las pruebas.

Características de las personas

ISO:

- Los clientes no están con los desarrolladores en la mayoría de los casos.

- La experiencia de los desarrolladores es importante solamente al inicio del proyecto.

- Libertad limitada, enfocada en procesos. Caracterizada por el orden.

XP:

- Los clientes están comprometidos con los desarrolladores.

- Desarrolladores con experiencia desde el inicio hasta el final del proyecto.

- Cultura de empoderamiento, libertad, enfocado en las personas, caracterizada por el caos.

4.      Dar un ejemplo de algún proyecto en particular que utilice metodología XP

Repo Margining System

Este  sistema debería permitir el comercio a través de un “navegador” y mantener informadas a ambas partes del trato. Además capturará las ofertas que se hagan y las mostrará en un margen especialmente dedicado a ello.

Las siguientes prácticas de la metodología XP fueron usadas por completo: The Planning Game, versiones pequeñas, sistema metamórfico, diseños simples, creación del conjunto de pruebas antes de la codificación, Refactoring, Programación en parejas, Propiedad colectiva del código, estándares de codificación. Aunque el cliente no estuvo presente siempre se mantuvo la comunicación con el en todo momento. Las 40 horas semanales fueron ampliadas a 50 horas semanales por decisión conjunta de todo el grupo de las cuales 14 se dedicaron a estudiar e informarse del entorno de desarrollo.

Resultados obtenidos:

El trabajo estuvo concluido en 4 iteraciones, lo que llevó 7 semanas. El sistema tomó forma a partir de la tercera iteración. El propósito de desarrollar bien, rápido y barato fue progresivamente considerado como posible. Los errores que se cometieron fueron mínimos y resueltos con facilidad.

5.      ¿Cuáles son los artefactos resultantes de la aplicación de XP como metodología de desarrollo?

Artefactos en XP

Historias del Usuario
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.

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".

Las Historias de Usuario tienen tres aspectos:
Tarjeta: en ella se almacena suficiente información para identificar y detallar la historia.
Conversación: cliente y programadores discuten la historia para ampliar los detalles
(verbalmente cuando sea posible, pero documentada cuando se requiera confirmación)
Pruebas de Aceptación: permite confirmar que la historia ha sido implementada
correctamente.

Task Card (tarea de ingeniería)
Las task card se usan para describir las tareas que se realizan sobre el proyecto.
Las tareas pueden ser: desarrollo, corrección, mejora, etc.
Estas tareas tienen relación con una historia de usuario; se especifica la fecha de inicio y
fin de la tarea, se nombra al programador responsable de cumplirla y describimos que se
tratara de hacer en la tarea.

Tarjeta CRC
Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la
clase, sus responsabilidades y sus colaboradores. En ellas se expresa el diseño del
sistema, la sencillez de esta tarjeta hace que del diseño una tarea fácil.

Clase: Cualquier persona, cosa, evento, concepto, pantalla o reporte.

Responsabilidades: son las cosas que conocen y las que realizan, sus atributos y
métodos.

Colaboradores: son las demás clases con las que trabaja en conjunto para llevar a cabo
sus responsabilidades.

Tarjeta CRC  Metáforas del sistema   Es útil generar metáforas que expliquen características del sistema comparándolo con conceptos sencillos. Por ejemplo, un sistema que utilice colas se puede comparar con una cafetería con una sola fila.

6. ¿Bajo qué condiciones no se recomendaría usar la  metodología XP?

No se recomendaría usar XP:

·         Cuando no sea posible involucrar al cliente en el desarrollo del software, es decir que este no puede participar en el desarrollo activamente.

·         Cuando el equipo de desarrollo tiene problemas para ajustarse a los principios y prácticas de la metodología. 

·         Cuando el proyecto es de gran escala,  que requerirán mucho personal, a menos que se subdivida en proyectos más pequeños.