Universidad Nacional

de Rio Negro (UNRN)

Trabajo Practico:
Investigación y Exposición sobre
Metodologías Ágiles –
XP (Extreme Programming).

Profesor: Mauricio Andrés

Tassara

Alumnos: Nicolás Puyardieu, Dalmiro

Marcocci, Bruno Gorosito, Maximiliano
Donadío, Lucio Giangiobbe

Fecha de entrega: 02/04/2019

Índice:
Página 3 …………………………………. Introducción
Página 4 …………………………………. Programación Extrema
………………………….. ¿Qué es la Programación Extrema?
Página 5 …………………………………. Ciclo de Vida XP
………………………….. El proceso XP
Página 6 ………………………………… Las 4 actividades básicas de XP
Página 7 ………………………………… Roles en XP
Página 8 ………………………………… Roles excepcionales
………………………….. Las Historias de Usuario en XP
Página 9 ………………………………… Fases de XP
………………………….. Fase 1
Página 10 ………………………………. Fase 2
…………………………. Fase 3
Página 11 ………………………………. Fase 4
Página 12 ………………………………. TDD como metodología de desarrollo

2
Introducción
Actualmente la mayoría de los programadores no pensamos en una metodología de desarrollo a
la hora de crear algún software, o sea tenemos cierta tendencia en embebernos en cuestiones
técnicas, hablar de lenguajes de programación, de técnicas de programación, de entornos de
desarrollo (IDE) o de editores de recursos, etc.

Pero se nos pasan por alto temas muy importantes como es la ingeniería de software, la manera
en que debemos de hacer nuestro software. Alrededor de cómo hacer software hay un gran
número de teorías, propuestas, etc. El primer paso es conocer las metodologías más relevantes
o buscar a alguien que las conozca, y en una situación ideal haber trabajado con varias de ellas.

No hay metodología que funcione de manera excepcional, de hecho, cada vez más las
metodologías se conciben como Marco Metodológico que son necesario ajustar para cada
organización y tipo de Proyecto. Realizar este ajuste es algo que requiere de una experiencia y
un conocimiento previo. El problema con la implantación de una metodología es que no se suele
tener una segunda oportunidad.

A la hora de seleccionar una metodología la primera decisión que se plantea es: ¿Una
Metodología ágil o una metodología guiada por plan? La gran mayoría de proyectos se pueden
beneficiar mucho del uso de una metodología ágil, pero existen proyectos y entornos en los que
es condición, generalmente impuesta por el cliente o la dirección de la empresa, que el proyecto
se desarrolle con más control.

Para plantearte el uso de una metodología ágil tenemos que ser capaces de comprender el
Manifiesto ágil y ser capaces de hacer que sea el paradigma que guíe la gestión de nuestro
proyecto, y desde luego es sumamente importante que logremos un Sponsor.

Tener un sponsor es vital en todo proyecto de implantación de una metodología, pero sobretodo
es vital para implantar una metodología ágil, pues exige que se produzcan profundos cambios
en la cultura tradicional relativa a la gestión de proyectos. Poniendo de menos a más ágil, de
más revolucionaria a menos, entre las metodologías más populares, tenemos las siguientes:
● eXtreme Programming
● Rational Unified Process
● Scrum

3
Programación Extrema
La programación extrema o EXtreme Programming (PX) es un enfoque de la Ingeniería de
Software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change 1999. 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. Los
defensores de PX consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del Desarrollo de Proyectos.

Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del
proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

¿Qué es la programación extrema PX?

La Programación Extrema PX, mejor conocida por su nombre en inglés Extreme Programming
(XP), es una de las llamadas Metodologías Ágiles de desarrollo de software más exitosas de los
tiempos recientes, nace como nueva disciplina de desarrollo de software, y ha causado un gran
revuelo entre el colectivo de programadores del mundo.

Con sus teorías ha conseguido el respaldo de gran parte de la industria del software y el rechazo
de otra parte. La programación extrema se basa en la simplicidad, la comunicación y el reciclado
continuo de código, para algunos no es más que aplicar una pura lógica.
Los Valores originales de la programación extrema son: simplicidad, comunicación,
retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda
edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:
La Simplicidad: es la base de la programación extrema. Se simplifica el diseño para agilizar el
desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas
modificaciones por parte de diferentes desarrolladores hace que la complejidad aumente
exponencialmente.

Para mantener la simplicidad es necesaria la Refactorización del Código, ésta es la manera de

mantener el código simple a medida que crece. También se aplica la simplicidad en la
documentación, de esta manera el código debe comentarse en su justa medida, intentando eso
sí que el Código esté auto-documentado.

Para ello se deben elegir adecuadamente los nombres de las variables, Métodos y clases. Los
nombres largos no decrementan la Eficiencia del código ni el tiempo de desarrollo gracias a las
herramientas de autocompletado y refactorización que existen actualmente.

Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas
se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el
sistema completo.
La Comunicación se realiza de diferentes formas, para los Programadores el código comunica
mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo
inteligible. El código auto-documentado es más fiable que los comentarios ya que éstos últimos
pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo
aquello que no va a variar, por ejemplo, el objetivo de una clase o la funcionalidad de un método.

4
Las Pruebas Unitarias son otra forma de comunicación ya que describen el diseño de las clases
y los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad. Los
programadores se comunican constantemente gracias a la programación por parejas. La
comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El
cliente decide qué características tienen prioridad y siempre debe estar disponible para
solucionar dudas.
Retroalimentación feedback: Al estar el cliente integrado en el Proyecto, su opinión sobre el
estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se
muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos
y ayuda a los programadores a centrarse en lo que es más importante, considerando los
problemas de ciclos largos. Meses de trabajo pueden tirarse por la borda debido a cambios en
los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es
una fuente de retroalimentación gracias a las Herramientas de desarrollo.

Por ejemplo, las Pruebas unitarias informan sobre el estado de salud del código. Ejecutar las
pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el
código.

Coraje o valentía: Los puntos anteriores parecen tener sentido común, entonces, ¿por qué
coraje? Para los gerentes la programación en parejas puede ser difícil de aceptar, porque les
parece como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los
programadores está escribiendo código.

Hay que ser valiente para confiar en que la programación por parejas beneficia la calidad del
código sin repercutir negativamente en la productividad. La simplicidad es uno de los principios
más difíciles de adoptar. Se requiere coraje para implementar las características que el cliente
quiere ahora sin caer en la tentación de optar por un enfoque más flexible que permita futuras
modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo(frameworks)
mientras el cliente espera.

En ese tiempo el cliente no recibe noticias sobre los avances del proyecto y el equipo de
desarrollo no recibe retroalimentación para saber si va en la dirección correcta. La forma de
construir marcos de trabajo es mediante la refactorización del código en sucesivas
aproximaciones.

El ciclo de vida ideal de XP

El ciclo de vida ideal de XP consta de seis fases:
● Exploración.
● Planificación de la Entrega (Release)
● Iteraciones.
● Producción.
● Mantenimiento.
● Muerte del Proyecto.

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 de manera general 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.

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

Las Cuatro Actividades Básicas

Ahora que tenemos nuestros cuatro valores estamos preparados para construir una Disciplina
de Desarrollo de software. ¿Qué tareas debemos de llevar a cabo para desarrollar un buen
software?

Codificar: Es la única actividad de la que no podremos prescindir. Sin código fuente no hay
programa, aunque hay gente que cuenta que existe software en producción del que se perdió el
código fuente. Por tanto, necesitamos codificar y plasmar nuestras ideas a través del código. En
una programación en PX en pareja el código expresa tu interpretación del problema, así
podemos utilizarlo para comunicar, para hacer mías tus ideas, y por tanto para aprender y
mejorar.
Hacer pruebas: Las características del software que no pueden ser demostradas mediante
pruebas simplemente no existen. Las pruebas me dan la oportunidad de saber si lo que
implementé es lo que en realidad yo pensaba que había implementado. Las pruebas nos indican
que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese
originar un fallo en nuestro sistema entonces has acabado por completo.

No debemos de escribir tan solo una prueba, ver que funciona y salir corriendo, debemos de
pensar en todas las posibles pruebas para nuestro código, con el tiempo llegaras a conclusiones
sobre las pruebas y podrás pensar que si dos de tus pruebas ya funcionan la tercera prueba no
será necesaria escribirla, sin caer en demasiada confianza. Programar y probar es más rápido
que sólo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero
perderás mucho tiempo en la Depuración.

Tendrás menos errores, tendrás que volver menos veces sobre el código, te costará menos
localizar los errores, perderás menos tiempo escuchado como tus clientes te dicen que no
funciona. Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebas pequeñas
que no testen a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando
pasemos de nuevo por allí y volveremos a caer dentro.
Escuchar: Los programadores no lo conocemos todo, y sobre todo muchas cosas que las
personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio
software ¿para qué nos querrían? Si vamos a hacer pruebas tenemos que preguntar si lo
obtenido es lo deseado, y tenemos que preguntar a quién necesita la información.

Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos
de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la Realimentación
entre ambos nos ayudan a todos a entender los problemas.
Diseñar: El Diseño crea una estructura que organiza la lógica del sistema, un buen diseño
permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos,
si alguna parte del sistema es de desarrollo complejo, divídala en varias. Si hay fallos en el
diseño o malos diseños, estos deben de ser corregidos cuanto antes.

Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas porque
sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no
6
escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder Codificar,
probar y escuchar indefinidamente.

Características fundamentales Las características fundamentales del método son:

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

Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi
y NUnit para la plataforma.NET. Estas dos últimas inspiradas en JUnit.
● 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, reescribir 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.

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
7
 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.). No le dice al grupo lo que tiene que hacer,
cuando hacerlo, ni verifica el avance de las tareas.

Roles excepcionales

● Consultor → Es un miembro externo del equipo con un conocimiento específico en algún

tema necesario para el proyecto. Guía al equipo para resolver un problema específico.
● Doomsayer (Augur de desastres) → Es el responsable de que se conozcan los riesgos
involucrados, que las malas noticias sean notificadas en la medida correcta, y que no se
sobre-dimensionen. Busca posibles riesgos en forma constante, presentándolos al equipo
siempre con una posible solución.

Las Historias de Usuario en XP

Las historias de usuario son utilizadas por la metodología XP como una técnica para especificar
los requisitos del mismo, tanto requisitos no funcionales como funcionales. Se trata de tarjetas
en las cuales el usuario describe las características que el sistema debe poseer, de forma muy
breve. Las características fundamentales del método son:
● 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 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.

8
Fases del XP
1ª Fase: Planificación del proyecto.
● Historias de usuario: El primer paso de cualquier proyecto que siga la metodología X.P es
definir las historias de usuario con el cliente. Las historias de usuario tienen la misma
finalidad que los casos de uso, pero con algunas diferencias: Constan de 3 o 4 líneas
escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles;
no se debe hablar ni de posibles algoritmos para su implementación ni de diseños de
base de datos adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte
de la aplicación que describen. También se utilizan en la fase de pruebas, para verificar si
el programa cumple con lo que especifica la historia de usuario. Cuando llega la hora de
implementar una historia de usuario, el cliente y los desarrolladores se reúnen para
concretar y detallar lo que tiene que hacer dicha historia. El tiempo de desarrollo ideal
para una historia de usuario es entre 1 y 3 semanas.
● Release planning*: Después de tener ya definidas las historias de usuario es necesario
crear un plan de publicaciones, en inglés "Release plan", donde se indiquen las historias
de usuario que se crearán para cada versión del programa y las fechas en las que se
publicarán estas versiones. Un "Release plan" es una planificación donde los
desarrolladores y clientes establecen los tiempos de implementación ideales de las
historias de usuario, la prioridad con la que serán implementadas y las historias que
serán implementadas en cada versión del programa. Después de un "Release plan"
tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que son
principalmente las historias que se deben desarrollar en cada versión), el tiempo que
tardarán en desarrollarse y publicarse las versiones del programa, el número de personas
que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo realizado.
(*Release plan: Planificación de publicaciones).
● Iteraciones: Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones de
aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes
deben seleccionar las historias de usuario definidas en el "Release planning" que serán
implementadas. También se seleccionan las historias de usuario que no pasaron el test
de aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario
son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los
programadores.
● Velocidad del proyecto: La velocidad del proyecto es una medida que representa la
rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con contar
el número de historias de usuario que se pueden implementar en una iteración; de esta
forma, se sabrá el cupo de historias que se pueden desarrollar en las distintas
iteraciones. Usando la velocidad del proyecto controlaremos que todas las tareas se
puedan desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar
esta medida cada 3 o 4 iteraciones y si se aprecia que no es adecuada hay que negociar
con el cliente un nuevo "Release Plan".
● Programación en pareja: La metodología X.P. aconseja la programación en parejas pues
incrementa la productividad y la calidad del software desarrollado. El trabajo en pareja
involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica
haciendo hincapié en la calidad de la función o método que está implementando, el otro
analiza si ese método o función es adecuado y está bien diseñado. De esta forma se
consigue un código y diseño con gran calidad.
● Reuniones diarias. Es necesario que los desarrolladores se reúnan diariamente y
expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen
que ser fluidas y todo el mundo tiene que tener voz y voto.

9
2ª Fase: Diseño.
● Diseños simples: La metodología X.P sugiere que hay que conseguir diseños simples y
sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un
diseño fácilmente entendible e impleméntable que a la larga costará menos tiempo y
esfuerzo desarrollar.
● Glosarios de términos: Usar glosarios de términos y una correcta especificación de los
nombres de métodos y clases ayudará a comprender el diseño y facilitará sus posteriores
ampliaciones y la reutilización del código.
● Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una
pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que
supone ese problema.
● Funcionalidad extra: Nunca se debe añadir funcionalidad extra al programa, aunque se
piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que
implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.
● Refactorizar. Refactorizar es mejorar y modificar la estructura y codificación de códigos
ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos
códigos para procurar optimizar su funcionamiento. Es muy común rehusar códigos ya
creados que contienen funcionalidades que no serán usadas y diseños obsoletos. Esto es
un error porque puede generar código completamente inestable y muy mal diseñado; por
este motivo, es necesario refactorizar cuando se va a utilizar código ya creado.
● Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and Collaboration)
permiten al programador centrarse y apreciar el desarrollo orientado a objetos
olvidándose de los malos hábitos de la programación procedural clásica.
● Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se puede
escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se pueden
escribir las responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las
clases que colaboran con cada responsabilidad.

3ª Fase: Codificación.
Como ya se dijo en la introducción, el cliente es una parte más del equipo de desarrollo; su
presencia es indispensable en las distintas fases de X.P. A la hora de codificar una historia de
usuario su presencia es aún más necesaria. No olvidemos que los clientes son los que crean las
historias de usuario y negocian los tiempos en los que serán implementadas. Antes del
desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que ésta hará
y también tendrá que estar presente cuando se realicen los test que verifiquen que la historia
implementada cumple la funcionalidad especificada.
La codificación debe hacerse ateniendo a estándares de codificación ya creados. Programar
bajo estándares mantiene el código consistente y facilita su comprensión y escalabilidad.
Crear test que prueben el funcionamiento de los distintos códigos implementados nos ayudará a
desarrollar dicho código. Crear estos test antes nos ayuda a saber qué es exactamente lo que
tiene que hacer el código a implementar y sabremos que una vez implementado pasará dichos
test sin problemas ya que dicho código ha sido diseñado para ese fin. Se puede dividir la
funcionalidad que debe cumplir una tarea a programar en pequeñas unidades, de esta forma se
crearán primero los test para cada unidad y a continuación se desarrollará dicha unidad, así
poco a poco conseguiremos un desarrollo que cumpla todos los requisitos especificados.
Como ya se comentó anteriormente, X.P opta por la programación en pareja ya que permite un
código más eficiente y con una gran calidad.
X.P sugiere un modelo de trabajo usando repositorios de código dónde las parejas de
programadores publican en pocas horas sus códigos implementados y corregidos junto a los test
que deben pasar. De esta forma el resto de programadores que necesiten códigos ajenos
trabajarán siempre con las últimas versiones. Para mantener un código consistente, publicar un
código en un repositorio es una acción exclusiva para cada pareja de programadores.
10
X.P también propone un modelo de desarrollo colectivo en el que todos los programadores están
implicados en todas las tareas; cualquiera puede modificar o ampliar una clase o método de otro
programador si es necesario y subirla al repositorio de código. El permitir al resto de los
programadores modificar códigos que no son suyos no supone ningún riesgo ya que para que
un código pueda ser publicado en el repositorio tiene que pasar los test de funcionamiento
definidos para el mismo.
La optimización del código siempre se debe dejar para el final. Hay que hacer que funcione y
que sea correcto, más tarde se puede optimizar.
X.P afirma que la mayoría de los proyectos que necesiten más tiempo extra que el planificado
para ser finalizados no podrán ser terminados a tiempo se haga lo que se haga, aunque se
añadan más desarrolladores y se incrementen los recursos. La solución que plantea X.P es
realizar un nuevo "Release plan" para concretar los nuevos tiempos de publicación y de
velocidad del proyecto.
A la hora de codificar no seguimos la regla de X.P que aconseja crear test de funcionamiento
con entornos de desarrollo antes de programar. Nuestros test los obtendremos de la
especificación de requisitos ya que en ella se especifican las pruebas que deben pasar las
distintas funcionalidades del programa, procurando codificar pensando en las pruebas que debe
pasar cada funcionalidad.

4ª Fase: Pruebas.
Uno de los pilares de la metodología X.P es el uso de test para comprobar el funcionamiento de
los códigos que vayamos implementando.
El uso de los test en X.P es el siguiente:

● Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo
específico para test.
● Hay que someter a tests las distintas clases del sistema omitiendo los métodos más
triviales.
● Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado
anterior se explicó la importancia de crear antes los test que el código.

Un punto importante es crear test que no tengan ninguna dependencia del código que en un
futuro evaluará. Hay que crear los test abstrayéndose del futuro código, de esta forma
aseguraremos la independencia del test respecto al código que evalúa.
Como se comentó anteriormente los distintos test se deben subir al repositorio de código
acompañados del código que verifican. Ningún código puede ser publicado en el repositorio sin
que haya pasado su test de funcionamiento, de esta forma, aseguramos el uso colectivo del
código (explicado en el apartado anterior).
El uso de los test es adecuado para observar la refactorización. Los test permiten verificar que
un cambio en la estructura de un código no tiene por qué cambiar su funcionamiento.
Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas tareas
en las que ha sido dividida una historia de usuario. Para asegurar el funcionamiento final de una
determinada historia de usuario se deben crear "Test de aceptación"; estos test son creados y
usados por los clientes para comprobar que las distintas historias de usuario cumplen su
cometido.
Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se harán
test que analicen partes de las mismas, sino que las pruebas se realizarán para las
funcionalidades generales que debe cumplir el programa especificado en la descripción de
requisitos

11
TDD como metodología de desarrollo
TDD o Test-Driven Development (desarrollo dirigido por tests) es una práctica de programación
que consiste en escribir primero las pruebas (generalmente unitarias), después escribir el código
fuente que pase la prueba satisfactoriamente y, por último, refactorizar el código escrito. Con
esta práctica se consigue entre otras cosas: un código más robusto, más seguro, más
mantenible y una mayor rapidez en el desarrollo. Antes pensaba que TDD era una forma de
programar que consistía en generar primero los tests unitarios antes que la propia aplicación,
con lo que conseguías desarrollos de más calidad a costa de disminuir la productividad. Sin
embargo, TDD no es para hacer pruebas, es una práctica que envuelve el desarrollo en su
conjunto, especialmente el diseño de software. De hecho, algunos dicen que su última letra,
debería significar diseño y no desarrollo. Es decir, diseño orientado por las pruebas.

Fue creado por Kent Beck (quien también inventó Extreme Programming y JUnit), y en esencia,
es un proceso a seguir, lo cual ya lo hace diferente a un simple enfoque de pruebas primero:

Este ciclo también se lo conoce como rojo (hacer que la prueba falle), verde (hacer que la
prueba pase) y refactor. Aunque al principio pueda parecer muy parecido a un enfoque de
probar primero, al combinarlo con prácticas de desarrollo ágil, TDD toma un enfoque mucho más
amplio, y cambia su atención de las pruebas al diseño. TDD está mucho más relacionado con el
diseño emergente que con las pruebas, de hecho, que TDD genere una gran cantidad de
pruebas es un efecto secundario positivo, pero no es su propósito final.

El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:

1. El cliente escribe su historia de usuario.

2. Se escriben junto con el cliente los criterios de aceptación de esta historia,
desglosándolos mucho para simplificarlos todo lo posible.
3. Se escoge el criterio de aceptación más simple y se traduce en una prueba unitaria.
4. Se comprueba que esta prueba falla.
5. Se escribe el código que hace pasar la prueba.
6. Se ejecutan todas las pruebas automatizadas.
7. Se refactoriza y se limpia el código.
8. Se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue
funcionando.
9. Volvemos al punto 3 con los criterios de aceptación que falten y repetimos el ciclo una
y otra vez hasta completar nuestra aplicación

Realmente es la forma natural de pensar, primero pensamos en “qué” queremos hacer y

después pasamos al “cómo”, la diferencia es que con TDD el test ya queda escrito y se
ejecutará cada vez que compilamos nuestro programa.
12