Gestión de Software

Año 2006

Extreme Programming
(XP)

Grupo
Integrantes
Líber Batalla CI: 4.227.319-2
Diego Fontanarossa CI: 4.227.412-4
Javier Garderes CI: 4.011.702-7
Andrés Gatto CI: 3.875.419-8
Índice
ÍNDICE.........................................................................................................................................2
1 INTRODUCCIÓN.................................................................................................................3
2 HISTORIAS DE USUARIO...................................................................................................4
3 PROCESO Y FASES..............................................................................................................5
4 REGLAS Y PRÁCTICAS DE XP............................................................................................8
4.1 Planificación..................................................................................................................................8
4.2 Diseño...........................................................................................................................................10
4.3 Codificación.................................................................................................................................12
5 ROLES EN XP....................................................................................................................15
5.1 Programador...............................................................................................................................15
5.2 Cliente..........................................................................................................................................15
5.3 Encargado de pruebas (Tester).................................................................................................15
5.4 Encargado de seguimiento (Tracker).............................................................................................15
5.5 Entrenador (Coach)....................................................................................................................15
5.6 Gestor (Big Boss).........................................................................................................................16
5.7 Consultor.....................................................................................................................................16
5.8 Doomsayer (Augur de desastres).............................................................................................16
6 RELACIÓN ENTRE CONCEPTOS DE XP Y CMM..............................................................18
6.1 Nivel 1 – Inicial...........................................................................................................................18
6.2 Nivel 2 – Repetible.....................................................................................................................18
6.3 Nivel 3 - Definido......................................................................................................................19
6.4 Nivel 4 – Gestionado..................................................................................................................19
6.5 Nivel 5 – Optimizante................................................................................................................19
7 Conclusiones..................................................................................................................21
1 Introducción
Extreme Programming es una metodología ágil centrada en potenciar las
relaciones interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentación continua entre el cliente y el equipo de desarrollo, comunicación
fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy
cambiantes, y donde existe un alto riesgo técnico. Su creador Kent Beck.

«Todo en el software cambia. Los requisitos cambian. El

diseño cambia. El negocio cambia. La tecnología cambia.
El equipo cambia. Los miembros del equipo cambian. El
problema no es el cambio en sí mismo, puesto que
sabemos que el cambio va a suceder; el problema es la
incapacidad de adaptarnos a dicho cambio cuando éste
tiene lugar.»

Es el método que más popularidad ha alcanzado de las metodologías ágiles y

se basa en la suposición de que es posible desarrollar software de gran calidad a
pesar, o incluso como consecuencia del cambio continuo.
Asume que con un poco de planificación, un poco de codificación y unas pocas
pruebas se puede decidir si se está siguiendo un camino acertado o equivocado,
evitando así tener que echar marcha atrás demasiado tarde.
Esta metodología se inspira en los siguientes valores: simplicidad, feedback,
coraje y comunicación.
La simplicidad consiste en desarrollar sólo el sistema que realmente se necesita.
Implica resolver en cada momento sólo las necesidades actuales. Con este
principio de simplicidad, junto con la comunicación y el feedback resulta más
fácil conocer las necesidades reales.
Una metodología basada en el desarrollo incremental iterativo de pequeñas
partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de
retro-información (feedback) valioso para detectar los problemas o
desviaciones.
 De esta forma fallos se localizan muy pronto.
 La planificación no puede evitar algunos errores, que sólo se
evidencian al desarrollar el sistema.
 La retro-información es la herramienta que permite reajustar la
agenda y los planes.
El coraje implica saber tomar decisiones difíciles, reparar un error cuando se
detecta, mejorar el código siempre que tras el feedback y las sucesivas
iteraciones se manifieste susceptible de mejora.
XP pone en comunicación directa y continua a clientes y desarrolladores. El
cliente se integra en el equipo para establecer prioridades y resolver dudas. De
esta forma ve el avance día a día, y es posible ajustar la agenda y las
funcionalidades de forma consecuente.

2 Historias de Usuario
Las historias de usuario son la técnica utilizada en XP para especificar los
requisitos del software. Se trata de tarjetas de papel en las cuales el cliente
describe brevemente las características que el sistema debe poseer, sean
requisitos funcionales o no funcionales.
El tratamiento de las historias de usuario es muy dinámico y flexible, en
cualquier momento historias de usuario pueden romperse, reemplazarse por
otras más específicas o generales, añadirse nuevas o ser modificadas. Cada
historia de usuario es lo suficientemente comprensible y delimitada para que
los programadores puedan implementarla en unas semanas.
Respecto de la información contenida en la historia de usuario, existen varias
plantillas sugeridas pero no existe un consenso al respecto. En muchos casos
sólo se propone utilizar un nombre y una descripción o sólo una descripción,
más quizás una estimación de esfuerzo en días. Beck en su libro presenta un
ejemplo de ficha (customer story and task card) en la cual pueden reconocerse
los siguientes contenidos: fecha, tipo de actividad (nueva, corrección, mejora),
prueba funcional, número de historia, prioridad técnica y del cliente, referencia
a otra historia previa, riesgo, estimación técnica, descripción, notas y una lista
de seguimiento con la fecha, estado cosas por terminar y comentarios.
Una de las interrogantes (que también se presenta cuando se utilizan casos de
uso) es ¿cuál es el nivel de granularidad adecuado para una historia de usuario?
La respuesta no es tajante. Jeffries dice que depende de la complejidad del
sistema, debe haber al menos una historia por cada característica importante, y
propone realizar una o dos historias por programador por mes. Si se tienen
menos, probablemente sea conveniente dividir las historias, si se tienen más lo
mejor es disminuir el detalle y agruparlas.
Para efectos de planificación, las historias pueden ser de una a tres semanas de
tiempo de programación (para no superar el tamaño de una iteración).
No hay que preocuparse si en un principio no se identifican todas las historias
de usuario. Al comienzo de cada iteración estarán registrados los cambios en las
historias de usuario y según eso se planificará la siguiente iteración.
Las historias de usuario son descompuestas en tareas de programación y
asignadas a los programadores para ser implementadas durante una iteración.
3 Proceso y Fases
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a
implementar basado en la habilidad del equipo para medir la funcionalidad que
puede entregar a través del tiempo. El ciclo de desarrollo consiste (a grandes
rasgos) en los siguientes pasos:

1. El cliente define el valor de negocio a implementar.

2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las
restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.

En la siguiente figura se muestra como esta metodología es iterativa y utiliza

pequeños lapsos de tiempo para realizar las actividades. De tal forma de que los
cambios no sean tan costosos.

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.
El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de
la entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del
Proyecto.

Fase I: Exploración

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que
son de interés para la primera entrega del producto. Al mismo tiempo el equipo
de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se
utilizarán en el proyecto.
Se prueba la tecnología y se exploran las posibilidades de la arquitectura del
sistema construyendo un prototipo. La fase de exploración toma de pocas
semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los
programadores con la tecnología.

Fase II: Planificación de la Entrega

En esta fase el cliente establece la prioridad de cada historia de usuario, y

correspondientemente, los programadores realizan una estimación del esfuerzo
necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la
primera entrega y se determina un cronograma en conjunto con el cliente. Una
entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos
días.
Las estimaciones de esfuerzo asociado a la implementación de las historias la
establecen los programadores utilizando como medida el punto. Un punto,
equivale a una semana ideal de programación. Las historias generalmente valen
de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de
la “velocidad” de desarrollo, establecida en puntos por iteración, basándose
principalmente en la suma de puntos correspondientes a las historias de
usuario que fueron terminadas en la última iteración.
La planificación se puede realizar basándose en el tiempo o el alcance. La
velocidad del proyecto es utilizada para establecer cuántas historias se pueden
implementar antes de una fecha determinada o cuánto tiempo tomará
implementar un conjunto de historias. Al planificar por tiempo, se multiplica el
número de iteraciones por la velocidad del proyecto, determinándose cuántos
puntos se pueden completar. Al planificar según alcance del sistema, se divide
la suma de puntos de las historias de usuario seleccionadas entre la velocidad
del proyecto, obteniendo el número de iteraciones necesarias para su
implementación.

Fase III: Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El
Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En
la primera iteración se puede intentar establecer una arquitectura del sistema
que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo
las historias que fuercen la creación de esta arquitectura, sin embargo, esto no
siempre es posible ya que es el cliente quien decide qué historias se
implementarán en cada iteración (para maximizar el valor de negocio). Al final
de la última iteración el sistema estará listo para entrar en producción.
Los elementos que deben tomarse en cuenta durante la elaboración del Plan de
la Iteración son: historias de usuario no abordadas, velocidad del proyecto,
pruebas de aceptación no superadas en la iteración anterior y tareas no
terminadas en la iteración anterior.
Todo el trabajo de la iteración es expresado en tareas de programación, cada
una de ellas es asignada a un programador como responsable, pero llevadas a
cabo por parejas de programadores
Fase IV: Producción

La fase de producción requiere de pruebas adicionales y revisiones de

rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al
mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas
características a la versión actual, debido a cambios durante esta fase.
Es posible que se rebaje el tiempo que toma cada iteración, de tres a una
semana. Las ideas que han sido propuestas y las sugerencias son documentadas
para su posterior implementación (por ejemplo, durante la fase de
mantenimiento).

Fase V: Mantenimiento

Mientras la primera versión se encuentra en producción, el proyecto XP debe

mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas
iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De
esta forma, la velocidad de desarrollo puede bajar después de la puesta del
sistema en producción. La fase de mantenimiento puede requerir nuevo
personal dentro del equipo y cambios en su estructura.

Fase VI: Muerte del Proyecto

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto
requiere que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema. Se genera la documentación final del
sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto
también ocurre cuando el sistema no genera los beneficios esperados por el
cliente o cuando no hay presupuesto para mantenerlo.

La siguiente figura muestra la ejecución de las fases.

4 Reglas y Prácticas de XP
La principal suposición que se realiza en XP es la posibilidad de disminuir la
usual curva exponencial del costo del cambio a lo largo del proyecto, lo
suficiente para que el diseño evolutivo funcione. XP apuesta por un crecimiento
lento del costo del cambio y con un comportamiento asintótico. Esto se consigue
gracias a las tecnologías disponibles para ayudar en el desarrollo de software y
a la aplicación disciplinada de un conjunto de prácticas que en base a la
experiencia en proyectos de alto riesgo y requerimientos cambiantes, han
surgido como receta para un buen desempeño.

La mayoría de las prácticas propuestas por XP no son novedosas sino que en

alguna forma ya habían sido propuestas en ingeniería del software e incluso
demostrado su valor en la práctica. El mérito de XP es integrarlas de una forma
efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los
valores humanos y el trabajo en equipo.

4.1 Planificación

El “Juego” de la Planificación
Es un espacio frecuente de comunicación entre el cliente y los programadores.
El equipo técnico realiza una estimación del esfuerzo requerido para la
implementación de las historias de usuario y los clientes deciden sobre el
ámbito y tiempo de las entregas y de cada iteración. Esta práctica se puede
ilustrar como un juego, donde existen dos tipos de jugadores: Cliente y
Programador. El cliente establece la prioridad de cada historia de usuario, de
acuerdo con el valor que aporta para el negocio. Los programadores estiman el
esfuerzo asociado a cada historia de usuario. Se ordenan las historias de usuario
según prioridad y esfuerzo, y se define el contenido de la entrega y/o iteración,
apostando por enfrentar lo de más valor y riesgo cuanto antes. Este juego se
realiza durante la planificación de la entrega, en la planificación de cada
iteración y cuando sea necesario reconducir el proyecto.

Escribir Historias de Usuario

Las Historias de Usuario se crean con el mismo propósito que los Casos de Uso,
pero no son lo mismo. Se utilizan para crear estimaciones de tiempo para las
reuniones de planificación de las liberaciones. También son utilizadas en lugar
del Documento de Requerimientos.
Las Historias de Usuario son escritas por los clientes como las cosas que el
cliente necesita que el sistema haga por él. Son similares a los Escenarios de
Uso, excepto porque no están limitados a describir la interfaz de usuario. Deben
ser escritas con un formato de dos o tres líneas de texto, escritas por el cliente
usando la terminología del cliente sin términos técnicos.
Las Historias de Usuario también guían la creación de las Pruebas de
Aceptación. Uno o más tests automatizados de aceptación deberían ser creados
de forma que puedan verificar que una historia de usuario haya sido
implementada correctamente.
Las Historias de usuario deberían tener únicamente la granularidad suficiente
para realizar estimaciones de cuánto se tardarían en implementar.
Cuando llega el momento de implementar la Historia de Usuario, los miembros
del equipo encargados de desarrollarla deberían obtener una descripción más
detallada de los requerimientos personalmente (con el cliente).

Los planes de Liberación organizan el calendario

Las reuniones de Planificación de Liberaciones son utilizadas para construir un
Plan de Liberaciones, que organiza el proyecto.
Luego, el Plan de Liberaciones es utilizado para crear Planes de Iteración para
cada Iteración individual.
Es importante que las decisiones técnicas sean tomadas por el personal técnico
y las decisiones de negocios sean tomadas por el personal encargado del
negocio.
La esencia de la Reunión de Planificación de Liberaciones es estimar la duración
de la implementación de cada Historia de Usuario en términos de “Semanas
Ideales de Programación”.
Una “Semana Ideal de Programación” es cuánto se estima que llevaría
implementar la Historia de Usuario si no hubiese nada más que hacer (sin
tomar en cuenta trabajo extra, dependencias, etc., pero incluyendo la
implementación de tests).
El cliente elige luego cuál historia tiene mayor importancia o prioridad de ser
completada.
Se podría planificar por fecha o por alcance. La velocidad del proyecto es usada
para determinar cuántas historias pueden ser implementadas antes de una
fecha dada o cuánto tardarían en ser finalizadas un conjunto de historias.
Si se planifica por fecha, se podría determinar cuántas historias de usuario
podrán completarse multiplicando el número de iteraciones planificadas por la
velocidad del proyecto.
Si planificamos por alcance, se podría determinar el número de iteraciones
necesarias para finalizar la liberación dividiendo la cantidad de historias de
usuario por la velocidad del proyecto.

Entregas pequeñas
La idea es producir rápidamente versiones del sistema que sean operativas,
aunque obviamente no cuenten con toda la funcionalidad pretendida para el
sistema pero que constituyan un resultado de valor para el negocio. Una
entrega no debería tardar más de 3 meses.

Medir la velocidad del proyecto

La Velocidad del Proyecto es una medida de cuánto trabajo está siendo
completado en el proyecto. Para medirla, simplemente se sumarían las
estimaciones de las Historias de Usuario que fueron finalizadas durante la
Iteración.
Durante las Reuniones de Planificación de las Iteraciones, los clientes están
habilitados a elegir un número de historias a implementar igual a la Velocidad
del Proyecto medida en la Iteración anterior. Luego, son estudiadas
técnicamente y divididas en tareas técnicas, pudiendo el equipo comprometerse
a ejecutar el mismo número de tareas técnicas de la velocidad del proyecto
medida en la iteración anterior.
Mediante este mecanismo posibilita la mejora de la planificación por parte del
equipo luego de una iteración “difícil”.
La idea detrás del uso de la Velocidad del Proyecto es que las estimaciones
iniciales suelen ser poco precisas. Por lo cual, sería más redituable ejecutar
algunas iteraciones para poder medir y así obtener una idea más real sobre el
tamaño del proyecto.

Rotación del Equipo

La rotación del equipo evita problemas de conocimiento y de cuellos de botella.
Si una única persona puede trabajar en un área dada y esa persona deja el
equipo o tiene otras tareas pendientes, aparecerá un atraso en el avance.
En ocasiones el entrenamiento de personas para incorporarse a una nueva área,
es un problema que requiere atención para evitar “islas de conocimiento”.
La rotación del equipo en conjunto con la Programación en Parejas, lograrían
dicho entrenamiento.
En lugar de que una persona conozca el código de una sección completa, todo el
equipo conoce todo el código de cada sección.
Con esto el equipo se vuelve más flexible y se sobrecarga menos.

Mejorar el proceso cuando se detecten problemas

El proceso debería ser mejorado y reorganizado tan pronto como se detecten
problemas.
Las reglas de XP deberían ser seguidas en el comienzo pero deben estar abiertas
a cambios en lo que no funcione. Esto no significa que el equipo puede hacer
cualquier cosa, sino que las reglas pueden cambiarse una vez detectado que el
equipo ha cambiado su funcionamiento.
La única forma de tener una idea de cuánto esperar del equipo es teniendo
reglas claras de funcionamiento conocidas por todos.
Mediante reuniones con el equipo deberían ser detectados los problemas y de
ahí buscar la solución que mejor se adapte.

4.2 Diseño

Diseño Simple
Se debe diseñar la solución más simple que pueda funcionar y ser
implementada en un momento determinado del proyecto. Un diseño simple
siempre toma menos tiempo para finalizarlo que un complejo.
La complejidad innecesaria y el código extra debe ser removido
inmediatamente. Siempre es más rápido y más barato reemplazar ahora el
código complejo antes que gastemos más tiempo en él.
Hay que mantener las cosas lo más simples posibles tanto como sea posible a
través de no agregar nuevas funcionalidades antes de que sean agendadas.
Kent Beck dice que en cualquier momento el diseño adecuado para el software
es aquel que: supera con éxito todas las pruebas, no tiene lógica duplicada,
refleja claramente la intención de implementación de los programadores y tiene
el menor número posible de clases y métodos.
Metáforas
En XP no se enfatiza la definición temprana de una arquitectura estable para el
sistema. Dicha arquitectura se asume evolutiva y los posibles inconvenientes
que se generarían por no contar con ella explícitamente en el comienzo del
proyecto se solventan con la existencia de una metáfora.
El sistema es definido mediante una metáfora o un conjunto de metáforas
compartidas por el cliente y el equipo de desarrollo. Una metáfora es una
historia compartida que describe cómo debería funcionar el sistema. La práctica
de la metáfora consiste en formar un conjunto de nombres que actúen como
vocabulario para hablar sobre el dominio del problema. Este conjunto de
nombres ayuda a la nomenclatura de clases y métodos del sistema.

Tarjetas CRC
Usar Tarjetas CRC (Class, Responsibilities and Collaboration) para diseñar el
sistema en conjunto. La mayor ventaja de las tarjetas CRC es permitir reducir el
modo de pensar procedural y apreciar la tecnología de objetos. Las tarjetas CRC
permiten contribuir al diseño a todo el equipo del proyecto.

No agregar funcionalidades antes de lo planeado

Siempre estamos tentados en agregar funcionalidades ahora antes que después
debido a que sabemos exactamente como agregarla o porque haría al sistema
mucho mejor. Parecería que fuera más rápido agregarlas ahora pero nosotros
debemos recordarnos constantemente que no las necesitamos ahora realmente y
quizás nunca las necesitemos.
Funcionalidades extra siempre nos hacen atrasar y malgastar nuestros recursos.

Refactorización
La refactorización es una actividad constante de reestructuración del código con
el objetivo de remover duplicación de código, mejorar su legibilidad,
simplificarlo y hacerlo más flexible para facilitar los posteriores cambios.
La refactorización mejora la estructura interna del código sin alterar su
comportamiento externo. Refactorizar a lo largo de todo el proyecto nos ahorra
tiempo e incrementa la calidad.
El diseño del sistema de software es una cosa viviente. No se puede imponer
todo en un inicio, pero en el transcurso del tiempo este diseño evoluciona
conforme cambia la funcionalidad del sistema. Para mantener un diseño
apropiado, es necesario realizar actividades de cuidado continuo durante el
ciclo de vida del proyecto. De hecho, este cuidado continuo sobre el diseño es
incluso más importante que el diseño inicial. Un concepto pobre al inicio puede
ser corregido con esta actividad continua, pero sin ella, un buen diseño inicial se
degradará.

4.3 Codificación

El cliente está siempre disponible

El cliente tiene que estar presente y disponible todo el tiempo para el equipo.
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 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 historias de usuario son escritas por los clientes con la ayuda de los
desarrolladores. Los clientes aseguran que la mayoría de las funcionalidades
deseadas del sistema están cubiertas por las historias mientras que los
desarrolladores ayudan con las estimaciones de tiempo.
Durante la planificación de una liberación, el cliente debe negociar la selección
de las historias de usuario que serán incluidas en dicha liberación. El tiempo de
la liberación deberá ser discutido también. Los clientes deben realizar sus
decisiones de acuerdo a sus objetivos de negocio.
Como los detalles no son incluidos en las historias de usuario, los
desarrolladores necesitarán hablar con los clientes para obtener suficientes
detalles para completar una cierta actividad de programación.
El cliente también será necesario con las pruebas funcionales.

Pareciera que necesitáramos una gran cantidad de tiempo del cliente

comparado con otras metodologías, pero no debemos olvidarnos que el tiempo
del cliente es ahorrado al principio por no requerir una especificación detallada
de los requerimientos y ahorrado después ya que el sistema es mucho más
probable que sea de su agrado.

En algunos casos esta alta disponibilidad del cliente puede ser difícil de
conseguir. Algunas recomendaciones propuestas para dicha situación son las
siguientes: intentar conseguir un representante que pueda estar siempre
disponible y que actúe como interlocutor del cliente, contar con el cliente al
menos en las reuniones de planificación, establecer visitas frecuentes de los
programadores al cliente para validar el sistema, anticiparse a los problemas
asociados estableciendo llamadas telefónicas frecuentes y conferencias,
reforzando el compromiso de trabajo en equipo.

Estándares de programación
XP enfatiza la comunicación de los programadores a través del código, con lo
cual es indispensable que se sigan ciertos estándares de programación (del
equipo, de la organización u otros estándares reconocidos para los lenguajes de
programación utilizados). Los estándares de programación mantienen el código
legible para los miembros del equipo, facilitando los cambios.

Pruebas unitarias
La producción de código está dirigida por las pruebas unitarias. Las pruebas
unitarias son establecidas antes de escribir el código y son ejecutadas
constantemente ante cada modificación del sistema. Los clientes escriben las
pruebas funcionales para cada historia de usuario que deba validarse.
Cuando creamos las pruebas antes del código encontraremos más fácil y rápida
la realización del código ya que ayuda a los desarrolladores a entender lo que
debe ser hecho.
Hay también cierto beneficio en el diseño del sistema. A veces es muy difícil
testear ciertos sistemas de software, principalmente si el código es escrito antes
que las pruebas y por un equipo diferente. Si creamos las pruebas primero,
nuestro diseño será influenciado por el deseo de testear todo lo que es de valor
para nuestro cliente. El código que crearemos será simple y conciso,
implementando solo aquellas características necesarias. Otros desarrolladores
podrán ver como usar este nuevo código observando las pruebas.

En este contexto de desarrollo evolutivo y de énfasis en pruebas constantes, la

automatización para apoyar esta actividad es crucial.

Programación en parejas
Toda la producción de código debe realizarse con trabajo en parejas de
programadores. La programación de a pares incrementa la calidad del software
sin impactar el tiempo para cumplir lo prometido. No es muy intuitivo, pero
dos personas trabajando en una sola computadora agregarán tantas
funcionalidades como si estuvieran trabajando por separado, excepto que
lograrán una mayor calidad. Y con una mayor calidad tendremos grandes
ahorros de tiempo en el futuro.

Las principales ventajas de introducir este estilo de programación son: muchos

errores son detectados conforme son introducidos en el código (inspecciones de
código continuas), por consiguiente la tasa de errores del producto final es más
baja, los diseños son mejores y el tamaño del código menor (continua discusión
de ideas de los programadores), los problemas de programación se resuelven
más rápido, se posibilita la transferencia de conocimientos de programación
entre los miembros del equipo, varias personas entienden las diferentes partes
del sistema, los programadores conversan mejorando así el flujo de información
y la dinámica del equipo, y finalmente, los programadores disfrutan más su
trabajo. Dichos beneficios se consiguen después de varios meses de practicar la
programación en parejas.

La mejor forma de programar en parejas es sentarse un junto al otro en frente al

monitor. Una persona es la que codifica y piensa tácticamente acerca del
método que está siendo creado, mientras que la otra piensa estratégicamente
acerca de cómo dicho método encaja dentro de la clase.

Integración secuencial
El código es integrado en el repositorio tomando turnos. Esto es, solo una pareja
de desarrolladores puede integrar, testear y liberar cambios al repositorio de
código en un momento determinado. De esta forma se permite que la última
versión esté consistentemente identificada.
Esto no significa que uno no pueda integrar su código con la última versión en
su propia estación de trabajo. Lo que no se puede es liberar esos cambios al
resto del equipo sin esperar su turno.
Integración contínua
Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el
sistema puede llegar a ser integrado y construido varias veces en un mismo día.
En ningún caso se puede estar sin integrar por más de un día.

Es una forma de que todo el mundo esté trabajando con casi la última versión.
De este modo evitamos que los cambios sean hechos sobre versiones obsoletas,
lo que sería un gran problema a la hora de integrar. Además evita o detecta
antes los problemas de compatibilidad.

Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo
código sea incorporado definitivamente. La integración continua a menudo
reduce la fragmentación de los esfuerzos de los desarrolladores por falta de
comunicación sobre lo que puede ser reutilizado o compartido.

Propiedad colectiva del código

Cualquier programador puede cambiar cualquier parte del código en cualquier
momento. Esta práctica motiva a todos a contribuir con nuevas ideas en todos
los segmentos del sistema, evitando a la vez que algún programador sea
imprescindible para realizar cambios en alguna porción de código.

Optimizar al final
No hay que optimizar hasta el final. Tampoco hay que intentar adivinar cual
será el cuello de botella de nuestro sistema, sino que hay que medirlo.
“Hazlo que ande, hazlo bien, y luego hazlo rápido”.

40 horas por semana

Se debe trabajar un máximo de 40 horas por semana. No se trabajan 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.
5 Roles en XP

Aunque en otras fuentes de información aparecen algunas variaciones y

extensiones de roles XP, en este apartado describiremos los roles de acuerdo
con la propuesta original de Beck.

5.1 Programador
El 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. Debe existir una comunicación y coordinación adecuada
entre los programadores y otros miembros del equipo.

5.2 Cliente
El cliente escribe las historias de usuario y las pruebas funcionales para validar
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 sólo uno dentro del proyecto pero puede
corresponder a un interlocutor que está representando a varias personas que se
verán afectadas por el sistema. En cualquier caso, debe tener la autoridad
necesaria para responder dudas respecto a historias de usuario ya existentes.

5.3 Encargado de pruebas (Tester)

El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.
Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es
responsable de las herramientas de soporte para pruebas.

5.4 Encargado de seguimiento (Tracker)

El encargado de seguimiento proporciona realimentación al equipo en el
proceso XP. Su responsabilidad es verificar el grado de acierto entre las
estimaciones realizadas y el tiempo real dedicado, comunicando los resultados
para mejorar futuras estimaciones.
También realiza el seguimiento del progreso de cada iteración y evalúa si los
objetivos son alcanzables con las restricciones de tiempo y recursos presentes.
Mantiene contacto directo y continuo con el equipo de desarrollo evaluando la
situación. Determina cuándo es necesario realizar algún cambio para lograr los
objetivos de cada iteración, involucrando al Gestor, Entrenador, o al Cliente en
el caso considerarlo conveniente.

5.5 Entrenador (Coach)

Es responsable del proceso global. Es necesario que conozca a fondo el proceso
XP para proveer guías a los miembros del equipo de forma que se apliquen las
prácticas XP y se siga el proceso correctamente. Es el responsable de proveer la
tecnología y metodologías a usar por el equipo de desarrollo. Oficia de mentor
para los miembros menos experientes de forma de asegurar su desempeño en el
proyecto, y media entre los miembros del equipo para asegurar un ambiente
saludable de trabajo.

5.6 Gestor (Big Boss)

Es el dueño del equipo y sus problemas. Persona experta en tecnología y
labores de gestión, su labor esencial es de coordinación. Es la imagen del equipo
al exterior. Elige los miembros que conformaran el plantel, obtiene los recursos
necesarios y maneja los problemas que se generan. Agenda reuniones (planes
de iteración, agenda de compromisos, etc), verifica que se realicen de manera
adecuada y registra lo referente a las mismas.
No le dice al grupo lo que tiene que hacer (el Cliente y el plan de iteración lo
hacen), cuando hacerlo (la agenda de compromisos lo hace), ni verifica el
avance de las tareas (Tracker).

Roles opcionales:

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

5.8 Doomsayer (Augur de desastres)

Es el responsable de asegurarse que se conocen los riesgos involucrados, que las
malas noticias se den a conocer en la medida correcta, y que no se
sobredimensionen. Debe buscar posibles riesgos en forma constante,
presentándolos al equipo siempre con una alternativa para tratar el problema.

Combinación de Roles

Algunos roles pueden ser combinados en un mismo individuo. Por ejemplo, la

misma persona puede ser el Gestor y el Tracker simultáneamente.

Sin embargo, la combinación de otros roles perjudicaría al correcto desempeño

del rol como tal. Ejemplos de ello serian:

Programador-Tracker
Programador-Tester
Cliente-Programador
Entrenador-Tracker

El Gestor probablemente no debería ser combinado con ningún otro rol

excepto de Tracker. También se considera que el Entrenador no debería
combinarse con el Programador, aunque es posible que se realice en forma
exitosa.

Comparación de los Roles entre PIS y XP

A continuación de muestra una tabla con los roles mencionados en el Proyecto
de Ingeniería de Software (PIS), y los roles más similares que se presentan en
XP:
PIS XP
Administrador Gestor
Responsable de la Comunicación Entrenador
Analista Programador
Implementador Programador
Especialista Técnico Programador
Arquitecto Programador
Responsable de Reuso Programador
Diseñador de Interfaz de Usuario Programador
Responsable de Integración Programador
Asistente de Verificación Tester - Cliente
Responsable de Verificación Tester
Responsable de SQA Tester - Programador
Coordinador de Desarrollo N/A (Tracker)
Responsable de SCM N/A (Progamador)

Si bien los roles aquí comparados no son análogos en forma directa, las
responsabilidades implicadas se comparten en forma mayoritaria.

Existen casos a su vez en los que un rol definido convencionalmente pueda

repartir sus responsabilidades, como es el caso con el Cliente en XP. El mismo,
al proveer de las pruebas de aceptación desde el comienzo, puede ser visto
como un asistente de verificación.

Por otro lado, existen roles en PIS que no son definidos en forma explicita en
XP, como ser el caso de los Responsables en general. Si bien estas tareas deben
realizarse, la responsabilidad es más compartida entre los miembros del equipo.

En particular los roles de Coordinador de Desarrollo y el Responsable de SCM

no son contemplados en XP. En el caso de la gestión de configuración, al estar
tan relacionada con las actividades de los Programadores en XP lo
consideramos adecuado para la comparación. El Coordinador de Desarrollo
deja de existir en XP directamente ya que se definen las tareas a realizar en los
planes de iteración. Sin embargo, algunas de las tareas del Tracker pueden ser
comparables con ciertas responsabilidades del coordinador mencionado.
6 Relación entre conceptos de XP y CMM
Ron Jeffries (Consultor Senior internacional, quien ha participado activamente
desde los inicios de XP junto a Kent Beck, siendo el primer XP Coach con
dedicación completa (full-time)), plantea que ciertas características encontradas
en CMM (hasta en los niveles más altos), están presentes en el proceso de
desarrollo de XP y analiza nivel a nivel, los principales parecidos.

6.1 Nivel 1 – Inicial

XP específicamente recomienda dos niveles de planificación, los cuales forman

el “Juego” de la Planificación. Dichos niveles, están basados en las estimaciones
de los desarrolladores para la producción y en la priorización por parte del
cliente. El proceso de la Planificación conjunta resulta en un estimativo de qué
será producido y cómo. El Plan de Iteración, planifica un intervalo pequeño y
los resultados de cada iteración retroalimentan el siguiente plan para redefinir y
depurar la Planificación. Esto redundará en la atenuación de las sucesiones de
crisis características en las organizaciones clasificadas como Nivel 1 en CMM.

Las prácticas recomendadas por XP, redundan en la desaparición de “héroes”

imprescindibles encargados de “apagar incendios”. En su lugar, la aparición de
integrantes del equipo que se tornen imprescindibles, es un indicio de que algo
está funcionando mal, lo cual debería ser investigado en profundidad para
determinar sus causas para reparar el proceso.
A su vez, la práctica de la Programación en Parejas, redunda en no necesitar
personal excepcional para poder realizar el trabajo y en general es mejor tener
dos mentes atacando un problema que una excelente.

El Gestor, no especifica qué se debe hacer a cada momento. Por el contrario, se

dedica a controlar el progreso y a servir de interlocutor con la Dirección,
dejando las decisiones técnicas y las asignaciones para ser tratadas en conjunto
por el equipo de desarrollo y por un proceso voluntario.

Al ser visto de esta manera, XP apelaría a la correctitud del seguimiento del

proceso, más que a las individualidades dentro del equipo para resolver los
problemas, por lo que no dependería de las personas y podría pensarse que
sería repetible.

6.2 Nivel 2 – Repetible

XP claramente especifica un conjunto de prácticas las cuales están bien

definidas y están documentadas. El equipo debe estar entrenado al inicio del
proyecto, tiene un Coach en tiempo completo y entrena a los nuevos miembros
en las prácticas del proceso.
La programación en parejas y contar con un proceso abierto y accesible, asegura
que todos los miembros del equipo saben que está pasando en el sistema.
En XP existe la constante preocupación por cuatro variables: Recursos, Alcance,
Calidad y Tiempo. Dichas variables permitirían determinar si se está
cumpliendo la planificación con la calidad deseada a medida que transcurre el
proyecto, siendo posible reportar las mediciones a la alta gerencia.

A raíz de lo anterior, podría reunirse, a primera vista y cumpliendo con las

prácticas recomendadas, los requerimientos del nivel dos de CMM para hacer
del proceso XP un proceso repetible, practicable, definido, documentado,
capacitando a nuevo personal en él, medido y mejorable.

6.3 Nivel 3 - Definido

Las reglas de XP encaminarían el criterio de transparencia del proceso (por

ejemplo: la completitud de las Historias de Usuario), de las entradas, estándares
y procedimientos, mecanismos de verificación, salidas y criterios de aceptación.

Nuevamente, utilizando las cuatro variables especificadas anteriormente, XP

permitiría una gestión simple, teniendo una visión clara de la performance del
proceso.

6.4 Nivel 4 – Gestionado

XP especifica los objetivos de calidad para los productos mediante los Test
Funcionales. Permanentemente es requerido que las pruebas unitarias se
mantengan en un 100% de cumplimiento, por lo que el número de Pruebas
Unitarias correctas no sería una estadística interesante.
Podríamos definir el Factor de Carga, el cual relaciona el tiempo transcurrido
con las estimaciones de dificultad de los desarrolladores. Igualmente no sería
un objetivo cuantitativo, pero podrían medirse los cambios en el Factor de
Carga como una idea de hacia dónde apuntar los esfuerzos de mejora.

Algunas variables candidatas a ser medidas serían: el número de pruebas

unitarias vs. el número de clases del sistema, la tasa de cambios de creación de
tests, el número de clases, las tasas de líneas de código de clases/métodos, etc.

6.5 Nivel 5 – Optimizante

Las prácticas de XP recomiendan una mejora continua del proceso y del

desarrollo en sí, detectando cada falla en el transcurso del proyecto y teniendo
una retroalimentación para no repetir errores del pasado. Esto cabría en la
definición del Nivel 5 CMM asociado a la mejora continua.
Igualmente, no podemos olvidar el contexto en el cual XP estaría recomendado,
que es en proyectos de alto riesgo, con requerimientos cambiantes y con
equipos de trabajo no superiores en número a 20 personas, por lo que los
requerimientos de documentación y de rigurosidad de CMM son “aligerados”
por XP.
7 Conclusiones
Las metodologías ágiles han ganado popularidad desde que se publicó su
manifiesto, siendo XP el miembro del grupo que goza de mayor aceptación en
el área. Estas metodologías buscan simplificar los procesos a través de la
reducción de irreversibilidad de los mismos.
XP es una metodología que para ser aplicada en forma correcta deben seguirse
sus directivas en forma constante, aunque permite ciertas flexibilidades. Las
doce prácticas propuestas Kent Beck son un punto de comienzo, pero XP
variará en cada ambiente.
Debe hacerse notar que si se deja de lado el ambiente de trabajo abierto (las
instalaciones no lo permiten), el cliente en la misma oficina (si no tienen los
recursos de tiempo y personal necesarios), y la programación de a pares (al
equipo no le agrada y trabajan en forma remota), etc etc, puede pasar de
encontrarse pensando que se esta haciendo XP cuando en realidad no se están
obteniendo sus beneficios.
XP requiere que el equipo sea consciente y piense en lo que funciona de manera
correcta y lo que no, buscando nuevas formas de mejorar el proceso.

¿Qué nos dice XP que ya sabíamos? Numerosas cosas:

La alta comunicación funciona. Si el equipo se establece en una misma

sala donde se puedan tomar decisiones y evaluar los resultados, la
velocidad de las cosas aumenta dramáticamente.

La Validación es importante. XP reduce el tiempo entre una idea, su

criterio de validación, y su implementación. Al requerir tests repetibles
automatizados, el equipo se asegura de estar avanzando correctamente.

El Iterar funciona. La idea de las iteraciones no es nueva, pero muchos

equipos declaran ser iterativos cuando no lo son. XP obliga a iterar al
establecer múltiples integraciones por día, iteraciones de una a tres
semanas de largo que concluyan con un sistema funcionando, y nuevos
lanzamientos cada pocos meses.

¿Cuál es el mayor desafío involucrado al implementar XP?

Identificar e implementar el 90% de las soluciones

Fragmentar las historias en historias más sencillas y consistentes.

Saber distinguir entre lo que es importante y lo que no.

¿Hacia donde va XP? En las siguientes líneas se encontraran algunas de las
opiniones más populares al respecto:

La simplificación y clarificación del proceso. El proceso de planificación

aun se siente algo más complicado de lo que debería ser. La forma de
integrar continuamente probablemente no se encuentre explicada
suficientemente. La idea básica es muy poderosa, pero muchos equipos
aun no la utilizan.

Buscar valores ocultos. La comunidad de XP ha estado explorando en

busca de principios ocultos que puedan informar de métodos útiles.

Limites de XP. ¿Puede un equipo grande utilizar XP? ¿Cuándo y dónde

XP es la opción correcta a seguir?

Tests de Aceptación. XP usa tests de aceptación automatizados

generados por el propio cliente. A medida que esta práctica se
implemente en distintos ambientes posiblemente se note un impacto en
la opinión de los desarrolladores.

El rol del Cliente. La visión del programador en este rol es: “Déme un
grupo de historias sencillas para trabajar, responda todas mis preguntas,
y déme un grupo de tests para saber cuando habré terminado.”. Ser
cliente de software es un trabajo complejo, y posiblemente se generen
nuevas ideas al respecto.