Metodologias Agiles Enseñanza

Metodologas giles, Programacin Extrema
INDICE
1. Introduccin.....................................................................................................................................................3
Metodologas Agiles, programacin extrema

Lic. Horacio Kuna ASC Sergio Caballero
2. La no metodologa...........................................................................................................................................4
3. Metodologas.................................................................................................................................................5
4. Metodologas Agiles.....................................................................................................................................6
4.1. Caractersticas bsicas.........................................................................................................................6
4.2 Antecedentes...............................................................................................................................................7
4.3. Caractersticas principales.......................................................................................................................7
4.4. Diferencias con las metodologas tradicionales...................................................................................8
5. Las Metodologas.....................................................................................................................................12
6. Manifiesto para el Desarrollo de Software gil......................................................................................17
7. XP..................................................................................................................................................................18
7.1. Riesgos....................................................................................................................................................20
7.2. Variables a considerar.........................................................................................................................22
7.3. Los valores...............................................................................................................................................22
7.3.1. Comunicacin.....................................................................................................................................22
7.3.2. Valenta...................................................................................................................................................23
7.3.3. Realimentacin (feedback)...................................................................................................................23
7.3.4. Simplicidad.............................................................................................................................................24
7.4. Principios bsicos.......................................................................................................................................24
7.5. Las actividades bsicas en el desarrollo de sistema..................................................................26
7.6. Las 12 prcticas.....................................................................................................................................27
7.6.1. Testing...................................................................................................................................................27
7.6.2. Programacin por pares de Programadores..............................................................................28
7.6.3. Diseo Simple.....................................................................................................................................29
7.6.4. Refactorizacin permanente...........................................................................................................29
7.6.5 Cliente On-Site.....................................................................................................................................30
7.6.6. Taller de planificacin.......................................................................................................................30
7.6.7. Integracin continua.........................................................................................................................31
7.6.8. Pequeos releases............................................................................................................................31
7.6.9. Propiedad Colectiva del cdigo.....................................................................................................32
7.6.10. Estndares de Codificacin..........................................................................................................32
7.6.11. Metforas del sistema.....................................................................................................................32
7.6.12. Semana de 40 Horas.......................................................................................................................33
7.7. Contexto de eXtreme Programing........................................................................................................33
7.8. Estrategias de gerenciamiento..........................................................................................................33
7.9. El espacio de trabajo............................................................................................................................34
7.10. Estrategias de planificacin en XP.................................................................................................34
7.11. Estrategias de desarrollo..................................................................................................................35
7.12. Estrategias de diseo........................................................................................................................35
7.13. Estrategias de testing........................................................................................................................35
7.14. Implementando XP..............................................................................................................................36
7.14.1. Integracin del equipo de trabajo y definicin de necesidades:........................................36
7.14.2. Planificacin......................................................................................................................................37
7.14.3. Diseo................................................................................................................................................37
7.14.4. Diseo de pruebas y codificacin...............................................................................................38
7.14.5. Integracin.........................................................................................................................................38
7.14.6. Refactorizacin.................................................................................................................................38
8. XP y Open Source.....................................................................................................................................39
9. Conclusiones.............................................................................................................................................43
10.Bibliografa................................................................................................................................................46
1. Introduccin
La sociedad del conocimiento, la globalizacin de la economa, el avance de la

tecnologa, hacen cada vez ms voltiles, tanto los requerimientos de los
sistemas, como los entornos en los que se desarrollan, esto profundiza la Crisis
del Software, siendo necesaria la revisin de las metodologas aplicadas hasta el
momento de manera de adaptar las metodologas, tcnicas y procedimientos a los
cambios que se producen.
A lo largo del tiempo se ha pasado por varias etapas en el desarrollo de sistemas,
en particular los pequeos y medianos sistemas sobre los que tratar este trabajo,
desde la no metodologa a la aplicacin de metodologa ingenieriles.
Pese a los esfuerzos por aplicar mtodos ingenieriles al desarrollo de sistemas, se
observa en general que los proyectos software que no llegan a implementarse o
que no satisfacen las necesidades de los clientes, es creciente. En este marco es
que aparecen con cada vez ms fuerza las llamadas Metodologas giles como
un intento de dar respuesta a esta situacin.
2. La no metodologa
En particular en los sistemas pequeos, se verifica que muchos de los desarrollos

se caracterizan por la no aplicacin de metodologa alguna, en general utilizando
el criterio de codificar y corregir, esta manera de desarrollar sistemas se puede
utilizar con dudoso resultado en pequeas aplicaciones, provocando en general
sistemas con enorme cantidad de bugs, en los que la etapa de depuracin abarca
mucho tiempo despus que el sistema esta en produccin, con usuarios que
sienten que nunca se cumplen sus expectativas iniciales, con costos superiores a
los previstos y con plazos que nunca se cumplen.
Dada la complejidad de los sistemas de Informacin esta manera de desarrollar
sistemas es casi imposible de aplicar en sistemas medianos y grandes.
3. Metodologas
En la mayora de las ingenieras los procesos constructivos son definidos y

predictivos, comenzando de una manera determinada, bajo las mismas
condiciones se llega al mismo resultado, esto NO ES lo que caracteriza el proceso
de construccin del Software, en este caso se trata de procesos empricos donde
la volatilidad de los requisitos es una caracterstica en la mayora de los proyectos.
Las metodologas ingenieriles para el desarrollo de sistemas han estado presentes
durante mucho tiempo y en general no han sido muy exitosas, la crtica que se les
hace es que son muy burocrticas y pesadas, por ejemplo Merisse, SSADM,
Metrica, etc.
En muchos de los proyectos que aplican este tipo de metodologas se observa que
el cliente y el producto pasan a segundo plano, siendo el eje del desarrollo el
cumplimiento de la planificacin y la documentacin. En el caso de los sistemas
que se han implementado suele suceder que es muy costosa la adaptacin de los
mismos a los nuevos requerimientos, que la documentacin se desactualiza
rpidamente y que el proceso de Gestin de Configuracin se hace muchas veces
inviable por los constantes cambios y el costo que implica mantener la
documentacin actualizada.
Entonces porque no poner el eje en el cliente, en el producto y en la realidad?.
4. Metodologas giles
4.1. Caractersticas bsicas

Como reaccin a lo que muchos consideran un fracaso surgi un grupo de
metodologas que en principio se llamaron Metodologas ligeras y ahora se las
conoce como Metodologas giles, para mucha gente lo importante de ellas es
su reaccin ante la monumentalidad de las metodologas predictivas tradicionales.
Algunas diferencias entre los mtodos giles y los tradicionales son:
Los mtodos ingenieriles tradicionales ponen el acento en la planificacin,

por lo tanto es difcil su adaptacin al cambio, en cambio los mtodos giles
son adaptables en lugar de predictivos. Para los mtodos giles el cambio
es una caracterstica del proceso de desarrollo y estn preparados para
adaptarse a estos cambios.
Los mtodos tradicionales estn orientados a los procesos y los giles a la

gente. Para los mtodos giles la base del xito esta en el equipo de
trabajo y no en la Planificacin. La base de las metodologas tradicionales
es la documentacin a diferencia de las metodologas giles que su base es
el cdigo fuente.
Los mtodos giles son adaptables en lugar de predictivos

Los mtodos giles estn orientados a la gente y no orientados al proceso
4.2 Antecedentes
Se detectan antecedentes de este tipo de metodologas en forma paralela en

varios lugares del mundo:
Dynamic System development Method, en Europa.
Feature Driven Development, en Australia
XP, Crystal, Adaptative Software Development, Scrum en Estados Unidos.
4.3. Caractersticas principales

Los mtodos giles cambian significativamente algunos de los nfasis de los
mtodos ingenieriles.
La diferencia inmediata es que son menos orientados al documento, exigiendo una
cantidad ms pequea de documentacin para una tarea dada. Se trata de
mtodos orientados al cdigo siguiendo un camino que dice que la parte
importante de la documentacin es el cdigo fuente.
Los mtodos ingenieriles tienden a intentar planear una parte grande del proceso
del software en gran detalle para un plazo largo de tiempo, esto funciona bien
hasta que las cosas cambian. As que su naturaleza es resistirse al cambio. Para
los mtodos giles, los cambios son bienvenidos. Intentan ser procesos que se
adaptan y crecen en el cambio, incluso al punto de cambiarse ellos mismos.
Los mtodos giles estn orientados a la gente y no orientados al proceso como la
mayora de los mtodos ingenieriles. La meta de los mtodos ingenieriles es
definir un proceso que funcionar bien con cualquiera que lo use. Los mtodos
giles afirman que lo central para el xito de un proyecto son las habilidades del
equipo de desarrollo, de modo que el papel del proceso es apoyar al equipo de
desarrollo en su trabajo. Explcitamente puntualizan el trabajar a favor de la
naturaleza humana en lugar de en su contra y enfatizan que el desarrollo de
software debe ser una actividad agradable para quien la desarrolla.
4.4. Diferencias con las metodologas tradicionales

Separacin de Diseo y Construccin / Diseo y construccin integrados

Las metodologas ingenieriles tradicionales se basan en realizar un plan y un
diseo y despus construir la aplicacin lo ms exacta posible de lo
planeado y diseado, por lo tanto el proceso de construccin es menos
intelectual y predecible.
La pregunta es si esto es posible en los proyectos software, es factible que el
proceso de construccin sea predecible?, basta slo recordar en nuestra
experiencia personal cuantas veces los programadores destrozaron el diseo
original para que sea posible su implementacin. En general se est utilizando el
formalismo U.M.L. (Lenguaje Unificado de Modelado) pero muchos lo reconocen
como bueno en el papel pero con muchos inconvenientes a la hora de la etapa de
programacin.
Otro problema es el costo comparativo. Cuando se construye un puente, el costo
del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la
construccin. En los proyectos software basados en metodologa predictivas la
cantidad de tiempo utilizada codificando es mucho menor.
Requisitos estables / Impredecibilidad de los Requisitos

Hace muchos aos, los sistemas de informacin se caracterizaban por su
estabilidad y predicibilidad, pero es una realidad que la globalizacin y los
constantes cambios tecnolgicos que vivimos hacen que los requisitos sean cada
vez ms voltiles, los cambios en muchos casos se producen en forma diaria, por
cierto nuestro pas es un cono de esta situacin, entonces si se esta trabajando
en procesos de alta impredictibilidad no se puede usar una metodologa predictiva
de acuerdo a la opinin de quienes sostienen las metodologas giles.
Grandes cambios en cada versin / Iteraciones

Refinamiento sucesivo, desarrollo incremetal, interactivo, espiral, prototipo, etc.,

muchos son los nombres pero la base conceptual es la misma, se trata de producir
en forma frecuente versiones que funcionen y que sean depuradas hasta llegar al
producto final que satisfaga al cliente
XP sugiere iteraciones de entre una y tres semanas. SCRUM propone realizar un
release por mes. Cristal estira aun ms. La tendencia, es hacer las interacciones
los mas cortas posibles, esta es la manera de garantizar que los cambios que
tiene cada nueva versin del sistema son tan pequeos que el impacto de una
modificacin en los requisitos es mucho menor que en el caso de los sistemas
donde cada versin contiene grandes cambios.
Esto no significa que no se pueda fijar un presupuesto para software por
adelantado. Lo que significa es que no se puede fijar el tiempo, precio y alcance
de manera dura. La manera gil usual es fijar tiempo y precio y permitir que el
alcance pueda moverse de manera controlada.
Clientes pasivos / Clientes activos

Las metodologas tradicionales suelen asignarle a los clientes un rol secundario,
son casi un mal necesario que cumplen un rol en especial en las primeras etapas
del ciclo de vida y despus que el producto est terminado, prcticamente no
intervienen en la construccin del mismo
Para los defensores de las metodologas giles sta es una de las principales
causas del fracaso de muchos proyectos, el objetivo es que el usuario participe en
forma activa a lo largo de todo el ciclo de vida.
Lderes de proyecto con rol central / Equipos de desarrollo con rol

central
Las metodologas de desarrollo de sistemas basadas en procesos predictibles
consideran a los programadores en un rol pasivo que tienen prcticamente que
obedecer el diseo establecido y su opinin usualmente no es tenida en cuenta.

Los partidarios de las metodologas giles opinan que para poder ejecutar
proyectos se requiere un equipo muy eficaz de desarrolladores. El equipo necesita
ser eficaz tanto en la calidad de los individuos como en la manera en que
funcionan juntos en equipo.
En esta filosofa las personas no se consideran como recursos sino como actores
centrales que deben tomar decisiones tcnicas importantes y en algunos casos
como XP son los que pueden estimar el tiempo que tomar el trabajo.
La base es la planificacin / La base son las pruebas

Lo que gua el desarrollo en las metodologas giles son las pruebas, que son
diseadas entre el equipo de desarrollo y el cliente que se integra a ese
equipo antes de la codificacin. A diferencia de las metodologas
tradicionales donde lo que gua el desarrollo es la documentacin
Metrica rgida / mtrica flexible

Los mtodos tradicionales consideran ms eficaz la gestin basada en mtricas,
aplicando tcnicas especficas para establecer esas mtricas (punto de funcin
Cocomo, por ejemplo).
Los defensores de las metodologas giles consideran que el desarrollo de
software tiene caractersticas tales que la gestin basada en mtricas lleva el
trastorno de la medida a niveles muy importantes. Se considera ms eficaz usar
un estilo delegatorio de administracin, donde por ejemplo los programadores son
los que establecen los tiempos del desarrollo.

10
Cuadro comparativo
Metodologas giles
Metodologas no giles
Grupos pequeos (< 12 integrantes) y

trabajando en el mismo sitio.
Menos nfasis en la arquitectura.
Grupos grandes de trabajo.
El cliente es parte del equipo de desarrollo

(adems in-situ).
El cliente interacta con el equipo

de desarrollo mediante reuniones.
Pequeos cambios en cada versin
Grandes cambios en cada versin
Rol central del equipo de desarrollo
Rol central del lder de proyecto y

diseadores
Desarrollo basado en pruebas
Desarrollo basado en la
planificacin
Existe un contrato prefijado.
No existe un contrato tradicional o al

menos es bastante flexible.
Diseo y construccin integrados
Fcilmente adaptable a los cambios
La arquitectura es esencial.
Separacin diseo y construccin

Difcil de adaptar a los cambios

11
5. Las Metodologas
XP (Programacin Extrema)
Formalmente el trmino Extreme Programming se dio a conocer en un
artculo en la edicin de octubre de 1998 de la revista Distributed Computing, en el
que se relataba la experiencia del Equipo C3 en el desarrollo del sistema de pago
de Chrysler, mejor conocido como Chrysler Comprehensive Compensation. Entre
los miembros del equipo C3 se encontraban Kent Beck, Ron Jeffries y Martin
Fowler. Beck es conocido como el padre de XP gracias a la publicacin, en 1999
de Extreme Programming Explained.
Aunque el sistema de Chrysler dej de utilizarse a finales del ao 2000 el
mensaje de XP est cada vez ms extendido y el xito de las conferencias de
Programacin Extrema y metodologas giles es cada vez mayor.
La XP empieza con cuatro valores: Comunicacin, Retroalimentacin, Simplicidad
y Coraje.
XP construye un proceso de diseo evolutivo que se basa en refactorar un sistema
simple en cada iteracin
La Familia de Crystal de Cockburn

Alistair Cockburn ha estado trabajando en metodologas desde que la IBM le
encarg escribir sobre ellas a inicios de los 90.
Su libro, Sobreviviendo Proyectos Orientados a Objetos, fue su primer consejo en
proyectos corrientes. Ms recientemente Alistair escribi un libro de de desarrollo
de software gil que mira los principios subyacentes de este tipo de metodologas.
Desde ese libro ha explorado ms los mtodos giles, desarrollando la familia de
metodologas Crystal.
Se trata de una familia, ya que Cockburn considera que diferentes proyectos
requieren diferentes metodologias. l observa esta variacin a lo largo de dos
ejes: el nmero de personas en el proyecto, y las consecuencias de los errores.
Cristal comparte con la XP una orientacin humana, pero esta centralizacin en la
gente se hace de una manera diferente. Alistair considera que las personas
12
encuentran difcil seguir un proceso disciplinado, as que ms que seguir la alta

disciplina de la XP, Alistair explora la metodologa menos disciplinada que an
podra tener xito, intercambiando conscientemente productividad por facilidad de
ejecucin.
Alistair tambin pone mucho peso en las revisiones al final de la iteracin,
animando al proceso a ser auto-mejorable.
Cdigo Abierto
Los principios del Open Source son:
Redistribucin libre: La licencia no deber impedir la venta o el ofrecimiento

del software
con un componente de una distribucin agregado,
conteniendo programas de muchas distintas fuentes.
Cdigo fuente: El programa debe incluir el cdigo fuente y se debe distribuir

tanto el ejecutable como este ltimo.
Trabajos derivados: La licencia debe permitir modificaciones y trabajos

derivados.
Integridad del cdigo fuente y del autor: Se debe mantener la integridad con
el cdigo desarrollado por el propietario del proyecto
No a la discriminacin de personas o grupos: no se puede discriminar a

ninguno en un proyecto basado en la filosofa Open Source.
No a la discriminacin de campos laborales: no se tiene que restringir a

nadie en el uso del sistema en un campo laboral especfico.
Distribucin de la licencia: Los derechos adjuntos al programa tienen que

aplicarse a todos aquellos que reciben el programa sin la necesidad de
ejecutar una licencia adicional para estas partes.
La licencia no tiene que ser especfica de un producto: Los derechos

adjuntos al programa no deben depender de que el programa forme parte
de una distribucin particular del software

13
La licencia no tiene que restringir a otro software: La licencia no tiene que

colocar restricciones en otro software que es distribuido junto con el
desarrollo licenciado.
Se desarrollar ms adelante en detalle las diferencias y similitudes entre XP y

Open Source.
El Desarrollo de Software Adaptable de Highsmith

Jim Highsmith despus de trabajar durante aos con metodologas predictica, de
desarrollarlas y ensearlas concluy que son profundamente defectuosas,
particularmente para los negocios modernos.
Su reciente libro se enfoca en la naturaleza adaptable de las nuevas
metodologas, con un nfasis particular en aplicar las ideas que se originaron en el
mundo de los sistemas complejos adaptables (normalmente conocida como teora
del caos).
No se trata de la descripcin detallada de actividades a desarrollar como lo hace
XP, pero proporciona la base fundamental de por qu el desarrollo adaptable.
El corazn del Desarrollo de Software Adaptable tiene tres fases que se
desarrollan en paralelo:
Especulacin
Colaboracin
Aprendizaje
Highsmith ve la planificacin como una paradoja en un ambiente adaptable, ya

que los resultados son naturalmente imprevisibles
En este ambiente imprevisible se necesita que las personas colaboren de la mejor
manera para tratar con la incertidumbre. La atencin de la gerencia es menor en lo
que tiene que hacer la gente y mayor sobre la comunicacin alentadora para que
las personas puedan proponer las respuestas creativas ellos mismos.
En ambientes predictivos, el aprendizaje se desalienta a menudo. Las cosas se
ponen de antemano y entonces se sigue ese diseo.
14
En un ambiente adaptable, aprender desafa a todos (desarrolladores y clientes) a

examinar sus presunciones y usar los resultados de cada ciclo de desarrollo para
adaptar el siguiente.
El aprendizaje como tal es un rasgo continuo e importante, que asume que los
planes y los diseos deben cambiar conforme avanza el desarrollo.
El beneficio atropellado, poderoso, indivisible y predominante del Ciclo de Vida de
Desarrollo Adaptable es que nos obliga a confrontar los modelos mentales que
estn en la raz de nuestro autoengao. Nos obliga a estimar con realismo nuestra
habilidad.
Scrum
Scrum divide un proyecto en iteraciones denominadas carreras cortas de 30
das. Antes de que comience una carrera se define la funcionalidad requerida para
esa carrera y entonces se deja al equipo para que la desarrolle. El punto es
estabilizar los requisitos durante la carrera.
Sin embargo la gerencia no se desentiende durante la carrera corta. Todos los
das el equipo sostiene una junta corta (quince minutos), llamada scrum, donde el
equipo discurre lo que har al da siguiente
Desarrollo Manejado por Rasgos

Jeff De Luca y OO Peter Coad disearon El Desarrollo Manejado por Rasgos
(FDD). Como las otras metodologas adaptables, se enfoca en iteraciones cortas
que entregan funcionalidad tangible. En el caso del FDD las iteraciones duran dos
semanas.
El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.
Desarrollar un Modelo Global
Construir una Lista de los Rasgos
Planear por Rasgo
Disear por Rasgo

15
Construir por Rasgo
DSDM (Mtodo de Desarrollo de Sistema Dinmico)

El Mtodo de Desarrollo de Sistema Dinmico empez en Gran Bretaa en 1994
como un consorcio de compaas del Reino Unido que queran construir sobre
RAD (Diseo Rpido de Aplicaciones). El resto del proceso forma tres ciclos
relacionados:
el ciclo del modelo funcional produce documentacin de anlisis y

prototipos
el ciclo de diseo del modelo disea el sistema para uso operacional
el ciclo de implantacin se ocupa del despliegue al uso operacional

16
6. Manifiesto para el Desarrollo de Software gil

A partir de reconocer la similitud en muchas metodologas, surge el inters de
realizar un trabajo colaborativo y en febrero de 2001 se renen representantes de
17 metodologias con caractersticas comunes en un taller de dos das que se
realiza en Snowbird, Utah, USA. Y se elabora lo que se conoce con el nombre de
Manifiesto de las metodologas giles:
Los individuos e interacciones son ms

importantes que los procesos y herramientas
Software que funcione es ms importante que
la documentacin exhaustiva.
La colaboracin con el cliente es ms
importante que la negociacin de contratos
La respuesta ante los cambios es ms
importante que el seguimiento de un plan
Este Manifiesto fue suscripto por :
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

17
7. XP
Kent Beck define al XP como Un proceso ligero, de bajo riesgo, flexible,
predecible, cientfico y divertido de desarrollar Software.
Allistair Cockburn lo define como Una metodologa gil que requiere gran
disciplina
Al igual que la mayora de metodologas de desarrollo de software, la
programacin extrema no es el resultado de un plan maestro incubado en las
mentes de genios, sino el fruto de la formalizacin de un conjunto de prcticas que
demostraron ser exitosas en el desarrollo de sistema.
Se diferencia de otras metodologas por:

Su acercamiento a la planificacin incremental que rpidamente propone un
plan global que se espera que evolucione a travs de la vida del proyecto.
Su habilidad para definir las funcionalidades de la aplicacin de manera
flexible, de manera de dar respuesta a las cada vez ms cambiantes
necesidades de los negocios.
Su regeneracin a partir de ciclos cortos.
Su confianza en un proceso de testing escrito por programadores y clientes
que supervisa el progreso del desarrollo, de esta manera se posibilita tomar los
defectos a tiempo y corrigindolos, posibilitar la evolucin del sistema hacia lo
que el cliente necesita en ese momento.

18
Su confianza en la comunicacin oral, las pruebas y el cdigo de la fuente para

comunicar la estructura del sistema.
Su confianza en un proceso del plan evolutivo que dura toda la vida til del
sistema.
Su confianza en la colaboracin ntima de programadores.
El ciclo de vida
Si los largos ciclos de desarrollo de los mtodos tradicionales son incapaces de

adaptarse al cambio, tal vez haya que trabajar en ciclos de desarrollo ms cortos.
Esta es una de las ideas centrales de XP.
En la figura se observa una comparativa grfica entre el modelo en cascada, el
modelo en espiral y XP.
7.1. Riesgos
19
En las metodologas tradicionales se observa que gran cantidad de riesgos se

hacen presentes y se convierten en problemas que hacen que en una enorme
cantidad de casos los proyectos fracasen, algunos de estos riesgos son:
Errores en la planificacin, no se cumple la planificacin original y esto implica

atrasos altamente costosos.
Proyectos que se cancelan antes de entrar en la fase de produccin.
Errores en el sistema que ya est en produccin, la gran cantidad de errores

provoca que despus de un tiempo se evale necesario remplazarlo ya que el
costo de corregir esos errores es ms alto que remplazarlo por otro sistema.
La cantidad de errores es tan grande que inviabiliza la utilizacin del sistema.
Desarrolladores que no entendieron bien el negocio y producen software que

no resuelve los problemas que se propuso originalmente.
El sistema se pone en produccin pero los requerimientos originales han

cambiado desde el momento en que se plantearon hasta el momento en que el
sistema se termina.
La produccin de los desarrolladores se degrada con el tiempo.
XP intenta dar respuesta a cada uno de esos riesgos:

Errores en la planificacin, no se cumple la planificacin original y esto implica
atrasos altamente costosos.
XP plantea ciclos cortos de interaccin (cuatro semanas), al segmentarla, se
limita cualquier error en la planificacin. XP ataca primero los rasgos
principales del sistema entonces el costo de cualquier error en la planificacin
al producir los rasgos principales tiene menor costo.
Proyectos que se cancelan antes de entrar en la fase de produccin.

Se trabaja con pequeos releases por lo tanto el trabajo anterior al primer
release es menor que en las metodologas tradicionales y las prdidas son
menores en el caso de una cancelacin anticipada.
Errores en el sistema que ya est en produccin, la gran cantidad de errores

provoca que despus de un tiempo se evale necesario remplazarlo ya que el
costo de corregir esos errores es ms alto que remplazarlo por otro sistema.
20
XP garantiza la calidad a partir de que las pruebas guan el proceso de diseo,
La cantidad de errores es tan grande que inviabiliza la utilizacin del sistema.

XP Disea las pruebas antes de comenzar la codificacin en forma conjunta
entre los programadores y el cliente.
Desarrolladores que no entendieron bien el negocio y producen software que

no resuelve los problemas que se propuso originalmente.
XP plantea que el cliente debe ser parte activa del equipo de desarrollo, las
especificaciones del proyecto son continuamente refinadas durante el mismo,
el aprendizaje permanente que tienen el cliente y los desarrolladores se refleja
en el producto final.
El sistema se pone en produccin pero los requerimientos originales han

cambiado desde el momento en que se plantearon hasta el momento en que el
sistema se termina.
XP al trabajar con pequeos releases, plantear interacciones cortas en el
tiempo y tener al cliente in situ reduce sustancialmente el riesgo de obtener
un producto que no responda a las necesidades del usuario ya que estas se
van ajustando en cada pequeo release.
La produccin de los desarrolladores se degrada con el tiempo.

XP tiene como uno de sus principios la responsabilidad de los programadores,
tienen un rol sustantivo en el desarrollo, por ejemplo estimando los plazos,
caractersticas arquitectnicas, etc. por otro lado el trabajo cooperativo, la
programacin por pares, el objetivo que el equipo acepte gradualmente cada
vez ms responsabilidad, hacen que la motivacin de los desarrolladores sea
mucho mayor que en las metodologas tradicionales donde el programador es
un sujeto mucho ms pasivo que en general debe obedecer sin tener mucha
participacin en las decisiones importantes.
7.2. Variables a considerar

Las variables que guan el proceso del desarrollo de un sistema son:

21
Costo
Tiempo
Calidad
Alcance
De estas variables el alcance es fundamental para el xito de un proyecto.
XP plantea que el cliente debe tener control sobre al menos 3 variables y el equipo
de desarrollo sobre la restante.
7.3. Los valores

XP se basa en 4 valores que tienen como objetivo garantizar el xito de un
proyecto, estos valores son:
Comunicacin
Valenta
Retroalimentacin
Simplicidad
7.3.1. Comunicacin
Desde el momento en que se detecta un problema, la comunicacin comienza a
ser un elemento central en el desarrollo de productos Software.

En eXtreme Programming, esta comunicacin es central, se considera que los
integrantes del equipo cuando establecen una comunicacin directa es mucho
ms eficaz que si esta comunicacin se mediatiza o es indirecta, se plantea contar
con entornos de desarrollo confortables que incentiven esta comunicacin.
El equipo de desarrollo debera estar compuesto tambin por un representante
autorizado del cliente, con ello no slo se mejora la comunicacin entre
desarrolladores, sino tambin entre stos y los clientes, elemento central para
garantizar el xito de los proyectos.
Cuando aparecen los problemas se resuelven en el momento, la comunicacin es
directa y no se debe perder tiempo yendo a consultar al cliente, ya que el mismo
est presente y todo el equipo participa de las soluciones. Es importante tener en
22
cuenta que en muchos desarrollos tradicionales la estratificacin de los distintos

miembros de los equipos es tan grande que en general la comunicacin entre
diseadores / programadores y clientes es mnima, XP rompe
esa aislacin
creando un entorno de desarrollo cooperativo y altamente comunicativo.
7.3.2. Valenta
En las metodologas tradicionales de desarrollo de sistemas en general nos
encontramos con programadores pasivos que deben aceptar sin poder emitir
opinin alguna lo que el lder del proyecto impone. La filosofa de trabajo de XP es
sustancialmente distinta, el programador puede modificar en forma responsable el
cdigo cuando lo considere necesario, el hecho de que se realicen pruebas
unitarias sobre cada cambio antes de ponerlo en el repositorio central hace que
se garantice la calidad de cada modificacin.
Esta valenta que debe tener el equipo de desarrollo debe estar acompaada por
la humildad y se debe decir en el seno del equipo de desarrollo con coraje todo lo
que se piensa sin miedos injustificados. Lo cierto es que no muchos equipos
estn acostumbrados a esta metodologa de trabajo, basada en el valor de
modificar lo que es perfectible y tener un rol activo en el proceso de desarrollo,
pero la sinceridad, la humildad y el coraje son elementos sustantivos para
garantizar el xito de un proyecto basado en XP.
7.3.3. Realimentacin (feedback)

Kent Beck en su libro sobre eXtreme Programming tiene un subttulo que dice
embrace change (abraza el cambio), que nos indica que se deben aceptar los
cambios y que los mismos deben estar incluidos en nuestro trabajo cotidiano
Mientras ms rpido se identifica el cambio, ms rpido se lo puede manejar. En
general, el principio es encontrar el error lo ms cerca posible al tiempo en que fue
introducido. XP se esfuerza para que se pueda recibir la retroalimentacin lo ms
rpido posible en todos los aspectos del proyecto.

23
La generacin de pruebas unitarias antes de actualizar el repositorio central y las

pruebas de aceptacin con el cliente, hacen que los cambios que se introducen
tengan niveles de calidad aceptables, cuanto antes se incorporan estos cambios,
cuanto antes se detectan los errores, mejor es para el proyecto.
Con estas premisas en el proyecto nos realimentamos cuidando una relacin
estrecha con el cliente sabiendo siempre si lo que estamos haciendo va bien
encaminado y cubre las necesidades de ste.
7.3.4. Simplicidad
Uno de los principios de la programacin extrema es la simplicidad. El cliente es el
eje que conduce todo el proceso de desarrollo en XP, hacer lo que el cliente
necesita, tan simple como sea posible es el objetivo, reduciendo la complejidad
desde el comienzo de cada proyecto.
Todo el cdigo debera ser refabricado tan frecuentemente como sea posible. La
refabricacin es el proceso de mejorar estructuras de cdigo sin cambiar la
funcionalidad que proveen.
El diseo debe ser lo ms simple posible. El paradigma KISS ("Keep It Small and
Simple" para unos o "Keep it Simple, Stupid" para otros) se lleva hasta las ltimas
consecuencias. Por ejemplo, se hace nfasis en no aadir funcionalidad nunca
antes de lo necesario, por las sencillas razones de que probablemente ahora
mismo no sea lo ms prioritario o porque quizs nunca llegue a ser necesaria.
7.4. Principios bsicos

Rpido feedback
Es fundamental que todo lo que se va aprendiendo a lo largo del desarrollo sea
socializado rpidamente. Los programadores aprenden que es lo mejor para el
proyecto, a utilizar nuevas herramientas, a crear pruebas para el sistema y este
aprendizaje debe ser compartido e incorporado en los equipos en forma inmediata.
Asumir la simplicidad
24
El 98% de los problemas se resuelve en forma sencilla, se trata de trabajar en el

da a da simplificndolos, es un vicio de muchos programadores complejizar
aquello que se puede resolver en forma sencilla
Cambio incremental
Los problemas se deben resolver con pequeos cambios, se trata de
particionarlos para simplificar y que el impacto de cada cambio sea lo menor
posible. El diseo, la codificacin, el equipo de trabajo se deben modificar en
forma incremental, incluso la propia implementacin del XP debe ser de a
pequeos pasos
Adoptar los cambios
La mejor estrategia es preservar la mayora de las opciones mientras se resuelve
los problemas ms urgentes
Trabajo de calidad
Se trata de hacer el trabajo lo mejor posible y con el mayor placer posible.
Cada uno de estos principios tiene embebidos los 4 valores mencionados
anteriormente.
A continuacin se detallan otros principios a considerar que si bien son
secundarios tienen mucha importancia:
Ensear aprendiendo
Jugar para ganar
Concretar los experimentos
Establecer una comunicacin honesta

25
Trabajar con el instinto de las personas no contra ellos, XP le da mucha

importancia a este punto.
Aceptar las responsabilidades
7.5. Las actividades bsicas en el desarrollo de sistema

Las actividades bsicas son:
Codificar:
Lo que se esta produciendo es software, si no hay cdigo, no se tiene nada.
Probar:
Debe existir una manera de saber en que punto termina la tarea, las pruebas
cumplen esa funcin.
Escuchar:
Los clientes deben estar presentes en el proceso porque son ellos los que
realmente van a obtener algo del software.
Disear:
El programa debe ser claro y comprensible para que se pueda trabajar con l.
7.6. Las 12 prcticas

26
XP propone 12 prcticas que deben ser tenidas en cuenta, no es recomendable

seguir slo algunas y otras no, se trata de aplicar en forma bastante estricta el
conjunto de prcticas propuestas:
Testing
Programacin por pares de Programadores
Diseo simple
Refactorizacin permanente
Cliente On-Site
Taller de planificacin
Integracin continua
Pequeos releases
Propiedad Colectiva del cdigo
Estndares de Codificacin
Metforas del sistema
Semana de 40 Horas
Existe una estrecha relacin entre estas doce prcticas y las mismas deben
implementarse en forma integral.
7.6.1. Testing
Las pruebas guan el proceso de desarrollo y son cruciales entre otras cosas para
garantizar la calidad y la retroalimentacin. Se deben realizar pruebas unitarias y
de aceptacin.
Formar una coleccin de pruebas unitarias desde el primer da, se convierte en
una herramienta bastante poderosa despus en el proyecto. No es posible
actualizar el repositorio central sin haber realizado estas pruebas.
Para esto se implementa una prctica muy interesante de codificacin que es la
llamada test-first. Antes de aadir un nuevo mdulo al sistema, se escribe una
prueba unitaria que ejecuta el cdigo an no existente.
Las pruebas de aceptacin se caracterizan por requerir que se pruebe el sistema
en forma total, el cliente est involucrado en la creacin de las pruebas de
aceptacin. Las pruebas unitarias se centran en que cada detalle tcnico est
funcionando de acuerdo a lo previsto y son diseadas bsicamente por el
programador, las pruebas de aceptacin aseguran que cada requerimiento del
27
cliente est funcionando correctamente y el mismo tiene un rol central en su

elaboracin.
Como la programacin es por pares de programadores, si uno de ellos no esta en
condiciones de disear una prueba es posible que el otro si pueda hacerlo, y en la
medida que el cliente disee las pruebas funcionales sentir que su participacin
es central y su rol se ve realzado.
7.6.2. Programacin por pares de Programadores

El software producido con XP es construido por dos programadores, sentados uno
al lado del otro en la misma mquina. Se espera que esta prctica garantice que
las pruebas unitarias las realice al menos un programador y se obtenga un mejor
diseo y cdigo.
En general se observa que los programadores solos tienden a producir gran
cantidad de errores.
Aunque parezca ineficiente tener dos programadores haciendo un mismo trabajo,
esto no es as, Laurie Williams de la universidad de Utah en Salt Lake City
demostr que
la programacin por parejas es un 15% ms lenta que la
programacin solitaria, pero que en cambio reduce los errores en el cdigo en un

15%, por lo tanto se obtiene en casi el mismo tiempo un software de mayor
calidad. La programacin por pares, al ser los mismos rotativos garantiza en
conocimiento general, los programadores aprenden en forma continua habilidades
que son aplicadas en cada proyecto.
Una buena prctica mientras se programa por parejas es que mientras uno de los
miembros de la pareja escribe el cdigo de test el otro va pensando sobre la
implementacin que se tiene que llevar a cabo para que el test pase.
Es posible que sea una de las prcticas ms resistidas ya que muchos lideres de
proyecto consideran que es una perdida de recursos que dos personas programen
en una sola maquina.

28
7.6.3. Diseo Simple

Se trata de buscar el camino ms sencillo para lograr el objetivo inmediato en el
desarrollo, o sea enfocar todos los esfuerzos para hacer sencillo el diseo de los
requisitos planteados en la actual interaccin y no pensar en un futuro que
probablemente cambie cuando se haga presente
Existe una clara relacin entre la retroalimentacin (una de la prcticas de XP) y el
mantener el diseo simple, ya que se eliminar tiempo de desarrollo innecesario.
Se trata entonces de no pensar en funcionalidades futuras ya que la flexibilidad de
la metodologa permitir incorporar y cambiar, as que no es necesario hacer ms
de lo que hoy se necesita.
7.6.4. Refactorizacin permanente

Esta prctica permite a los desarrolladores reestructurar el sistema sin cambiar la
funcionalidad del mismo, eliminando duplicidades, simplificando el cdigo,
flexibilizndolo
Normalmente se aplica cuando se solicita una nueva funcionalidad, ese es el
mejor momento para refabricar el cdigo y desarrollar la nueva funcionalidad. El
objetivo es que el cdigo no solo sea entendible por la maquina sino tambin por
las personas.
Para evitar errores en este proceso de refabricacin se debe garantizar que se
hagan suficientes pruebas unitarias.
La refactorizacin permite ahorrar tiempo y aumentar la calidad
Es claro que los factores que se estn enumerando tienen una profunda relacin
entre si, por ejemplo la refactorizacin, con la simplicidad, la propiedad colectiva,
la valenta (porque en general se refabrica lo que funciona, no lo que no funciona),
la programacin por pares y las pruebas.
7.6.5 Cliente On-Site

Es una condicin esencial que se incorpore al equipo de desarrollo un
representante del cliente en forma permanente, para responder preguntas,
29
interactuar con el equipo y participar en el diseo de las pruebas funcionales. Su

participacin activa garantiza que los cambios se incorporan en forma inmediata.
Este representante debe ser una persona con autoridad para decidir sobre la
marcha cuestiones relacionadas con la funcionalidad del producto.
7.6.6. Taller de planificacin

El objetivo de la planificacin es determinar rpidamente que contendr el prximo
release, combinando las necesidades del negocio con las posibilidades tcnicas.
El Release Planning es una prctica donde el cliente presenta las caractersticas
deseadas a los programadores a travs de un formulario denominado historias de
usuario,
los
programadores
estiman
su
dificultad
factibilidad
de
implementacin, se trata de una accin donde se integran las necesidades y

posibilidades a corto plazo (un nuevo release). Ya que se trata de pequeos
releases estas reuniones de planificacin se realizan como mximo cada tres
semanas, entonces los ajustes a la planificacin general se van detectando en
forma casi interactiva, XP modifica la planificacin tentativa original no se ajusta
como un dogma a ella. Con estas reuniones se logra:
La participacin del equipo completo en todas las decisiones

1. Decidir el alcance y prioridades
2. Estimar tiempos de desarrollo
Potenciar la retroalimentacin
7.6.7. Integracin continua

El sistema se construye e integra varias veces por da, cada vez que se concluye
una tarea. El juntar el cdigo de varios programadores puede ser muy complejo si
no se realiza cada vez que se finaliza una tarea, por lo tanto para garantizar la
flexibilidad del sistema se debe seguir la siguiente secuencia:
Disear pruebas
30
Codificar
Prueba Unitaria
Integrar
Probar el sistema integrado
En el caso que no se pasen correctamente las pruebas se debe tomar como

prioridad la correccin de los errores, corrigiendo los mismos hasta que todas las
pruebas se realicen sin que se produzcan errores. Es conveniente realizar esta
tarea varias veces al da preferentemente en una mquina dedicada para la
integracin.
7.6.8. Pequeos releases

Se trata de producir un sistema simple rpidamente, que el mismo este probado y
funcionaado y que tenga las funciones que el cliente elija en cada interaccin.
Despus se debe liberar nuevas versiones en ciclos de desarrollo rpido, desde
una por semana a una por mes.
Las entregas frecuentes salen de la idea del creador de Linux cita: "release early,
release often."
De lo que se trata es de garantizar que el sistema haga lo que el cliente quiere que
haga y se pueda mejorar interactivamente cada nueva versin, considerando que
no se incorporan gran cantidad de funcionalidades en cada interaccin, por lo
tanto el costo de cualquier desviacin es mnimo y los ajustes son menos
complejos.
7.6.9. Propiedad Colectiva del cdigo

El concepto de propiedad colectiva (collective code ownership), esto se relaciona
con la posibilidad que cualquier miembro del equipo de desarrollo puede modificar
cualquier parte del cdigo fuente, esto tiene un efecto muy interesante ya que al
saber cada programador que su cdigo pasa a ser de todos se esmera por
hacerlo lo mejor posible, mejorando la calidad, aumentando la cohesin y
31
reduciendo los errores. Esto rompe alguno de los vicios que tienen las
metodologas tradicionales donde cada programador es dueo exclusivo de su
cdigo y solo el puede modificarlo. Este sentimiento de team potencia la
productividad.
7.6.10. Estndares de Codificacin

Para lograr la propiedad colectiva del software y la refabricacin es necesario que
el equipo de desarrollo escriba el cdigo respetando estrictas reglas de
programacin estipuladas previamente. Cuando se utilizan estos estndares de
programacin el cdigo fuente es ms fcil de leer y es ms sencillo tener
valenta para modificarlo ya que muchas veces sucede en proyectos que utilizan
esta metodologa que a un programador al leer el cdigo le cuesta saber si lo
escribi el mismo.
7.6.11. Metforas del sistema

Se trata de una descripcin informal de la arquitectura del sistema, se describe al
sistema en conceptos simples, la idea es que en base a estas metforas se pueda
entender como trabaja el sistema. En otras metodologas se pueden encontrar
conceptos parecidos, como en el caso del RUP (Rational Unified Process) los Use
Cases.
7.6.12. Semana de 40 Horas

Una de las dificultades que aparecen en los equipos de desarrolladores en los
proyectos tradicionales es la sobreactividad, XP promueve la semana de 40 horas
de trabajo, considerando que un programador descansado produce mejor y con
menos errores

32
Este concepto intenta hacer entender que un programador que trabaja 14 horas
diarias no esta en condiciones de producir con calidad, muchas veces estas
actitudes heroicas solo perjudican los proyectos.
7.7. Contexto de eXtreme Programing

XP se limita a un contexto muy delimitado: entornos cambiantes, con requisitos
voltiles y con equipos de 12 personas o menos.
7.8. Estrategias de gerenciamiento

En los proyectos software
suelen darse dos tipos de estrategias de
gerenciamiento, por un lado el Lder de Proyecto todopoderoso que resuelve todos

los temas sin dar participacin a nadie, por el otro podemos encontrar equipos
donde cada integrante trabaja en forma aislada y autnoma sin ningn tipo de
direccin. XP plantea una alternativa intermedia que se caracteriza por:
Aceptar la responsabilidad, el lder de proyecto seala lo que se necesita hacer

no ordena.
Trabajo de calidad, la relacin entre los programadores y el lder del proyecto

se debe basar en la confianza, considerando que los programadores quieren
hacer bien su trabajo y el lder del proyecto tiene como funcin ayudar, orientar, no
ordenar.
Cambios incrementales, propone que el lder de proyecto brinde una gua a lo

largo del proyecto y no provea un gran plan cerrado que cubre todo el proyecto.
Adaptarse a la realidad local, se trata que todo proyecto se adapte a la

situacin concreta y la cultura organizacional del lugar donde se va a aplicar.
Tareas cortas, el lder de proyecto debe requerir de los programadores tareas

concretas y no muy pesadas, que puedan hacerse en poco tiempo.
Utilizar una mtrica adecuada, no intentar por ejemplo medir en minutos la

productividad de los programadores.
33
7.9. El espacio de trabajo

XP recomienda especialmente que el espacio de trabajo debe ser cmodo y
confortable, se trata de contar con un espacio comn para los desarrolladores y
que los mismos sean quienes acondicionan ese lugar. Un lugar de trabajo
agradable ayuda a que los desarrolladores estn a gusto y el trabajo se haga de
mejor forma.
7.10. Estrategias de planificacin en XP

Se trata de hacer un plan general en forma rpida e ir refinndolo en forma
permanente ajustndolo a la realidad, o sea que la realidad modele el plan y no el
plan a la realidad (motivo del fracaso de muchos proyectos). Las tareas tienen que
ser a corto plazo, de manera que si es necesario realizar cambios el impacto sea
menor sobre el conjunto del plan al realizarlo en base a pequeas tareas. Algunas
de las tareas relacionadas con la planificacin son:
Reunir al equipo
Decidir las prioridades y el alcance
Estimar el costo y la agenda
Dar confianza al equipo que la tarea es posible
Realizar la planificacin detallada considerando el horizonte prximo, el

prximo release, la prxima interaccin.
Aceptar la responsabilidad, la responsabilidad solo puede ser aceptada por el

equipo no puede se impuesta por el Lder del proyecto.
Una vez aceptada la responsabilidad, el encargado de realizar la tarea debe

estimar cuanto tiempo le llevar.
7.11. Estrategias de desarrollo.

Se trata de abordar los problemas en el da a ida, al trabajar con pequeos
releases el objetivo es ir resolviendo los problemas en la medida que aparecen,
esperando que se trate de pequeos problemas relacionados con el sistema
34
integral. La estrategia de desarrollo comienza con la planificacin de la interaccin,

la interaccin continua disminuye los conflictos en el desarrollo y posibilita
establecer el fin natural de una etapa. La propiedad colectiva del software ayuda a
disminuir los problemas en la etapa del desarrollo.
Los programadores deben usar la regla del 20-80 donde el 80% de los beneficios
provienen del 20% del trabajo.
El trabajo cooperativo y la definicin de tareas pequeas ayudan a disminuir los
problemas en la etapa de desarrollo.
7.12. Estrategias de diseo

Continuamente se debe refinar el diseo del sistema, empezando de manera
simple. La estrategia es tener el diseo ms simple posible que permita ejecutar
las pruebas que se planificaron.
7.13. Estrategias de testing.

Las pruebas se disean antes de codificar, o sea las pruebas guiaran el proceso
de diseo, por esta razn en XP juegan un rol central, las pruebas deben ser
diseadas desde el punto de vista del cliente entre los desarrolladores y el cliente.
Es imposible probar todo pero se debe considerar que el objetivo de la prueba es
determinar que debe hacer el sistema y como debe hacerlo.
7.14. Implementando XP
7.14.1. Integracin del equipo de trabajo y definicin de
necesidades:
El rol del cliente es central el mismo es parte del equipo de desarrollo como ya se
explico anteriormente y su importancia es capital tanto en la definicin de las

35
Historias de Usuarios, las reuniones de planificacin, el diseo de las pruebas

funcionales, etc.
En el punto 7.2. se hablo de las variables que existen en un proceso de desarrollo
de un sistema, El costo, Tiempo, La calidad, El alcance. De estas 4 variables el
alcance es la ms importante, por lo tanto la determinacin de los requisitos tiene
un papel fundamental.
En Xp los requisitos se definen en torno a lo llamado Historias de Usuarios y
tienen dos fases:
En la primera fase el cliente describe con sus propias palabras las

caractersticas que piensa debe tener el sistema y el responsable del
equipo de desarrollo le informa de la dificultad tcnica y el costo de cada
una de ellas. El cliente deja por escrito sus necesidades y las ordena de
acuerdo a sus prioridades
La segunda fase consiste en tomar las primeras historias (de acuerdo a su

nivel de prioridad) y determinar las tareas necesarias para implementar los
requisitos planteados en esa historia. El cliente participa de este proceso
pero el peso ms importante en esta etapa es del equipo de desarrollo, el
resultado ser una planificacin ms exacta.
Si bien las Historias de Usuarios tienen alguna similitud con los Uses Cases de
UML el proceso de creacin es muy distinto. Es ms extensa que un requisito (que
suele ser una frase corta) y menos que un caso de uso (que puede ser de una o
dos pginas).
Los desarrolladores son los responsables de catalogar las historias de los usuarios
y asignarles una duracin, el tiempo de programacin de cada una de estas
historias no debe ser mayor a tres semanas y menor a una, en el caso que ocupen
menos de una semana se las agrupa y si ocupan ms de tres se las divide.
Cuando se habla de una semana de trabajo se considera 5 das a 8 horas cada
da. Al hacer la planificacin se aplica un factor de correccin medido de proyectos
anteriores para ajustar este tiempo ideal al real.
Las historias de los usuarios se plasmarn en tarjetas especialmente diseadas
para ese fin.
36
7.14.2. Planificacin
La planificacin debe definir cada una de las iteraciones, teniendo en cuenta que
se deben generar entregas frecuentemente.
El objetivo es que las necesidades del cliente guen el desarrollo y no la
planificacin, por lo tanto se debe prever que cada 3 a 5 iteraciones se tengan que
revisar las historias de los usuarios y renegociar nuevamente la planificacin.
Se debe tambin definir la planificacin de cada iteracin, en esta planificacin se
especifica que historias de usuarios son prioritarias y se agrega las historias de
usuarios que no han pasado las pruebas de la iteracin anterior.
Es por eso, que el diseo que seguimos se puede calificar de continuo. Se trata en
general de optimizar al final del desarrollo, se trata de "make it work, make it right
and then make it fast" (haz que funcione, hazlo bien y entonces haz que sea
rpido).
7.14.3. Diseo.
Se habla de diseo continuo, el mismo debe ser revisado y mejorado
permanentemente a medida que se agregan funcionalidades, esto se contrapone
con las metodologias tradicionales que hablan de un gran diseo previo.
La metfora tiene un papel central en esta etapa, mejorando la relacin en el
equipo de trabajo y dando una visin general del sistema que se quiere
desarrollar.
Puede suceder que el cliente participe en esta etapa. Muchas veces se utiliza un
tipo de tarjetas denominadas CRC (Class, Responsabilities and Collaboration Clases, Responsabilidades y Colaboracin). Para cada clase identificada se
rellenar una tarjeta de este tipo y se especificar su finalidad as como otras
clases con las que interaccione. Para algunos autores el uso de estas tarjetas solo
debe limitarse a los proyectos complejos.
7.14.4. Diseo de pruebas y codificacin

37
Las pruebas unitarias se desarrollan antes de codificar. Hay mucha literatura sobre
las pruebas unitarias pero en general se coincide en que cuanto ms difcil sea
implementar una prueba, ms necesaria es.
Las pruebas unitarias se diferencias de las de aceptacin,
las primeras las
disean los programadores y las de aceptacin son realizadas por el cliente, se

trata de pruebas de caja negra y se utilizan las historias de usuarios para hacerlas.
Los programadores se ponen por parejas (dos personas en el mismo ordenador)
para codificar esas historias. Primero entonces se disea la prueba y despus se
codifica hasta que se pasen con xito todas las pruebas.
7.14.5. Integracin
Despus de codificar cada nueva funcionalidad se debe integrar, esta integracin
como ya fue mencionado es continua, evitando una gran integracin final.
En todo desarrollo de programacin extrema debera existir, por tanto, una versin
siempre integrada. Existe un repositorio central que debe sincronizar cada modulo
al menos una vez por da.
7.14.6. Refactorizacin
Refactorizar consiste en mejorar el cdigo. El cdigo no solo debe funcionar sino
debe ser simple. El proceso de refactorizacin incluye las pruebas unitarias.
Dado que se trata de desarrollos que se basan en los cambios, todo el proceso en
de tipo incremental.
8. XP y Open Source
Existen algunas caractersticas comunes entre las Metodologas giles y el Open
Source Software que sern analizadas en este capitulo, sin lugar a dudas ambos
han recorrido un camino en el desarrollo de sistemas con muchos puntos en
comn.
38
En 1985 nace la Free Software Fundation, este momento es considerado como el

nacimiento formal del Open Source Software (OOS), la base filosfica que
sustenta este movimiento tiene que ver con la socializacin del conocimiento, con
usuarios activos, en contra de la filosofa del gigante de Microsoft que cierra el
conocimiento al ocultar el cdigo fuente de sus productos y entiende al usuario
como un objeto pasivo.
El concepto de desarrollo de Linus Torvalds es claro para entender el OOS Libere
rpido y a menudo, delegue todo lo que pueda, sea abierto hasta el punto de la
promiscuidad.
Eric S. Raymond, un terico del software libre, escribi en 1997 que el modelo de
desarrollo del software libre es similar a la construccin de los bazares , en contra
de las
metodologa tradicional que las compara con la construccin de las
catedrales con un arquitecto que disea y distribuye tareas y albailes que

construan las catedrales respetando exactamente los planes y con tcnicas
secretas (recordemos que el sindicato de albailes de catedrales es el que da
origen a la secta secreta de los Masones). En cambio en la construccin de los
bazares, los planes no tienen un orden tan estricto, se construye colectivamente y
todos ven sus secretos
La mayora de los proyectos de cdigo abierto tienen uno o ms mantenedores.
Un mantenedor es la nica persona a la que se le permite integrar un cambio en el
almacn de cdigo fuente. Sin embargo otras personas pueden hacer cambios a
la base del cdigo. La metodologa de trabajo es que el usuario desarrollador
enva al mantenedor los cambios propuestos y este decide si es incluido o no ese
cambio, la clave que impulsa este tipo de desarrollo es la meritocracia. El
mantenedor es el responsable de mantener la integridad del producto
Otro rasgo distintivo es que muchas personas participan simultneamente del
proceso de testing y cuando se encuentra un defecto estos usuarios activos
pueden enviar la correccin del bug al mantenedor para que lo incluya en la
prxima versin.
En el articulo La catedral y el Bazar Eric S. Raymon plantea algunos principios y
caractersticas comunes que tienen los proyectos de OSS, estos principios tienen
39
sin lugar a dudas muchos puntos en comn con los de las Metodologas giles,
algunos de los principios planteados por Raymon son:
Todo buen trabajo de software empieza a partir de las necesidades

personales del programador
Los buenos programadores saben que escribir. Los mejores que reescribir.
Si tienes la actitud adecuada tendrs problemas interesantes.
Cuando se pierde el inters de un programa se lo debe heredar a un sucesor

competente.
Tratar a los usuarios como colaboradores es la forma ms apropiada de

mejorar el cdigo y la ms efectiva de depurarlo.
Libere rpido y a menudo y escuche a sus clientes.
Dada una base suficiente de desarrolladores asistentes y beta-tester casi

cualquier problema puede se r caracterizado rpidamente y su solucin ser
obvia para alguien.
Si usted trata a sus beta tester como si fueran un recurso muy valioso, ellos le
respondern como recursos muy valiosos.
Las estructuras de datos inteligentes y el cdigo burdo funcionan mucho mejor

que en el caso inverso.
Lo ms grande despus de tener buenas ideas es reconocer las buenas ideas

de sus usuarios.
La perfeccin en diseo se logra cuando ya no hay nada que quitar.
Etc.
De estos principios se desprenden algunas caractersticas modulares que tiene

que ver con el rol del Cliente , con el uso colectivo del cdigo fuente, con el rol
central del programados, con la metodologa incremental, con el testeo, con la
necesidad de hacer simple el cdigo.
El siguiente cuadro muestra una comparacin entre OSS y Metodologa giles:
Item
Desarrolladores
OSS
Metodologas giles
Colaborativos,
capacitados, Colaborativos capaces giles.
giles.
En un mismo lugar fsico
40
Clientes
Requerimientos
Arquitectura
Tamao
Objetivo principal
Distribuidos geogrficamente
Dedicados,
capaces Autorizados,
especializados,
colaborativos
integrantes del equipo de
desarrollo.
Voltiles
Cambian rpidamente
Diseada
para
los Diseada
para
los
requerimientos actuales.
requerimientos actuales
Equipos grandes y dispersos. Equipos y sistemas pequeos.
Sistema pequeos
Problemas desafiantes
Rapidez.
Una de las diferencias fundamentales aparecen en relacin con el rol y la

ubicacin del cliente, mientras el Open Source Software se trata de clientes
desarrolladores distribuidos geogrficamente, en las Metodologas giles el cliente
forma parte in situ del equipo de desarrollo.
En forma ms estructurada considerando cuatro elementos, la metodologa de
desarrollo, el trabajo cooperativo, el software sencillo y la adaptabilidad, se pueden
analizar las siguientes coincidencias:
O.S.S.
Metodologas giles
Metodologa Distribucin frecuente de Se desarrollan pequeos releases
Incremental
releases, con aporte de los
desarrolladores y testeados
por la comunidad, segn
Linus Torvald Release early,
release often
Cooperativo Existe un propietario
proyecto,
pero
desarrolladores
se
del Una de las caractersticas del equipo
captan de desarrollo tiene que ver con el
utilizando conocimiento colectivo del cdigo, la
Internet y se integran a los programacin
por
pares
de
proyectos a partir de sus programadores, las reuniones diarias

meritos como programadores, de planificacin, el cliente como parte
que se integran a partir de un activa del equipo de desarrollo.
complejo
proceso
de

41
Sencillo
Ingeniera Social.
Se trata de utilizar procesos Se trata de garantizar un proceso
de
construccin
ortodoxos,
con
poco sencillos de construccin segmentado

poca los problemas lo mximo posible,
documentacin conocidos por donde el eje de la documentacin es

la comunidad donde la base el cdigo fuente
Adaptativo
es la calidad
Los requerimientos se van Una de las razones del nacimiento de
elaborando
constantemente las
Metodologas
giles
es
la
por la comunidad, partiendo adaptabilidad, los pequeos releases

de algunas ideas bsicas se aportan en este sentido.
construye el producto
Como conclusin puede afirmarse que si bien ambas filosofas tienen orgenes
distintos y una base filosfica distinta, donde en el Open Source Software la
distribucin del cdigo fuente es modular y para las Metodologas giles lo central
es el desarrollo rpido de sistemas y que sean fcilmente adaptables, en ambas
prcticas se observan muchos puntos en comn como claramente que da
expresado en la tabla anterior, y la interrelacin entre ambas prcticas puede ser
muy beneficiosa y no es imposible imaginar la aparicin de hbridos entre el OSS y
las metodologas giles.
9. Conclusiones
Existe un antecedente claro de las metodologas giles que es el mtodo
Incremental e Interactivo, el origen de estas metodologas datan de 1930 y se
observan muchos proyectos desarrollados a partir de la dcada del 60.
Considerando que el Manifiesto de las Metodologas giles surge en el ao 2001,
estamos considerando metodologas que cuentan con antecedentes pero que se
42
constituyen y reconocen con principios comunes no hace mucho tiempo, en esta

corta historia se detectan las siguientes discusiones:
En el ao 2001 se discuta que son en realidad las Metodologas giles.
En el ao 2002 La discusin paso por determinar si no existe contradiccin
entre CMM (Capability Maturity Model) desarrollado por el SEI, las normas
ISO 9000 y las metodologas giles, determinndose que no exista mucho
inters en relacionarse.
En el ao 2003 La discusin pasa por determinar si es posible combinar las
prcticas giles con los mtodos tradicionales y tomar algunos de los
elementos de cada uno.
La aplicacin de las metodologas giles implica un cambio importante en las
organizaciones, afecta la estructura de poder donde el programador y el cliente
adquieren un rol central desplazando el de los gerentes y Analistas.
Estas metodologas obligan a tener un mayor nivel de interaccin entre los
programadores y Lideres de Proyecto, por otro lado el tema que los testetadores y
programadores trabajen juntos tambin implica un cambio en los hbitos de
trabajo.
El siguiente cuadro muestra un resumen, diferenciando por reas, las
caractersticas que debe tener un proyecto basado en la filosofa de Metodologas
Agiles:
rea
Metodologas giles
Desarrolladores
giles, capacitados, colaborativos y situados en

el mismo lugar.

43
Clientes
Especializados, representativos ,
situados en el mismo lugar
y autorizados.
Requerimientos
Generalmente en vas de desarrollo cambian

rpidamente.
Arquitectura
Diseada para los requerimientos actuales.
Tamao
Equipos y productos pequeos.
Objetivo Principal
Rapidez.
Las Metodologas Agiles proveen un conjunto de prcticas muy interesantes, que

fueron mencionadas en el presente trabajo, por cierto existen muchos seguidores
y muchos detractores, se trata que el lector evale las ventajas y desventajas y
realice su propia experiencia, tanto en desarrollos a medida tradicionales, como
en los basados en la filosofa del Open Source Software.
El uso de un mtodo gil no es para todos ni para todos los proyectos, solo se
limitan a los entornos cambiantes y equipos pequeos.
La realidad es
que gran parte de los desarrollos pequeos hoy en da utilizan
la metodologia de codificar y corregir, las metodologas giles aportan un

conjunto de principios y pasos livianos a seguir que sin duda ayudaran a los
desarrollos que trabajan sin metodologa y que producen hoy, software de baja
calidad y que en muchos casos nunca se implementa. Tambin es una ayuda a
los equipos que aplican metodologas tradicionales en desarrollos pequeos o
medianos para hacer el eje del desarrollo en la realidad y en el cliente, y no en la
aplicacin rgida de metodologas que son muy pesadas de seguir.
Los cambios relacionados con la Tecnologa de la Informacin obligan a los
profesionales del rea a estar abiertos a cualquier cambio que implique mejorar la
calidad del software y permitir que los clientes queden satisfechos, las
Metodologas Agiles sin duda se orientan en este sentido.
44

45
10.Bibliografa
Extreme programming explained. Kent Beck. Editorial Addison Wesley

1999
Questioning Extreme Programming. Pete McBreen. Editorial Addison

Wesley 2002
Extreme Programming Perspectivas. Michele Marchesi, Giancarlo Succi,

Don Wells, Laurie Williams. Editorial Addison Wesley. 2002
Java Extreme Programming Cookbook Eric M. Burke, Brian M. Coyner

Editorial O'Reilly. 2003
Testing Extreme Programming.
Lisa Crispin, Tip House. Editorial
Addison Wesley 2002
Agile Software Development Ecosystems. J.Highsmith . Editorial

Addison Wesley. 2002
Agile Software Development with SCRUM. K. Schwaber and M.Beedle,

Prentice Hall. 2002
Extreme programming from CMM perspective. M. Paulk. IEEE Software

Nov/Dic 2001 pp 19-26
Agile Software Development: Its abaut feedback and change. Laurie

Williams. Alistair Cockburn. Computer junio 2003. pp 39-43
Agile Through discipline: a debate. Kent Beck. Barry Boehm. Computer

junio 2003 pp 44-46
Interactive and Incremental development: a brief history. Craig Larman.

Victor Basili. Computer junio 2003. pp47-55
Agile software development: the people factor. A. Cockburn . Computer

nov.2001 pp 131-133
Extreme Programming Explore. Williams Wake. Editorial Addison Wesley.

2000.

46
Java Tools for Extreme Programming. Richard Hightower Nicholas

Lesiecki. Editorial Wiley. 2002
La Catedral y el Bazar. Eric Raymond. 1997
Cultivando la Noosfera. Eric Raymon. 1998
SCRUM: http://controlcaos.com
Feature Driven Development: http://www.featuredrivendevelopment.com/
Crystal Methodologies: http://members.aol.com/acockburn
Adaptative Software Development : http://www.adaptivesd.com
Agile Modeling: http://www.agilemodeling.com

47

Metodologias Agiles Enseñanza

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Metodologias Agiles Enseñanza

Enviado por

Direitos autorais:

Formatos disponíveis

Metodologas giles, Programacin Extrema

Metodologas Agiles, programacin extrema

La sociedad del conocimiento, la globalizacin de la economa, el avance de la

En particular en los sistemas pequeos, se verifica que muchos de los desarrollos

En la mayora de las ingenieras los procesos constructivos son definidos y

4.1. Caractersticas bsicas

Los mtodos ingenieriles tradicionales ponen el acento en la planificacin,

Los mtodos tradicionales estn orientados a los procesos y los giles a la

Los mtodos giles son adaptables en lugar de predictivos

Se detectan antecedentes de este tipo de metodologas en forma paralela en

4.3. Caractersticas principales

4.4. Diferencias con las metodologas tradicionales

Separacin de Diseo y Construccin / Diseo y construccin integrados

Requisitos estables / Impredecibilidad de los Requisitos

Grandes cambios en cada versin / Iteraciones

Refinamiento sucesivo, desarrollo incremetal, interactivo, espiral, prototipo, etc.,

Clientes pasivos / Clientes activos

Lderes de proyecto con rol central / Equipos de desarrollo con rol

Metodologas Agiles, programacin extrema

La base es la planificacin / La base son las pruebas

Metrica rgida / mtrica flexible

Metodologas Agiles, programacin extrema

Grupos pequeos (< 12 integrantes) y

Grupos grandes de trabajo.

El cliente es parte del equipo de desarrollo

El cliente interacta con el equipo

Pequeos cambios en cada versin

Grandes cambios en cada versin

Rol central del equipo de desarrollo

Rol central del lder de proyecto y

Desarrollo basado en pruebas

No existe un contrato tradicional o al

Separacin diseo y construccin

Metodologas Agiles, programacin extrema

La Familia de Crystal de Cockburn

encuentran difcil seguir un proceso disciplinado, as que ms que seguir la alta

Redistribucin libre: La licencia no deber impedir la venta o el ofrecimiento

con un componente de una distribucin agregado,

conteniendo programas de muchas distintas fuentes.

Cdigo fuente: El programa debe incluir el cdigo fuente y se debe distribuir

Trabajos derivados: La licencia debe permitir modificaciones y trabajos

No a la discriminacin de personas o grupos: no se puede discriminar a

No a la discriminacin de campos laborales: no se tiene que restringir a

Distribucin de la licencia: Los derechos adjuntos al programa tienen que

La licencia no tiene que ser especfica de un producto: Los derechos

Metodologas Agiles, programacin extrema

La licencia no tiene que restringir a otro software: La licencia no tiene que

Se desarrollar ms adelante en detalle las diferencias y similitudes entre XP y

El Desarrollo de Software Adaptable de Highsmith

Highsmith ve la planificacin como una paradoja en un ambiente adaptable, ya

En un ambiente adaptable, aprender desafa a todos (desarrolladores y clientes) a

Desarrollo Manejado por Rasgos

Desarrollar un Modelo Global

Construir una Lista de los Rasgos

Planear por Rasgo

Disear por Rasgo

Construir por Rasgo

DSDM (Mtodo de Desarrollo de Sistema Dinmico)

el ciclo del modelo funcional produce documentacin de anlisis y

el ciclo de diseo del modelo disea el sistema para uso operacional

el ciclo de implantacin se ocupa del despliegue al uso operacional

Metodologas Agiles, programacin extrema

6. Manifiesto para el Desarrollo de Software gil