Daniel Castillo Gabriel Gonzlez Carlos Gamboa Cristian Mosquera Javier Snchez Mauricio Rincn Juan Carlos Suarez

EXTRREME PROGRAMING

INTRODUCCION
La programacin extrema o eXtreme Programming (XP) es una metodologa de desarrollo de la ingeniera de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad.

VALORES FUNDAMENTALES DEL LA PROGRAMACIN EXTREMA

Simplicidad Comunicacin Retroalimentacin Coraje Respeto

SIMPLICIDAD
La simplicidad es la base de la programacin extrema. Se simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento. Un diseo complejo del cdigo junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de mantener el cdigo simple a medida que crece.

COMUNICACIN
La comunicacin se realiza de diferentes formas. Para los programadores el cdigo comunica mejor cuanto ms simple sea. Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms fiable que los comentarios ya que stos ltimos pronto quedan desfasados con el cdigo a medida que es modificado. Debe comentarse slo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un mtodo

RETROALIMENTACIN
Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es ms importante.

CORAJE
Muchas de las prcticas implican valenta. Una de ellas es siempre disear y programar para hoy y no para maana. Esto es un esfuerzo para evitar empantanarse en el diseo y requerir demasiado tiempo y trabajo para implementar el resto del proyecto. La valenta le permite a los desarrolladores que se sientan cmodos con reconstruir su cdigo cuando sea necesario

RESPETO
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compaeros. Los miembros respetan su trabajo porque siempre estn luchando por la alta calidad en el producto y buscando el diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin del cdigo

CARACTERSTICAS FUNDAMENTALES
Desarrollo iterativo e incremental Pruebas unitarias continuas Programacin en parejas Frecuente interaccin con el cliente Refactorizacin del cdigo Propiedad del cdigo compartida Simplicidad en el cdigo

KEN BECK
Es ingeniero de software estadounidense, uno de los creadores de las metodologas de desarrollo de software de programacin extrema
Fue pionero en patrones de diseo de software, el redescubrimiento del testdriven development, as como tambin del la aplicacin comercial de Smalltalk. Con Ward Cunningham populariz la metodologa de tarjetas CRC, y con Erich Gamma el framework de pruebas unitarias para Java conocido como JUnit. "Todo en el software cambia, los requisitos cambian, el diseo cambia, el negocio cambia, la tecnologa cambia, el equipo cambia, los miembros del equipo cambian, el problema no es el cambio en si mismo, puesto que sabemos que el cambio va a suceder, el problema es la incapacidad de adaptarse a dicho cambio cuando este tiene lugar"

CICLO DE DESARROLLO XP
Se inicia el ciclo nuevamente. El cliente define los requerimientos a desarrollar.

El programador construye lo seleccionado por el cliente.

El programador define el tiempo estimado para cada implementacin.

El cliente selecciona que construir, de acuerdo con sus prioridades y las restricciones de tiempo.

CICLO DE DESARROLLO XP

HISTORIAS DE USUARIO
Reemplazan el documento de requerimientos. Aspectos Importantes:
Tarjetas. Conversacin. Confirmacin.

HISTORIAS DE USUARIO
HISTORIA DE USUARIO Numero: Usuario: Identificacin de la Historia Nombre: Nombre de la Historia

Cliente que ha creado la Historia Numero de Modificacin Iteracin Asignada: Riesgo en desarrollo:
(Alta / Media / Baja)

Modificacin de Historia Nmero: Prioridad en Negocio:

(Alta / Media / Baja)

Numero de Iteracin Riesgo asociado

Prioridad asignada por el cliente

Descripcin: Observaciones:

Texto explicativo de la historia de usuario

Formato: Como [rol] quiero [funcionalidad] para [beneficio] Como [cliente habitual], quiero [ver productos relacionados con mis compras anteriores] para [ver si hay otros productos que me puedan interesar].

HISTORIAS DE USUARIO
Numero: 02 Usuario: Administrador Modificacion de Historia Numero: NA HISTORIA DE USUARIO Nombre: Registro de Facultades

Prioridad en Negocio: Media (Alta / Media / Baja)

Iteracion Asignada: Primera Riesgo en desarrollo: Bajo (Alto /

Medio / Bajo)

Descripcion: Se realiza el registro de la informacion acerca de las facultades (Nombre). Observaciones: Las facultades registradas son aquellas que participan en el proceso electoral segun sea el caso. Historia de Usuario
Nmero: 14 Usuario: Todos Nombre historia: Control de acceso de usuarios Prioridad en negocio: Baja Puntos estimados: 1 Programador responsable: David Ferrer

Riesgo en desarrollo: Baja Iteracin asignada: 3

Descripcin: Antes de iniciar la aplicacin se solicita el nombre de usuario y su clave para que tenga acceso a los datos que corresponden a su categora de usuario. Hay dos tipos de usuario: secretaria y almacenista, con distintos permisos de acceso a los mens de acceso a las funcionalidades que les corresponden. Observaciones:

HISTORIA DE USUARIO
Un usuario puede enviar un curriculum a la pagina web. El programa ser escrito en c++. El programa se conectara a una base de datos a travs de un pool de conexiones.
Las historia de usuario, presentan la funcionalidad, que es lo que aprecia el usuario.

Donde quedan los detalles?

LOS DETALLES
Los usuarios pueden buscar un trabajo.
- Por cuales campos el usuario puede buscar (departamento, titulo trabajo, palabras). - Debe estar registrado antes de consultar. - Que informacin debe ser mostrada.

Los detalles pueden ir en otras historias de usuario

Es mejor tener mas historias de usuario que una historia muy extensa.

LOS DETALLES
Los detalles pueden ir en otras historias de usuario Es mejor tener mas historias de usuario que una historia muy extensa.

Los detalles se discuten entre el equipo de desarrollo y los clientes

Los detalles se convierten en pruebas de aceptacion

EJEMPLO
El usuario puede pagar sus tems que se encuentran en su carrito de compras con una tarjeta de crdito.
Probar con tarjeta debito. Probar con diferentes valores que hayan superado el limite de la tarjeta.

POR QUE HISTORIAS DE USUARIO

Inicio levantamiento de Requerimiento Cliente Fin Entrega Producto Cliente Inicio levantamiento de Requerimiento Cliente

Las historias deben ser escritas en el lenguaje de negocio no en forma tcnica

Son los que conocen en primera medida lo que se necesita

Se pueden escribir en cualquier momento dentro del proceso

CARACTERSTICAS
Independientes Negociables

Funcionalidad

Estimable

Dividir o Combinar

EJEMPLO
Una empresa puede pagar x una publicacin de oferta de trabajo con tarjeta de crdito, aceptamos visa, Master Card y American Express, por montos superiores a $ 100, debe pedir el numero de identificacin del respaldo de la tarjeta, el sistema puede identificar que tipo de tarjeta a partir de los 2 primeros dgitos del numero de la tarjeta, el sistema puede almacenar un numero de tarjeta para un uso futuro, almacenar el mes de vencimiento y fecha de la tarjeta.

SOLUCIN
Una empresa puede pagar x una publicacin de oferta de trabajo con tarjeta de crdito.
Probar con Visa, Master Card y American Express. Probar con Dinners Club. Probar con datos correctos y errneos. Probar con tarjetas que ya hayan expirado. Probar con montos de 100 o superior.

HISTORIAS DE USUARIO
Valoracin de Historias de Usuario

PLAN DE ENTREGAS
Es de suponer que todos los documentos presentados de forma previa sean completados durante la llamada Reunin de planificacin de entregas, al final de esta reunin debe quedar un documento denominado Plan de Entregas, el cul detalla cuntas y cules historias de usuario se desarrollaran en cada entrega y en que fechas se entregarn.

PLAN DE ENTREGAS
Actividades de Reunin de Planificacin de Entregas El plan de entregas es un documento que especifica exactamente que historias de usuario sern implementadas en cada entrega del sistema y sus prioridades, de modo que tambin permita conocer con exactitud qu historias de usuario sern implementadas en la prxima liberacin. Debe ser negociado y elaborado en forma conjunta entre el cliente y el equipo desarrollador durante las reuniones de planificacin de entregas, la idea es hacer entregas frecuentes para obtener una mayor retroalimentacin. A continuacin se describen las principales actividades que se deben llevar a cabo, y los documentos que deben ser completados tanto por el cliente como por el equipo desarrollador como una pieza fundamental de la reunin de planificacin de entregas, para finalmente documentar el plan respectivo:

PLAN DE ENTREGAS
Actividades Implementacin de Historias de Usuario Descripcin Completar este documento para obtener los requerimientos para el desarrollo del sistema. Segn las historias de usuario se debe llevar a cabo una estimacin de cada una de ellas completando el documento especfico. Una vez estimadas las historias stas deben ser debidamente priorizadas, lo cul quedar en este documento. De este documento se obtiene informacin respecto a lo que es la velocidad del proyecto para cada liberacin. A travs de este documento se especifica las historias de usuario que sern implementadas en la liberacin. En este documento se debe realizar un resumen de los documentos anteriores, respecto de las historias de usuario a implementar con sus respectivas prioridades. Responsable Cliente

Estimacin de Historias de Usuario

Equipo desarrollador

Priorizacin de Historias de Usuario

Cliente y equipo desarrollador.

Fijar velocidad del proyecto.

Equipo desarrollador.

Planificacin por alcance o tiempo.

Cliente y equipo desarrollador.

Documentar el plan de entregas.

Documentador.

PLAN DE ENTREGAS
Plan de Entregas [[Nombre del proyecto]] Fecha de Reunin de Planificacin:

Nombre de Documentador: Entrega N: Historias de Usuario a Implementar en la Entrega Nmero de Historia Ttulo Prioridad Fecha en la que entregar Liberacin en la que se incluir <Colocar el N de la(s) Entrega(s) para la cul(es) se implementarn las historias >

Informacin de aprobacin del Plan

Firma del Entrenador (Coach)

Firma del cliente

La programacin extrema parte del caso habitual de una compaa que desarrolla software, normalmente a medida. En donde el cliente pasa a ser parte importante en el equipo de desarrollo.

ITERACIONES PLANIFICACIN SEGUIMIENTO

Entregas

REGLAS

Iteracin

ITERACIONES PLANIFICACIN SEGUIMIENTO

OBJETIVOS FLEXIBLES

SEGUIMIENTO DE ITERACIN
Comunicacin Reuniones breves Reportes de seguimiento tareas activas Diagrama BurnDown Diagrama de velocidad del proyecto

REPORTE DE SEGUIMIENTO DE TAREAS ACTIVAS

DIAGRAMA DE BURNDOWN

DIAGRAMA DE BURNDOWN

DIAGRAMA DE VELOCIDAD

El cliente tiene un papel importante de interaccin con el equipo de desarrollo, sobre todo despus de cada cambio, y de cada posible problema localizado. De esta forma se posibilita que el cliente pueda ir cambiando de opinin sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo. En este tipo de programacin existirn pruebas de aceptacin de la programacin que ayudarn a que su labor sea lo ms provechosa posible.

Planificacin del proyecto Se tendr que elaborar la planificacin por etapas, donde se aplicarn diferentes Ciclo de desarrollo Iteraciones.
El cliente define el valor de negocio a implementar. El programador estima el esfuerzo necesario para su implementacin. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. El programador construye ese valor de negocio. Pruebas de aceptaci n

Velocidad de Proyecto (VP) puntos/semana Historias de Usuario Primera Iteracin

Segunda Iteracin

N-sima Iteracin

ltima Iteracin

Historias fuera de la entrega

2 a 3 semanas

 Las entregas se tienen que hacer cuanto antes mejor, y con cada iteracin, el cliente ha de recibir una nueva versin. Cuanto ms tiempo se tarde en introducir una parte esencial, menos tiempo se tendr para trabajar con ella despus. Se aconseja muchas entregas y muy frecuentes. Cada tres o cinco iteraciones es normal revisar las historias de los usuarios, y renegociar la planificacin.

Cada iteracin necesita tambin ser planificada, es lo que se llama planificacin iterativa, en la que se anotarn las historias de usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptacin. Estas planificaciones tambin se harn en tarjetas, en las que se escribirn los trabajos que durarn entre uno y tres das.
Cada vez que se quiere implementar una parte de cdigo, en XP, se tiene que escribir una prueba sencilla, y despus escribir el cdigo para que la pase.

TARJETAS CRC (CLASE, RESPONSABILIDAD Y COLABORACIN)

QUE ES? E S U N A M E T O D O L O G A P A R A E L D I S E O D E SOFTWARE ORIENTADO POR OBJETOS CREADA POR KENT BECK Y WARD CUNNINGHAM. E S U N A T C N I C A P A R A L A R E P R E S E N T A C I N SISTEMAS OO, PARA PENSAR EN OBJETOS. DE

ORIENTACIN A OBJETOS?
No se centra en "qu procesamiento lleva a cabo el sistema?", sino en
qu entidades estn involucradas funcionamiento del sistema? en el

En este contexto, entender la aplicacin que se va a desarrollar supone:

Identificar y definir los objetos Asignarles lo que pueden hacer y lo que conocen Describir la manera en que se relacionan unos con otros

EL PROBLEMA
Repartir Lo que va a hacer el sistema en unidades de diseo/implementacin (Clases)
Lo que aporta cada clase al comportamiento del diseo se define en trminos de responsabilidades Unas clases pueden recurrir a otras para llevar a cabo sus responsabilidades. Este tipo de comunicaciones entre clases se denomina colaboraciones

COMO EMPEZAR: BRAINSTORMING

Para que esto funcione hay que tener siempre presente: Todas las ideas pueden ser buenas (En esta etapa) concentrarse en aadir nombres de posibles clases a la lista, dejar para otro momento si son validos o no (Si es un nombre, es candidato valido) Escuchar a todo el mundo por turno Tener sentido del humor (Es casi mas importante participar en el dialogo que proponer ideas buenas; un proceso posterior se encargara de tener en cuenta las ideas buenas)

EJEMPLO DE LISTA DE CLASES

CajeroAutomtico TransaccinMonetaria TarjetaBancaria ClienteBancario PIN Cuenta CuentaCorriente CuentaAhorro Transferencia RetirarEfectivo Deposito ConsultaSaldo Recibo ImpresoraRecibo Teclado

DispensadorBilletes MensajeEnPantalla EfectivoDisponible ErrorSobreDeposito Saldo TeclaTimeOut BitacoraTransacciones Cantidad TitularCuenta Impresora SalvaPantallas TeclaNumerica Tecla Pantalla Cliente

SELECCIONAR CLASES BSICAS

Localizar las que se quedan seguro
Localizar las que se quitan seguro

Para las dudosas, discutir cada una y votar a mano alzada

Reducir la lista de clases bsicas lo ms posible pero conservar a mano la lista de clases dudosas y eliminadas por si en el paso siguiente se ve que falta alguna clase

QUE DEBE CUMPLIR UNA CLASE BSICA

Tiene un nombre inequvoco fcilmente reconocible por los expertos
Tiene un nombre que encaja con otros sistemas/mdulos desarrollados por el equipo Es un nombre en singular, no en plural Empieza con mayscula Tiene responsabilidades La necesitan otras clases Participa activamente en el sistema

CASOS A IDENTIFICAR
Fantasmas Clases relacionadas con lo que se hace pero que en realidad corresponden a piezas de sistemas externos con los que el sistema tiene que relacionarse. Ej. CajeroAutomatico, Impresora
Sinnimos Clases iguales a otras que ya estn presentes, pero con otro nombre Ej. Cliente, TitularCuenta

EJEMPLO DE LISTA FILTRADA DE CLASES

Clases Bsicas TransaccinMonet aria Cuenta ConsultaSaldo RetiradaEfectivo Deposito TarjetaBancaria Transferencia
Clases dudosas CajeroAutomtico (nombre del sistema) PIN (atributo) CuentaCorriente(atr ibuto de Cuenta) CuentaAhorro(atrib uto de Cuenta) EfectivoDisponible (atributo) Saldo (atributo) TitularCuenta
Clases irrelevantes ImpresoraRecibo Teclado Pantalla DispensadorBilletes MensajeEnPantalla ErrorSobreDeposito TeclaTimeOut BitacoraTransaccio nes Cantidad Impresora SalvaPantallas TeclaNumerica Tecla ClienteBancario Recibo

POR QUE LAS TARJETAS

Las tarjetas son una herramienta para estimar si el conjunto de clases obtenida hasta este punto (o versiones posteriores del mismo) responden bien a las necesidades dinmicas del sistema Se crean a partir de la lista de clases bsicas Si resultan evidentes, se incluyen responsabilidades y colaboraciones Si no se dejan para ser identificadas durante la escenificacin de iteraciones

CONTENIDO DE UNA TARJETA CRC

Nombre de la clase Superclase Subclases Responsabilidades Para cada responsabilidad, lista de las colaboraciones (con qu otras clases tiene que relacionarse esta clase para llevar a cabo esa responsabilidad concreta)
(Opcionalmente) Se puede escribir por detrs: Una definicin breve de la clase Una lista de atributos de la clase

UNA TARJETA CRC: TRANSFERENCIA

Nombre de la clase: Transferencia Responsabilidades Colaboradores

Registrar y validar monto a transferir

Cuenta ConsultaSaldo

EJERCICIO
HISTORIAS DE USUARIO Empresa: Asociacin de agricultores ABC. Solicitud: La Asociacin de agricultores ABC ha pedido el desarrollo de un software que les ayude a automatizar algunas tareas de los cultivos de invernadero. A continuacin se exponen los requisitos o historias de usuario:

EJERCICIO
Los invernaderos se dividiran en zonas (lgicas), segn los cultivos. En cada zona, existiran los siguientes tipos de dispositivos: luz artificial y generadores de calor. Tambin, por zona, debera tener detectores de humedad de ambiente y detectores de humedad de la tierra. Adems, se requiere tener termmetros digitales distribuidos por las zonas, as como sensores de luminosidad que permitan saber la cantidad de luz de un zona. Se contara con un sistema de riego por aspersin que se pueda activar y desactivar de acuerdo a ciertas reglas. Que, a partir de unas reglas que seran por zona, el sistema pueda actuar haciendo funcionar los dispositivos de calor, los de luz artificial o el riego por aspersin, cuando dichas reglas demuestren que es necesario.

EJERCICIO
Lista de clases - luz artificial. - generador de calor. - zona. - detector humedad ambiente. - detector humedad tierra. - termmetro. - sensor luz. - aspersor. - regla.

La metodologa XP, especifica las siguientes actividades dentro de la ejecucin de iteraciones.

Diseo de pruebas de aceptacin Especificacin de escenarios para convertirlos en mdulos. funcionales. Refactorizacin de cdigo si es necesario. Ejecucin de pruebas de aceptacin. PRUEBAS DEL SISTEMA Se crea las pruebas de aceptacin, tambin denominadas pruebas de funcionalidad las cuales constituyen uno de los pilares bsicos de la metodologa XP, permitiendo reducir el nmero de errores e incrementar la calidad del producto; representan una salida del sistema que el cliente espera sea funcional, adems de ayudar a realizar un seguimiento del cdigo a emplear. Se pueden agregar nueva funcionalidades o redisear algunas pruebas.

Diseo simple Historias del usuario valores Criterios de las pruebas de iteracin Plan de iteracin Cartas CRC

Soluciones pico prototipos

DISE ION

ICAC F I N PLA

recodificacin

ICAC F I D O

ION

Programacin en pareja

PR U

EB A
Prueba de unidad

Lanzamiento Incremento de software Velocidad calculada del proyecto

Integracin continua

Pruebas de aceptacin

REGLAS
Disponibilidad del cliente No solamente como apoyo a los desarrolladores, sino formando parte del grupo. El involucramiento del cliente es fundamental para que pueda desarrollarse un proyecto con la metodologa XP Uso de estndares de manera que sea fcilmente entendible por todo el equipo Programacin dirigida por las pruebas (Test-driven programming) lo primero que se escribe son los test que el sistema debe pasar. Luego, el des arrollo debe ser el mnimo necesario para pasar las pruebas previamente definida Programacin en pares XP propone que se desarrolle en pares de programadores errores se descubren en el momento en que se codifican defectos encontrados en las pruebas es estadsticamente menor Los diseos son mejores y el cdigo ms corto equipo resuelve problemas en forma ms rpida personas aprenden significativamente ms, acerca del sistema personas aprenden a trabajar juntas, generando mejor dinmica de grupo Las personas disfrutan ms de su trabajo

1. 2. 3. 4. 5. 6. 7.

REGLAS
Integraciones permanentes
necesitan trabajar siempre con la ltima versin. Realizar cambios o

mejoras sobre versiones antiguas causan graves problemas, y retrasan al proyecto. Para evitar errores, solo una pareja de desarrolladores puede integrar su cdigo a la vez.

Propiedad colectiva del cdigo

todo el equipo puede contribuir con nuevas ideas que apliquen a cualquier parte del proyecto. En XP, se promueve la recodificacin, en aras de generar cdigos mas simples y adaptados a las realidades cambiantes

Ritmo sostenido
debe llevarse un ritmo sostenido de trabajo. Anteriormente, sta prctica se denominaba Semana de 40 horas. planificar el trabajo de manera de mantener un ritmo constante y razonable, sin sobrecargar al equipo

PRCTICAS
Liberacin limitada: para que el desarrollo de xp tenga xito estos productos deben administrarse con rapidez. Esto significa que los programadores no pueden implementarse las caractersticas en una sola pieza de software, la versin debe liberarse de acuerdo con lo programado. Si, esto es extremo, pero los clientes estarn contentos porque tendrn producto para usar. Ms tarde pueden hacerse cualquier mejora.

Semana de trabajo de 40 horas: los equipos de desarrollo de xp fomentan una prctica cultural en la que el equipo trabaja de manera intensa durante una semana tpica de cuarenta horas. Esta prctica es esencial de la programacin extrema y tiene como propsito motivar alas miembros del equipo a que elaboren intensamente en el lugar de trabajo, y que tomen un periodo de descanso para que cuando vuelven al trabajo estn relajados, menos presionados, con capacidad de detectar los problemas y menos proclives a cometer errores costosos y omisiones debido a un desempeo ineficiente o a la apata.
Cliente en el sitio: la mayora de los desarrolladores de sistemas argumentan que el cliente es vital para el xito del sistema, pero terminan reunindose solo una o dos veces con el cliente para determinar los requerimientos del sistema. Esta persona toma parte activa en el proceso, pues escribe los relatos de usuario (vase el capitulo 6), se comunica con los miembros del equipo y ayuda a establecer prioridades. Programacin en parejas: ejecutan las pruebas y conversan acerca de formas de hacer eficientes y eficazmente trabajo. Al trabajar con otro programador puede clasificar su forma de pensar. La programacin en parejas ahora tiempo, reduce la negligencia, estimula la creatividad y es una manera divertida de programar

ROLES
Programadores A diferencia de los otros programadores, a los de xp se les exige ser buenos comunicadores. Cliente el cliente debe aprender a escribir relatos del usuario, aprender a escribir pruebas funcionales para las aplicaciones que generen los programadores. Probador El programador tambin necesita comunicarse con el cliente sobre las pruebas del funcionamiento, realizar pruebas con regularidad, dar mantenimiento a las herramientas de prueba y elaborar informes precisos a cerca de los resultados de las pruebas. Rastreador Da seguimiento de progreso general del grupo calculando el tiempo que toman sus tareas y el progreso de sus metas.

ROLES
Entrenador Mantienen el orden, la calma y seguridad del equipo. Consultor sus miembros le pedirn que resuelva los problemas junto con ellos, fastidindolo a cada momento y cuestionando cualquier suposicin que usted haga. Lo que los equipos de desarrollo de XP esperan de un consultor es que este les ensee a resolver sus propios problemas Gran Jefe o Lder el equipo espera que el gran jefe confe en ellos, requiere de comunicacin constante con el equipo. Su tarea es conseguir que la comunicacin fluya sin convertirse en una ola de rumores. Ante todo, usted n desea ser un obstculo para cualquier cosa razonable que el equipo intente realizar. Este es un rol que exige una total conviccin en el enfoque de XP

CONCLUSIONES
En una encuesta realizada sobre 45 proyectos realizados con XP se concluye que: Casi todos los proyectos se categorizaron como exitosos. El 100% de los desarrolladores encuestados afirmaron que volver a a utilizar la metodologa XP en el siguiente proyecto si fuera apr opiado. Las frecuentes ausencias del cliente fueron identificadas como el mayor riesgo en los proyectos. Los problemas ms comunes fueron barreras psicolgicas, com o por ejemplo el escepticismo de la lnea gerencial, la filosofa de la empresa desarrolladora que no permita tener al cliente en siti o, o que algunos desarrolladores se opona al trabajo en parejas.

BIBLIOGRAFIA
http://desarrollocomercial.blogspot.com/2011/11/r eemplazar-1-de-un-cliente-perdido.html Kent Beck and Martin Fowler-Planning Extreme Programming. Addison.Wesley.User.Stories.Applied.For.Agile.Softw are.Development.Mar.2004.