Programación Extrema y Test Driver Development

PROGRAMACION EXTREMA (XP) Y TEST DRIVEN DEVELOPMENT

(TDD)
Diego José Elías Anaya
e-mail: dj.ebest@gmail.com
Ricardo Antonio Merino Escobar
e-mail: mericardoa@gmail.com
Kirio Waldo Portillo Mendoza
e-mail: kirio.pm@gmail.com
Bayron Francomar Rivera Ríos
e-mail: bayfran8@gmail.com
Jaime Gabriel Valle Chacón
e-mail: sk8jaime@hotmail.com

RESUMEN: El desarrollo de software no es una 2 OBJETIVOS

tarea fácil. Prueba de ello es que existen numerosas
propuestas metodológicas que inciden en distintas
dimensiones del proceso de desarrollo. Test Driven
Development, o TDD como se lo conoce más a menudo,
es un proceso de desarrollo de software que se basa en
la idea de desarrollar pruebas, codificar y refactorizar el
código construido. Programación Extrema (eXtreme
Programming, XP) es una de las llamadas metodologías
ágiles de desarrollo de software más exitosas de los
últimos tiempos. En este trabajo se presenta un resumen
de las características más destacables de esta
metodología, incluyendo las fases de su ciclo de vida
PALABRAS CLAVE: Desarrollo ágil, Programación
Extrema, Test Driven Development.
1 INTRODUCCIÓN
Hace varios años las empresas desarrolladoras de
software creían que la parte más importante a la hora de
construir una solución era contar con un modelado
eficiente y las ultimas herramientas CASE que existían en
el mercado, pero con el paso del tiempo entendieron que
esto no era suficiente si no se contaba con un buen
desarrollo del proyecto, el cual asegurara un software de
calidad y satisfacción del cliente. Debido a esto ahora hoy
en día ha nacido un creciente interés por las
metodologías de desarrollo de software que agilicen el
tiempo de desarrollo y garanticen el uso eficiente de los
recursos, aplicadas tanto para empresas grandes con
numerosos procesos como a empresas pequeñas que no
cuentan con muchas herramientas para llevar a cabo los
proyectos. Se presentara resumidamente el contexto en
el que surgen las metodologías ágiles, sus
características, principios y comparaciones con las
metodologías tradicionales. Además se describe con
mayor detalle Programación Extrema (extreme
Programming, XP) la metodología ágil más popular en la
actualidad y el Test Driven Development (TDD).
2.1 OBJETIVO GENERAL
Investigar las metodologías agiles programación
extrema y Test Driven Development que se utilizan en el
desarrollo de software.
2.2 OBJETIVOS ESPECIFICOS
 Identificar las características más destacables
de las metodologías programación extrema y el
Test Driven Development.
 Conocer las fases en las que se desarrolla la
metodología Test Driven Development.
 Dar un panorama sobre los beneficios que
ofrece la metodología Programación Extrema
(XP).
 Explicar los artefactos esenciales que nos
proporciona la metodología Programacion
Extrema
3 METODOLOGIA AGIL
Los procesos ágiles son una buena elección cuando
trabajamos con requisitos desconocidos o variables. Si no
existen requisitos estables, no existe una gran posibilidad
de tener un diseño estable y de seguir un proceso
totalmente planificado, que no vaya a variar ni en tiempo
ni en dinero. En estas situaciones, un proceso adaptativo
será mucho más efectivo que un proceso predictivo. Por
otra parte, los procesos de desarrollo adaptativos también
facilitan la generación rápida de prototipos y de versiones
previos a la entrega final, lo cual agradará al cliente. Pero
la mayor barrera que habrá que salvar será convencer al
cliente de que no existe una planificación y una forma fija
de hacer las cosas. En cualquier caso, lo que se garantiza
es un menor riesgo ante la posibilidad de cambios en los
requisitos. Porque los cambios existen, y los procesos
adaptativos permitirán estos cambios lo que en definitiva,

1
Programación Extrema y Test Driver Development
.
garantizará que el producto final sea el deseado por el
cliente. Según afirma Booch (2001), todas estas razones
son las que hacen que los procesos indicados por las
comunidades de Extreme Programming y de Open
Source hayan suscitado tanto interés. [1]
Figura 1. Desarrollo utilizando metodología ágil.
4 DESARROLLO GUIADO POR
PRUEBAS (TDD).
Es una técnica de ingeniería de software que
involucra dos prácticas las cuales son: Escribir primero
las pruebas y Refactorización. Para escribir las pruebas
generalmente se utilizan las pruebas unitarias. Primero se
escribe una prueba y se verifica que las pruebas fallan.
Luego se implementa el código que hace que la prueba
pase satisfactoriamente y se refactoriza el código escrito.
El propósito del desarrollo guiado por pruebas es lograr
un código limpio que funcione. La idea es que los
requisitos sean traducidos a pruebas, de este modo,
cuando las pruebas pasen se garantizará que el software
cumple con los requisitos que se han establecido.
Esta técnica se centra en tres pilares
fundamentales:
 La implementación de las funciones justas que
el cliente necesita y no más.
 La minimización del número de defectos que
llegan al software en fase de producción.
 La producción de software modular, altamente
reutilizable y preparado para el cambio.
Esta técnica es realmente una herramienta de
diseño que convierte al programador en desarrollador. La
cual es de gran utilidad a la hora de dar respuesta a las
siguientes preguntas:
¿Cómo lo hago?, ¿Por dónde empiezo?, ¿Cómo sé
qué es lo que hay que implementar y lo que no?, ¿Cómo
escribir un código que se pueda modificar sin romper
funcionalidad existente? [2]
4.1 COMO AFRONTAR TDD
Se debe elegir uno de los requisitos a implementar,
buscar un primer ejemplo sencillos del requisito, crear una
2
prueba unitaria, ejecutar la prueba para, implementar el
código mínimo para superar la prueba y ejecutar de nuevo
la prueba para ver que se supera.
Lo que se desea conseguir al ejecutar la prueba
después de crearla es ver que esta falla y que será
necesario hacer algo en el código para que este pase, y
así solo será necesario volver a aplicar el proceso descrito
anteriormente hasta haber resuelto la funcionalidad o
funcionalidades que se debían implementar.
Una vez pasada la prueba es necesario revisar el
código, por si requiere refactorizar. Si este fuese el caso,
se revisará, corregirá y se ejecutaran las pruebas
unitarias, de nuevo.
Se debe tener presente que solo se crea un test por
iteración y solo se implementa el código mínimo necesario
para resolver ese caso. No es correcto implementar y
desarrollar más de lo necesario para resolver el caso de
prueba ya que se perderá una gran parte de la eficacia de
este método. [3]
4.2 CICLOS DE DESARROLLO DE TDD
 Elegir un requisito a desarrollar: Se elige de
una lista el requisito que se cree que nos dará
mayor conocimiento del problema y que a la vez
sea fácilmente implementable.
 Crear la prueba o test: Se comienza
escribiendo una prueba para el requisito. Para
ello el programador debe entender las
especificaciones y los requisitos de la
funcionalidad que está por implementar. Esto
fuerza al programador a tomar la perspectiva de
un cliente considerando el código a través de sus
interfaces.
 Ejecutar los tests: falla (ROJO): Si la prueba
no falla es porque el requisito ya estaba
implementado o porque la prueba es errónea.
 Crear código específico para resolver el test:
Escribir el código más sencillo que haga que la
prueba funcione.
 Ejecutar de nuevo los tests: pasa (VERDE):
Verificar si todo el conjunto de pruebas funciona
correctamente.
 Refactorizar el código: se utilizará
principalmente para eliminar código duplicado.
Se hace un pequeño cambio cada vez y luego
se corren las pruebas hasta que funcionen.
 Ejecutar los tests pasa (VERDE): Se actualiza
la lista de requisitos tachando el requisito
implementado. Asimismo se agregan requisitos
que se hayan visto como necesarios durante
este ciclo y se agregan requisitos de diseño.
Programación Extrema y Test Driver Development
.
Figura 2. Ciclos de desarrollo de TDD
4.2.1 TEST
Las pruebas se escriben antes de escribir el propio
código, y las mismas son escritas por los propios
desarrolladores, esto busca que los mismos logren un
entendimiento de lo que deben desarrollar mediante la
construcción del código que lo va a probar.
4.2.2 CODIGO
Las pruebas deben ser escritas en código, y esto
permite que se ejecuten automáticamente las veces que
sea necesario, y el solo hecho de ejecutar las pruebas
debe mostrar si la ejecución fue correcta o no.
4.2.3 REFACTORIZAR
Permite mantener la calidad de la arquitectura, se
cambia el diseño sin cambiar la funcionalidad,
manteniendo las pruebas como reaseguro. Además
mantiene el diseño del código limpio, facilitando su
mantenimiento. Otro aspecto que posibilita la
refactorización es la eliminación de la duplicación de
código, lo cual trae como consecuencia reducir la
dependencia en el código.
En palabras de Kent Beck: “Nunca escribas una
nueva funcionalidad sin escribir primero una que falle”.
Por otra parte Dave Chaplin expresa “Si no se puede
escribir una prueba para el nuevo código, entonces no se
debería estar pensando en incorporar el nuevo código”.
Estos dos axiomas de TDD implican que ninguna
nueva funcionalidad se debe escribir por adelantado, sino
que es necesario previamente contar con las pruebas que
permiten verificar que es correcta. Y como se deben
escribir las pruebas de a una a la vez, tenemos de esta
manera un proceso de desarrollo incremental extremo. Es
por esto que Kent Beck definió a TDD como el corazón de
la metodología XP. [4]
4.3 VENTAJAS DEL TDD
4.3.1 MAYOR CALIDAD.
Si TDD ha sido aplicado rigurosamente y revisado a
conciencia brinda un nivel de calidad y seguridad al
3
momento de incorporar cambios en las funcionalidades
que ya existen. Garantiza que las pruebas se ejecutan,
evitando que las aplicaciones tengan fallas la primera vez
que el usuario las ejecuta o que el usuario encuentre los
errores, en lugar de ser encontrados por el equipo de
desarrollo.
Asimismo, el hacer pruebas en etapas tempranas
del desarrollo es una forma de incorporar la calidad al
proceso, resultando en menos errores (bugs) en las
etapas finales del proyecto.
4.3.2 DISEÑO ENFOCADO EN LAS NECESIDADES.
Al realizar primero las pruebas, se realiza un
ejercicio de análisis en profundidad de los requisitos
necesarios, así se encuentra la mayor parte de
variabilidad al igual que aspectos importantes y no
contemplados, así obtendremos un diseño enfocado a
nuestras necesidades al igual que una mayor simplicidad
en el diseño.
Al implementar únicamente el código necesario para
realizar correctamente la prueba, reducimos código
innecesario en la aplicación, el cual nos puede ahorrar
mucho espacio a la hora de ejecutar la aplicación. Esto
nos proporcionará mayor calidad en la aplicación y como
resultado, habrá menos trabajo después.
4.3.3 MAYOR SIMPLICIDAD EN EL DISEÑO.
En lugar de enfocarse en realizar diseños extensos
y complejos, el equipo se enfocará en la necesidad o
requerimiento del cliente, agregando solamente la
funcionalidad que el cliente necesita. Esto es muy
importante, pues es la complejidad la que produce los
errores. Esto obliga a escribir código enfocado en las
necesidades del usuario, evitando anti patrones como los
objetos multipropósito o el acoplamiento del código, dado
que desarrollarán códigos específicos a los
requerimientos que se estén atendiendo en esa iteración
4.3.4 EL DISEÑO SE VA ADAPTANDO AL
ENTENDIMIENTO DEL PROBLEMA
Esto sucede ya que a medida se van realizando
iteraciones de prueba y programación, el nivel de
comprensión del problema que estamos resolviendo va
incrementando, por tal motivo cada que realicemos
iteraciones y entre mas sean estas, nos proporcionará un
mayor entendimiento del problema, esto conllevara a una
reducción de los malos entendidos o malos resultados de
alguna funcionalidad al final del desarrollo.
4.3.5 MAYOR PRODUCTIVIDAD.
Cuando nos encontramos trabajando en un proyecto
de manera tradicional, nos encontramos con la situación
de que experimentados una alta productividad cuando
iniciamos nuestro proyecto, sin embargo, dicha
productividad elevada tiende a caer cuando nos
encontramos en las etapas finales del proyecto, esto
sucede ya que se empiezan a encontrar errores por todas
partes, de igual manera resultan mal entendidos con el
cliente ya que no es lo que él esperaba.
Programación Extrema y Test Driver Development
.
En este sentido podemos resaltar que una de las
principale ventajas de TDD es que se está en constante
retroalimentación (feedback) de manera inmediata sobre
el desarrollo del software. Trabajando bajo esta práctica
al principio se puede tornar algo improductiva, ya que se
necesita escribir una serie de casos de pruebas que
tendrían que fallar al primer intento, no obstante, los
beneficios se harán notorios cuando se ha probado
constantemente el sistema que se está desarrollando, ya
que gracias a ello se han encontrado y corregido todos
aquellos errores de forma temprana y de igual manera
resultaran aclaradas las dudas tempranas que se puedan
tener respecto a la funcionalidad.
4.3.6 MENOS TIEMPO INVERTIDO EN DEBUGGING
DE ERRORES.
Esta ventaja parece ser de las más claras que nos
ofrece dicha práctica, ya que el código se encuentra
desarrollado en pequeñas partes, esto hace que cuando
surja un error, su solución sea más fácil, esto es gracias
a que todos los esfuerzos son orientados a esa pequeña
pieza o fragmento de código recién desarrollado o
modificado, esto resulta en que sea fácil llegar a los
problemas de una forma directa y precisa.
4.4 POSIBLES PROBLEMAS DEL TDD Y
SUS SOLUCIONES
4.4.1 INTERFAZ DE USUARIO
La práctica de TDD resulta bastante difícil de
implementar en la capa de la interfaz con el usuario, esto
es debido a dicha actividad contiene elementos que
tienden a alargar el ciclo de prueba y desarrollo. También
podemos decir que no conviene hacer pruebas
automatizadas sobre la interfaz de usuario, porque ésta
es muy cambiante y las pruebas se desactualizan con
mucha frecuencia. Por el contrario TDD encaja más
fácilmente en los desarrollos en las capas de lógica de
negocios y acceso a datos.
4.4.2 LA BASE DE DATOS
Dentro de los problemas principales de TDD,
podemos mencionar cuando se usan en aplicaciones con
base de datos, esto sucede debido a que ejecutada la
prueba, en la base de datos nos queda un estado, que no
es el oportuno para la cuando se necesite ejecutar la
siguiente prueba (por ejemplo, si la aplicación necesita
cambiar el valor de un campo de A a B, cuando la prueba
termina el valor queda en B, por lo que no se puede
ejecutar una siguiente prueba). Podemos identificar una
forma de posible solución a dicho problema, esta es que
se deberá de diseñar un código que pueda inicializar la
base de datos al estado anterior y que con ello quede lista
para ejecutar la siguiente prueba, cabe mencionar que
dicha estrategia añadirá carga de trabajo extra.
4.4.3 ERRORES NO IDENTIFICADOS
4
No se debe cometer el error de exceso de confianza,
el hecho de utilizar TDD nos podría conducir a una falsa
noción de seguridad, esto nos indica, que deberemos
enfocarnos en que todas las pruebas sean elaboradas
detalladamente y que sean capaces de cubrir todos los
escenarios posibles. Ya que el hecho de realizar ciertas
pruebas y que estas hayan sido aprobadas de manera
satisfactoria, esto realmente no garantiza que no se
tengan errores, esto mas bien solo nos indica que las
pruebas ejecutadas no han encontrado errores algunos.
4.4.4 PERDER LA VISIÓN GENERAL
Se deberá detener el cuidado pertinente de no
perder la visibilidad del proyecto y del aplicativo mismo,
ya que debemos recordar que TDD es un enfoque de
abajo hacia arriba.
Por tal razón se dice que es una buena idea
mantener un esquema o modelo general del proyecto y
poder revisarlo las veces que sean pertinente, para así,
poder encontrar oportunidades para refactorizar y hacer
que la aplicación se le pueda dar mantenimiento en el
tiempo.
4.4.5 PRONUNCIADA CURVA DE APRENDIZAJE
Test Driven Development resulta difícil de asimilar,
por dicho motivo puede esperarse un declive en la
productividad de aquellos que adopten TDD durante los
primeros dos meses de implementación. Lo
recomendable para enfrentar esto es buscar ayuda, por
medio de formación (cursos) y consultorías que apoyen
en la adopción de la nueva forma de trabajo. [5]
5 PROGRAMACION EXTREMA (XP)
La programación extrema es una metodología de
desarrollo ágil que tiene como principal objetivo aumentar
la productividad a la hora de desarrollar un proyecto
software. Da prioridad a los trabajos que dan un resultado
directo y en los cuales se reduce la burocracia que pueda
existir en el entorno de trabajo. [7]
Familiarmente conocida como XP, es una disciplina
del negocio de desarrollo de software que enfoca a todo
el equipo en metas. Utilizando los valores y principios de
XP, los equipos aplican las prácticas de XP apropiadas en
su propio contexto. Las prácticas de XP son elegidas por
la creatividad humana y su aceptación de la fragilidad
humana. Los equipos XP producen Software de calidad a
un ritmo sostenible.
Una de las metas de XP es traer la responsabilidad
y transparencia al software desarrollado, para ejecutar el
desarrollo de software como cualquier otra actividad
empresarial.
Además se busca lograr resultados sobresalientes, más
eficaces y eficientes desarrollos con mucho menos
defectos de lo que se espera actualmente. Por último, XP
apunta para alcanzar estos objetivos celebrando y
sirviendo las necesidades humanas de todos los
Programación Extrema y Test Driver Development
.
desarrolladores de software, patrocinadores, gestores,
probadores, usuarios y programadores.
Extreme Programming es sobre el cambio social. Se
trata de dejar ir los hábitos y patrones que fueron
adoptados en el pasado, pero ahora entrar en la forma en
que hacemos nuestro mejor trabajo. Se trata de renunciar
a las defensas que nos protegen pero interfieren con
nuestra productividad.
XP es un estilo de desarrollo de software que se
centra en la excelente aplicación de técnicas de
programación, comunicación clara y trabajo en equipo
que nos permite realizar cosas que previamente no
podíamos ni siquiera imaginar. XP incluye:
 Una filosofía de desarrollo de software basada
en los valores de comunicación,
retroalimentación, sencillez, coraje y respeto.
 Un conjunto de prácticas demostradas útiles
para mejorar el desarrollo de software.
 Un conjunto de principios complementarios,
técnicas intelectuales para traducir los valores
en práctica, útiles cuando no hay una práctica
para su problema particular.
 Una comunidad que comparte estos valores y
muchos de las prácticas. [6]
5.1 ANALISIS Y DISEÑO
La planificación es la primera actividad en el proceso
de desarrollo. Comienza creando una serie de historias
de usuarios (similares a los casos de uso) que describen
la funcionalidad del software que se va a construir. El
cliente les asigna una prioridad y el equipo de desarrollo
evalúa cada una y le asigna un periodo de desarrollo. Si
la historia supera más de tres semanas de desarrollo se
divide la historia en historias menores.
Una vez establecido un acuerdo detallando la fecha
de entrega, el equipo de desarrollo ordena las historias
para implementar antes las que tengan mayor prioridad.
Conforme avanza el trabajo de desarrollo, el cliente
puede agregar nuevas historias con nueva funcionalidad,
de esta manera, la programación extrema es una
metodología que acepta fácilmente requisitos cambiantes
durante el desarrollo de software.
El diseño en la programación extrema sigue el
principio de hacerlo todo simple .El diseño se va
modificando a lo largo de todo el proceso de desarrollo.
La programación extrema recomiendo que después
de diseñar las historias el equipo no debe comenzar la
codificación sino que debe desarrollar una serie de
pruebas de unidad que les ayuden a centrarse en lo que
debe implementase para pasar esa prueba. [8]
Entre las herramientas a utilizar en la programación
extrema podemos mencionar las siguientes:
5
 User stories: Es una representación de un
requisito escrito en una o dos frases utilizando el
lenguaje común del usuario.
 Pruebas de aceptación: Son las investigaciones
empíricas y técnicas cuyo objetivo es
proporcionar información objetiva e
independiente sobre la calidad del producto a la
parte interesada o stakeholder.
 Task Card: Usadas para describir tareas que
realizan en el proyecto. Deben tener relación con
cada User stories.
 Tarjeta CRC: Forma de trabajo grupal donde se
encuentran los objetos del dominio de la
aplicación a resolver. [10]
5.2 ROLES
Como todo equipo de trabajo se deben asignar o
tener roles y en extreme programming existen varios roles
tantos los que deben estar presentes siempre en un
proyecto o algunos opcionales.
 Programador
Escribe las pruebas unitarias y produce el código del
sistema. Define las tareas que conlleva cada historia de
usuario, y estima el tiempo que requerirá cada una.
 Cliente
Escribe las historias de usuario y las pruebas
funcionales para validar su implementación. Asigna la
prioridad a las historias de usuario y decide cuáles se
implementan en cada iteración centrándose en aportar el
mayor valor de negocio.
 Tester (Encargado de pruebas)
Ayuda al cliente a escribir las pruebas funcionales.
Ejecuta pruebas regularmente, difunde los resultados en
el equipo y es responsable de las herramientas de soporte
para pruebas.
 Tracker (Encargado de seguimiento)
Es el encargado de seguimiento. Proporciona
realimentación al equipo. Debe verificar el grado de
acierto entre las estimaciones realizadas y el tiempo real
dedicado, comunicando los resultados para mejorar
futuras estimaciones.
 Entrenador (coach)
Es responsable del proceso global. Experto en XP,
provee de las guías a los miembros del equipo para que
se apliquen las prácticas XP y se siga el proceso
correctamente. Determina la tecnología y metodologías a
usar por el equipo de desarrollo.
 Gestor (Big boss)
Es el dueño del equipo y sus problemas. Experto en
tecnología y labores de gestión. Construye el plantel del
equipo, obtiene los recursos necesarios y maneja los
problemas que se generan. Administra a su vez las
reuniones (planes de iteración, agenda de compromisos,
etc). [9]
Programación Extrema y Test Driver Development
.
5.3 PRINCIPIOS
Tenemos 12 principios básicos los cuales se
describen a continuación:
5.3.1 PLANIFICACIÓN
El cliente (o su representante) escribirá sus
necesidades para definir concretamente las actividades
que el sistema debe realizar. En esta fase se creará un
documento que contendrá historias de usuario que
forman el plan de liberación, el cual define los tiempos de
entrega de la aplicación para poder recibir feedback por
parte del cliente.
5.3.2 ESTÁNDAR DE PROGRAMACIÓN
Se debe establecer un estándar de codificación
aceptado e implementado por todo el equipo. Se
promueve la codificación en parejas, la propiedad
colectiva, el testeo continuo, la integración continua.
 Sin los estándares de codificación, la
metodología eficaz de programación se
vendría abajo.
 Se relaciona con el sistema metafórico,
dado que es necesario establecer un
criterio fijo que proporcione reglas para la
creación de nombre para variables y
métodos.
 Establecer un estándar de codificación de
tal forma que los programadores sigan los
mismos criterios para desarrollar código.
 Se gana eficacia al decidir de ante mano el
mejor estándar para satisfacer los
requerimientos propuestos por el cliente.
5.3.3 PROGRAMACIÓN EN PAREJAS
Consiste en escribir código en parejas compartiendo
una sola máquina. Según los experimentos ya realizados
sobre este método, se producen mejores y más
consistentes aplicaciones a igual o menor coste.
5.3.4 40 HORAS POR SEMANA
Los programadores cansados escriben peor código.
Es importante minimizar las horas extras y mantener a los
programadores frescos y descansados. De esta manera,
se generará mejor código. Si es necesario hacer horas
extras, quiere decir que el proyecto está mal planificado.
5.3.5 VERSIONES PEQUEÑAS
El producto es evaluado en un ambiente real
mediante la colocación de un sistema sencillo en
producción el cual se actualizará rápidamente, es decir,
6
cada 2 semanas (3 como máximo) el software será puesto
en producción.
5.3.6 DISEÑOS SIMPLES
El mejor programa será aquel que cumpla con los
requisitos y sea más simple. Es importante proporcionar
un software que cubra las necesidades de un cliente. Ni
más ni menos.
5.3.7 TESTEOS CONTINUOS
Lo primero que se debe hacer es establecer un
período de pruebas de aceptación del programa, en el
cual se definirán las entradas y salidas del sistema.
Básicamente se define lo que debe hacer el software
desarrollado. Como si fuese una caja negra.
5.3.8 REFACTORING
Este término en esta parte está asociado a que el
código debe ser simple y claro. Con lo cual se pretende el
huir del código duplicado.
Cuando implementamos nuevas características en
nuestros programas nos planteamos la manera de
hacerlo lo más simple posible, después de implementar
esta característica, nos preguntamos cómo hacer el
programa más simple sin perder funcionalidad, este
proceso se le denomina recodificar o refactorizar
(refactoring). [14]
La duplicación de código complica la tarea de
programación por diversas causas, una de ellas es que
“ensucia” el programa haciéndolo más largo de lo
estrictamente necesario. Con esto aumenta las
posibilidades de tener errores, y hace incomprensible o
de difícil lectura el programa. En ciertas ocasiones,
cuando una nueva “historia de usuario” va a ser
implementada, es normal que los objetos existentes
deban ser estructuralmente cambiados o incluso
debamos crear nuevos objetos.
Para entonces, se discutirá la necesidad de
refactorizar por parte del equipo, que confirme la validez
o no de dicho proceso.
El Proceso a seguir es el siguiente:
 Una vez se empiece a trabajar en la nueva
estructura del objeto y cuando se esté conforme,
será publicado al equipo de programación.
 Dada la aprobación, la pareja comenzara con la
implementación del nuevo objeto, el código
existente de ese nuevo será incluido de nuevo
en el objeto, donde la nueva funcionalidad no
está todavía incluida.
 Una vez terminada la nueva funcionalidad, la
pareja comenzara con la fase de pruebas.
 Se cambian todas las invocaciones y se ejecuta
todos los métodos de integración de ambos
Programación Extrema y Test Driver Development
.
componentes, que serán analizados por la
propia pareja de creación de la nueva
funcionalidad.
 Las nuevas funcionalidades son adheridas al
proyecto y la secuencia de codificación y análisis
normal sigue en curso.
Cabe señalar que la refactorización es
indispensable en la fase de pruebas, los cambios que se
pueden someter a nuestro código no son decisiones
aleatorias y cualquier fallo podría tener consecuencias
drásticas en cuanto a la operatividad de nuestro software.
5.3.9 PROPIEDAD COLECTIVA DEL CÓDIGO
(COLLECTIVE OWNERSHIP)
El código tiene propiedad compartida. Nadie es
propietario de nada, ni siquiera de lo que ha desarrollado.
Todos los programadores son "dueños" de todo el código.
Es decir, que cierto código que el equipo genere para
llevar a cabo un proyecto es propiedad de cada uno de
los componentes del equipo.
 Cualquier componente del equipo podrá
modificar un módulo o porción generada por otro
componente si lo cree conveniente.
 En un equipo no existen derechos de autor ni
prohibiciones de ningún tipo a la hora de
modificar el código de un compañero.
 Todo el código desarrollado por cada
componente del equipo es cedido para el bien
del propio equipo.
 Permite al grupo trabajar más rápidamente y
rendir de una forma más eficaz debido a que no
producen los retardos o esperas ocasionados
por la propiedad privada de un código.
Según esta metodología, cuantos más
programadores haya trabajado en una parte de código,
menos errores tendrá.
5.3.10 INTEGRACIÓN CONTINÚA
La integración continua es una práctica de
desarrollo de software donde los miembros de un equipo
de integrar su trabajo con frecuencia. Siempre tener
versiones simples y manejables del sistema. Esto
también se puede aplicar a los cambios que se deben
introducir en versiones pasadas.
 El código siendo claro y simple es más fácil de
manejar y de entender, así que los cambios que
se acumulen pueden convertirse en un
obstáculo difícilmente superable.
 Los cambios siempre deben ser integrados
continuamente y no acumularlos e integrarlos de
un golpe.
7
 Permite tener conciencia en todo momento del
trabajo que se lleva desarrollado y también
permite tener a mano cuando el cliente solicite
una versión perfectamente funcional y con los
últimos avances.
 La integración continua es introducir todos los
cambios producidos a lo largo del día a final de
la jornada.
5.3.11 EL CLIENTE EN SU SITIO
El cliente elabora especificaciones de los
requerimientos iniciales asi como las funcionalidades que
debe cumplir el proyecto, aunque pueden que no queden
claras en un principio.
Así, se propone que el propio cliente pase a formar
parte del proyecto, que se involucre en la producción del
software desde sus posibilidades que no son escasas. El
equipo de producción debe estar continuamente en
comunicación con el cliente, que deberá aclarar en la
medida de lo posible los requerimientos que necesitara
utilizar.
Se soluciona o al menos se facilita la compresión de
las funcionalidades, que en ciertos casos suele ser la
etapa más difícil, más cara y más lenta del desarrollo del
proyecto.
5.3.12 ESTÁNDARES DE CODIFICACIÓN
Se debe establecer un estándar de codificación
aceptado e implementado por todo el equipo. [15]
Se promueve la codificación en parejas, la propiedad
colectiva, el testeo continuo, la integración continua.
 Sin los estándares de codificación, la
metodología eficaz de programación se vendría
abajo.
 Se relaciona con el sistema metafórico, dado
que es necesario establecer un criterio fijo que
proporcione reglas para la creación de nombre
para variables y métodos.
 Establecer un estándar de codificación de tal
forma que los programadores sigan los mismos
criterios para desarrollar código.
 Se gana eficacia al decidir de ante mano el mejor
estándar para satisfacer los requerimientos
propuestos por el cliente.
Programación Extrema y Test Driver Development
.
Figura 3. Principios de la XP.
5.4 CICLO DE VIDA DE PROGRAMACION
EXTREMA
Las metodologías agiles se basan en una
interacción continua entre el cliente y los desarrolladores.
En XP no se realiza un plan a largo plazo, sino que se
realizan las planificaciones de las “liberaciones de
software”. Las “liberaciones de software”, son entregas de
software al cliente que ya cumplen con cierta o todos los
requerimientos de este.
En un proyecto enmarcado en XP puede haber
varias “liberaciones de software”, las liberaciones de
software se realizan hasta que el software cumpla con el
alcance previamente acordado con el cliente. Para
facilitar la comprensión de las fases en el desarrollo se
ejemplificara cada etapa con el Desarrollo de un pequeño
sistema bibliotecario.
A manera de ejemplo, hagamos no la idea de que
contamos con una serie de datos sobre cierto tema en
específico, por ejemplo ciertos datos de un automóvil
como lo son el año, la marca, el modelo; y la meta es
diseñar un sistema capaz de realizar la búsqueda de
ciertos datos. La interfaz gráfica es como la siguiente:
8
Figura 4. Ciclo de vida del proceso XP.
5.4.1 FASE DE EXPLORACIÓN
En esta fase el cliente hace uso de las historias de
usuarios donde se describen a grandes rasgos las
funcionalidades que debe poseer el sistema, de esta
manera las historias de usuario no son lo mismo que la
recolección de requerimientos tradicional ya que XP no
profundiza en los detalles por lo ya mencionado de contar
con un cliente que interactúa en todo momento con el
equipo de desarrollo.
Paralelamente a la captación de estas primeras
historias se hace el spike arquitectónico que consta de
una familiarización entre el equipo de desarrollo, la
metodología, herramientas, lenguajes y normas de
codificación que se usaran en el proyecto.
Podríamos citar un ejemplo de una Historia de
Usuario:
Figura 5. Historia de usuario.
El cliente, al estar en comunicación continua con los
programadores puede resolver todas las dudas e
interrogantes.
 Programador: “¿Qué tipo de configuración
necesitan?”
 Cliente: “Muchos clientes usan la misma
biblioteca todo el tiempo, pero otros usan de una
variedad. Nos gustaría que el usuario elija de
una lista la biblioteca deseada.”
Programación Extrema y Test Driver Development
.
 Programador: “Ok. Eso podría estar lleno en 2
semanas. ¿Qué nos puede decir acerca de la
compatibilidad con otros sistemas y acerca el
rendimiento?”
5.4.2 FASE DE PLANIFICACIÓN
El cliente entrega al equipo las historias que ha
confeccionado asignándoles una prioridad para el
funcionamiento del sistema.
Se priorizan las historias de usuario y se acuerda el
alcance del release. Los programadores estiman cuánto
esfuerzo requiere cada historia y a partir de allí se define
el cronograma. La duración del cronograma del primer
release no excede normalmente dos meses.
La fase de planeamiento toma un par de días. Se
deben incluir varias iteraciones para lograr un release. El
cronograma fijado en la etapa de planeamiento se realiza
a un número de iteraciones, cada una toma de una a
cuatro semanas en ejecución. [11]
La primera iteración crea un sistema con la
arquitectura del sistema completo. Esto es alcanzado
seleccionando las historias que harán cumplir la
construcción de la estructura para el sistema completo. El
cliente decide las historias que se seleccionarán para
cada iteración. Las pruebas funcionales creadas por el
cliente se ejecutan al final de cada iteración. Al final de la
última iteración el sistema está listo para producción.
Figura 6. Planificación de la entreda.
5.4.3 FASE DE ITERACIONES
9
Figura 7. Comenzar la interacción
Inicialmente se convoca a una reunión para
establecer cuantas iteraciones se realizaran y de acuerdo
a ello se establece el tiempo de duración de cada una.
Para una iteración determinada se siguen los pasos a
continuación: - Se reúnen las historias asignadas a esa
iteración, se detallan las tareas a realizar por cada historia
y el grado de dificultad de cada una; luego se reparten las
tareas prioritarias para dejar el resto en cola.
Siguiendo con el ejemplo de los automóviles, las
tareas necesarias por la historia de Consulta pueden ser
crear las clases necesarias para la consulta (Documento,
Consulta, Resultado, Buscador) y los métodos necesarios
para su implementación; para la historia de configuración
las tareas por realizar, como establecer los protocolos de
comunicación necesarios entre los sistemas del negocio
automotriz, adaptar las configuraciones, etc.
En XP se usa una programación de forma
incremental y las pruebas que se efectuarán al código se
hacen antes de escribir el código. Incremental porque se
programa en ciclos, no una clase completa, sino unas
pocas líneas de código o un método a la vez, y las
pruebas se escriben antes de escribir el código para que
el código que escribamos se ajuste al test y no el test al
código que se ha escrito.
Ejemplo de un test:
public void testDocument() {
Document d = new Document("a", "t", "y");
assertEquals("a", d.getAuthor());
assertEquals("t", d.getTitle());
assertEquals("y", d.getYear());
}
5.4.4 FASE DE PRODUCCIÓN
Se requiere, prueba y comprueba el extra del
funcionamiento del sistema antes de que éste se pueda
liberar al cliente. En esta fase, los nuevos cambios
pueden todavía ser encontrados y debe tomarse la
decisión de si se incluyen o no en el reléase actual.
Programación Extrema y Test Driver Development
.
Esta etapa se fundamenta en pasar la aplicación a
producción cuando se alcancen las funcionalidades
mínimas que aporten un valor real al negocio y una
estabilidad confiable; esto nos hace que nuestra
aplicación aporte sus primeros frutos a la empresa en aún
tempranas etapas de lo que es el proyecto de desarrollo.
Para el ejemplo en desarrollo, esta etapa es
después de la primera iteración, al entregar la primera
versión; esta versión es capaz de crear una consulta y
entregar resultados de acuerdo a unos pocos libros
ingresados al sistema. Además en esta etapa se trabaja
en las historias de menor prioridad (funcionalidades
secundarias del software).
Figura 8. Programación.
5.4.5 FASE DE MANTENIMIENTO
Se requiere de un mayor esfuerzo para satisfacer
también las tareas del cliente. Así, la velocidad del
desarrollo puede desacelerar después de que el sistema
esté en la producción. La fase de mantenimiento puede
requerir la incorporación de nueva gente y cambiar la
estructura del equipo.
Una vez el alcance del proyecto se ha completado,
y se cuentan con todas las funcionalidades en
producción, se verifican con el usuario aquellas nuevas
historias de usuario que se han realizado después de la
puesta en producción del proyecto; estas nuevas
funcionalidades se van incorporando según su valor en el
negocio y el presupuesto adicional con que disponga el
usuario. Por ello el equipo de desarrollo se reduce a la
mínima expresión, dejando algunos miembros para el
mantenimiento.
Debido a esto, 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. Para esta
fase nuestro proyecto ya cuenta con las funcionalidades
solicitadas y las nuevas agregadas al proyecto. Se
realizan las pruebas nuevamente una por una, y se
integra la aplicación a los sistemas bibliotecarios
correspondientes.
5.4.6 FASE DE MUERTE DEL PROYECTO
10
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. [12]
Cuando no se tienen más historias de usuario para
implementar en el sistema, solo queda que se cumplan
las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad. Se elabora la documentación
final del sistema y no se realizan más cambios en la
estructura. La muerte del proyecto también ocurre cuando
el sistema no genera los beneficios esperados por el
cliente o cuando no hay presupuesto para brindarle
mantenimiento.
5.5 VENTAJAS Y DESVENTAJAS DE
PROGRAMACIÓN EXTREMA
En la programación extrema como en todo nuevo
proyecto estuvo en el ojo de la comunidad desarrolladora
de software. En este apartado veremos las principales
observaciones que ha tenido por la comunidad de
desarrollo de software.
Está claro que las Ventajas que nos ofrece el utilizar
metodologías ágiles, en especial y en este caso XP, están
por arriba de las Desventajas. Como se podrá notar,
realmente podemos tomar como “desventajas”
solamente, el hecho de que tal vez no todos los proyectos
se adapten a esta metodología.
5.5.1 VENTAJAS
Una de las ventajas de la programación extrema es
que de adapta al desarrollo de sistemas pequeños y
grandes; optimiza el tiempo de desarrollo; permite realizar
el desarrollo del sistema en parejas para complementar
los conocimientos; el código es sencillo y entendible,
además de la poca documentación a elaborar para el
desarrollo del sistema.
 Da lugar a una programación sumamente
organizada. [13]
 Ocasiona eficiencias en el proceso de
planificación y pruebas.
 Cuenta con una tasa de errores muy pequeña.
 Propicia la satisfacción del programador.
 Fomenta la comunicación entre los clientes y los
desarrolladores.
 Facilita los cambios.
 Permite ahorrar mucho tiempo y dinero.
 Puede ser aplicada a cualquier lenguaje de
programación.
 El cliente tiene el control sobre las prioridades.
 Se hacen pruebas continuas durante el
proyecto.
Programación Extrema y Test Driver Development
.

 La XP es mejor utilizada en la implementación

de nuevas tecnologías.

5.5.2 DESVENTAJAS

Las desventajas son que no se tiene la definición del

costo y el tiempo de desarrollo; el sistema va creciendo
después de cada entrega al cliente y nadie pude decir que
el cliente no querrá una función más; se necesita de la
presencia constante del usuario, lo cual en realidad es
muy difícil de lograr.

Otra desventaja es la programación en parejas,

algunos desarrolladores son celosos del código que
escriben y no les es grato que alguien más modifique las
funciones que realizó o que su código sea desechado por
no cumplir con el estándar.

 Es recomendable emplearla solo en proyectos a

corto plazo.
 En caso de fallar, las comisiones son muy altas.
 Requiere de un rígido ajuste a los principios de
XP.
 Puede no siempre ser más fácil que el desarrollo
tradicional.

Para finalizar podemos resumir la programación

extrema de la siguiente manera:

 Planificación incremental: Los requerimientos

se registran en tarjetas de historias. Los
desarrolladores dividen estas historias en
Tareas de desarrollo.
 Entregas pequeñas: Primero se desarrolla una
versión con la funcionalidad más importante.
Después se van añadiendo funcionalidades a las
distintas entregas.
 Diseño sencillo: Solo se lleva a cabo el diseño
necesario para cumplir con los requerimientos
actuales.
 Desarrollo previamente probado: Se utilizan
pruebas automatizadas antes de escribir código.
 Programación en parejas: Las parejas de
desarrolladores trabajan en todas las áreas del
sistema.
 Integración continua: Cuando acaba el trabajo
de una historia se integra en el sistema entero.
después de la integración se deben pasar todas
las pruebas de unidad.
 Cliente presente: El cliente debe estar
disponible ya que es miembro del equipo de
desarrollo y es responsable de formular los
requerimientos del sistema para que se puedan
implementar.

11
Programación Extrema y Test Driver Development
.

6 CONCLUSIONES https://iswugaps2extremeprogramming.wordpress.com/201
5/09/14/ventajas-y-desventajas/
[14] Introducción a la Programación Extrema (XP)
La programación extrema como metodología de David Valverde © 2007 – 2015
desarrollo de software no se ajusta a cualquier proyecto, http://www.davidvalverde.com/blog/introduccion-a-la-
es el equipo de trabajo él debe cerciorarse de los programacion-extrema-xp/
[15] Programación Extrema,Exposición de Maestría
requerimientos que el cliente especifique y sus
2007
funcionalidades; además el administrador del proyecto https://www.slideshare.net/edgarespinoza/programaci
debe permitir un entorno adecuado para la comunicación on-extrema
priorizando aspectos importantes como lo es el trabajo en
parejas que disminuye considerablemente la
documentación pero a su vez simplifica y acelera el
desarrollo.

El Test Driven Development si se utiliza, debe

considerarse entenderlo bien para que sea realmente
productivo, nos ayuda a centrarnos en lo importante y a
no sobre diseñar, pero es importante saber refactorizar el
código según vaya evolucionando para que sea
consistente.

No existe una metodología universal para hacer

frente con éxito a cualquier proyecto de desarrollo de
software. Toda metodología debe ser adaptada al
contexto del proyecto (recursos técnicos y humanos,
tiempo de desarrollo, tipo de sistema, etc).

7 REFERENCIAS
[1] Metodologias agiles, obtenido de Noticias y
articulos:
[2] Jose Roldan (20011, Enero 11). [En línea].
Disponible en: https://www.paradigmadigital.com/dev/tdd-
como-metodologia-de-diseno-de-software/
[3] Lordudun (20011, Abril 18). [En línea]. Disponible
en: http://blog.lordudun.es/agile/2011/04/18/introduccion-a-
tdd-test-driven-development.html
[4] Fernandez, Javier (20012, Sept. 19). [En línea].
Disponible en:
http://www.pmoinformatica.com/2012/09/test-driven-
development-scrum.html
[5] Nilsson, J. Putting (20012, Dic. 3). [En línea].
Disponible en:
http://www.pmoinformatica.com/2012/12/test-driven-
development-ventajas-y.html
[6] Kent Benck, Extreme Programming Explained,
Embrace Change, Second Edtion Cap I pag 1-2
[7] https://geekytheory.com/programacion-extrema-
que-es-y-principios-basicos
[8] (20010, Junio 21). [En línea]. Disponible en:
https://parasitovirtual.wordpress.com/category/cursos-y-
articulos/ingenieria-del-software/metodologias-agiles-de-
desarrollo/programacion-extrema-xp/
[9] Sergio Alberto. (20015, Sept. 14). [En línea].
Disponible en:
https://iswugaps2extremeprogramming.wordpress.com/201
5/09/14/roles/
[10] Daniel Ochoa. (20014, Abril 21). [En línea].
Disponible en: https://es.slideshare.net/nataliahrey/extreme-
programming-33773657
[11] https://modulopoo.wordpress.com/unidad-iv/
[12] Aplicación de eXtreme Programming en ONess
http://oness.sourceforge.net/proyecto/html/ch05s02.html
[13] Ventajas y Desventajas. (Publicado el 14
septiembre, 2015 por sergioalbertoc )

12