1 MÉTODOS ÁGILES MÁS ADOPTADOS

1.2 SCRUM

HISTORIA
Ken Schwaber y Jeff Sutherland presentaron conjuntamente por primera vez Scrum en la
12
conferencia OOPSLA en 1995 . Scrum es un marco de trabajo para el desarrollo y el
mantenimiento de productos complejos que ha sido utilizado desde los años 90, en el cual las
personas pueden afrontar complejos problemas adaptativos, a la vez que entregan productos del
máximo valor posible de forma productiva y creativa. Scrum es:

 Ligero
 Fácil de entender
 Extremadamente difícil de llegar a dominar

El marco de trabajo de Scrum consiste en los equipos Scrum y en sus roles, eventos, artefactos y
reglas asociadas. Cada componente dentro del marco de trabajo sirve a un propósito específico y
es esencial para el éxito de Scrum y para su uso.
 Figura 0.3 Proceso Scrum

Scrum se fundamenta en la teoría empírica de control de procesos o empirismo. El

empirismo asegura que el conocimiento procede de la experiencia y de tomar
decisiones basándose en lo que se conoce. Scrum emplea una aproximación iterativa e
incremental para optimizar la predictibilidad y controlar el riesgo.
Tres pilares soportan toda implementación de control empírico de procesos:
transparencia, inspección y adaptación.

 Transparencia.
Se refiere a que los aspectos significativos del proceso deben ser claramente
entendidos por los responsables del resultado, es decir, los responsables deben
de compartir un lenguaje común para referirse al proceso.

 Inspección.
Todo el equipo en Scrum debe inspeccionar frecuentemente los artefactos y
monitorear el avance para detectar variaciones no deseables.

 Adaptación.
Si un inspector detecta que algún aspecto del proceso se desvía de los límites
aceptables, y que el producto resultante no será aceptable, el proceso o el
material que están siendo procesados deberán ser ajustados para minimizar
desviaciones mayores.

ROLES.
El equipo Scrum consiste en un dueño del producto (Product Owner), El equipo de
Desarrollo (Development Team), y un Scrum Master. En Scrum los equipos deben ser
auto-organizados y multifuncionales. Los equipos auto-organizados toman decisiones y
eligen la mejor forma para llevar a cabo su trabajo en lugar de ser dirigidos por otros
externos al equipo. Los equipos multifuncionales tienen todas las competencias
necesarias para llevar a cabo el trabajo. Este modelo de trabajo está diseñado para
optimizar la flexibilidad, la creatividad y la productividad.
Los equipos en Scrum realizan entregas incrementales del producto, asegurando que se
tiene una versión potencialmente útil y funcional del producto.
 • Dueño del Producto (Product Owner).
Es el responsable de maximizar el valor del producto y del trabajo del equipo de
desarrollo. El Product Owner es el único responsable de gestionar el Product
Backlog o listado de Requerimientos funcionales. Esta gestión incluye:
o Describir de manera clara los requerimientos.
o Definir el valor de negocio y la prioridad de cada requerimiento para que el
equipo de desarrollo conozca que requerimientos atender primero.
o Asegurar que el equipo de desarrollo entiende de manera clara cada
requerimiento.

El dueño del producto es una persona no un comité, todas las decisiones y

definiciones que tome el Product Owner en base al producto deben ser
respetadas por todos.

• Equipo de Desarrollo (Development Team).

Son los profesionales que tienen la responsabilidad de entregar un incremento
del producto “Hecho”, potencialmente utilizable, al final de cada Sprint.
Al equipo desarrollo se le otorga el poder por parte de la organización para que
pueda gestionar y llevar a cabo su trabajo, esta sinergia produce eficiencia y
efectividad en el equipo. Los equipos de desarrollo deben cumplir con las
siguientes características:
o Son auto-
organizados. o Son
Multifuncionales.
o No contienen sub-equipos.

• Scrum Master.
Es el responsable de que el proceso de Scrum se entienda y que se aplican las
reglas correctamente. Es un líder servil al servicio del equipo Scrum.

o Servicios del Scrum Master al Product Owner

a) Encontrar técnicas para gestionar el Product Backlog
b) Comunicar la visión y objetivos del Product Backlog
c) Enseñar a crear las historias de usuario
d) Entender el proceso empírico y de adaptación.
e) Facilitar los eventos de Scrum

o Servicios del Scrum Master al Equipo de Desarrollo

a) Entrenar al equipo de desarrollo en ser auto-organizados y
multifuncionales.
b) Formar y liderar a los equipos de desarrollo a crear productos de alto valor.
c) Eliminar impedimentos que afecten el avance del equipo.
d) Facilitar los eventos de Scrum
e) Entrenar al equipo a entender Scrum.

Eventos.
En Scrum existen eventos prescritos, con el fin de crear regularidad y minimizar la
necesidad de reuniones no definidas en Scrum. Se utilizan eventos en la forma de
bloques de tiempo (time-boxes), de modo que todos tienen una duración máxima. Esto
asegura que se emplee una cantidad apropiada de tiempo en la planificación, de forma
que no se admita desperdicio en este proceso de planificación.
Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los
eventos de Scrum constituye una oportunidad para la inspección y adaptación de algún
aspecto. Estos eventos están específicamente diseñados para habilitar la vital
transparencia e inspección. La falta de alguno de estos eventos da como resultado una
reducción de la transparencia y constituye una oportunidad perdida para inspeccionar y
adaptarse.

• Sprint.
El corazón de Scrum es el Sprint, un bloque de tiempo (time-box) de un mes o
menos durante el cual se crea un incremento de producto “Hecho”, utilizable y
potencialmente entregable.
Los Sprints contienen y consisten en la Reunión de Planificación del Sprint
(Sprint Planning Meeting), los Scrums Diarios (Daily Scrum), el trabajo de
desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint
(Sprint Retrospective). Los Sprints habilitan la predictibilidad al asegurar la
inspección y adaptación del progreso hacia un objetivo, al menos en cada mes
de calendario. Los Sprints también limitan el riesgo al incurrido en el coste de un
mes de calendario.

Los Sprints contienen y consisten en:

• Reunión de Planificación del Sprint (Sprint Planning Metting)

Es en esta reunión de no más de 8 horas se realiza el plan de que es lo que se
va a entregar al finalizar el sprint. La reunión se divide en 2 partes, en la
primera parte el Product Owner presenta el Product Backlog ordenado y explica
cada elemento al equipo de desarrollo posteriormente el equipo de desarrollo
tendrá la responsabilidad de seleccionar los elementos del Product Backlog que
desean integrar en el Sprint, una vez hecho esto el equipo Scrum tendrá que
elaborar el Objetivo del Sprint la cual es una meta a alcanzar al finalizar el
sprint. En la segunda parte de la reunión el Equipo de desarrollo define como
construir el producto y determina el tiempo necesario para cada tarea, los
tiempos no deben ser mayores a un día. Los elementos seleccionados y el plan
de tiempo para construirlos recibe el nombre de Sprint Backlog. Si el equipo de
desarrollo determina que tiene demasiado trabajo o poco trabajo para realizar
en el Sprint podrá renegociar con el Product Owner para realizar los ajustes
necesarios al Sprint Backlog.

• Scrum Diario (Daily Scrum)

Es una reunión que tiene lugar todos los días con una duración no mayor a 15
minutos, la idea principal es que el equipo de desarrollo presente las actividades
realizadas desde el último Daily Scrum y haciendo una predicción de lo que
realizara antes del siguiente.
Básicamente en esta reunión el equipo de desarrollo responde a tres preguntas:
1. Que se trabajo el día de hoy?
2. Que actividades se planean realizar el dia de mañana?
3. Existe algún impedimento que afecte el avande?
En el Daily Scrum el Equipo de Desarrollo explica al Product Owner y al Scrum
Master como pretende organizarse para lograr el objetivo del Sprint. El Scrum
Master es el responsable de organizar estas reuniones y de aplicar la regla de
los 15 minutos, sin embargo el Equipo de Desarrollo es el responsable de
dirigirlas. Esta reunión no es de seguimiento ni tampoco de reporte de estado.
 El principal beneficio de esta reunión es que mantiene comunicados a todo el
equipo Scrum y permite la detección temprana de impedimentos. Constituye
una reunión clave de inspección y adaptación.

• Revisión del Sprint (Sprint Review)

En esta reunión se realiza un inspección sobre el incremento del producto hecho
y adaptar el Product Backlog en caso de ser necesario. En esta reunión participa
todo el Equipo Scrum donde el Product Owner identifique lo que se terminó y lo
que no, el Equipo de Desarrollo habla de los problemas que se tuvieron y como
se resolvieron además de que presenta el incremento del producto hecho. Todo
el grupo colabora con comentarios de lo que puede realizarse en el siguiente
Sprint.

• Retrospectiva del Sprint (Sprint Retrospective)

En esta reunión el equipo Scrum se examina así mismo y crea un plan de
mejoras para aplicarse en el siguiente Sprint. En esta reunión se examinan a las
personas, herramientas y procesos y se busca responder básicamente a tres
preguntas:
1. Que hicimos bien en el Sprint?
2. Que no se hizo bien?
3. Que podemos hacer mejor en el siguiente Sprint?

El Scrum Master debe alentar el equipo, para que mejore en el proceso Scrum,
su procesos de desarrollo y sus prácticas para hacerlos más efectivos. Al final de
esta reunión el Equipo Scrum debe haber identificado mejoras para aplicar en el
siguiente Sprint.

Artefactos de Scrum.
Los artefactos de Scrum representan trabajo o valor en diversas formas que son útiles
para proporcionar transparencia y oportunidades para la inspección y adaptación.

• Product Backlog
Es una lista ordenada de todos los requerimientos funcionales del producto. El
Product Owner es el responsable de elaborar este documento. Un Product
Backlog nunca es estático, durante el proceso de construcción en cada
incremento la lista puede ir cambiando y evolucionando para tener un producto
más adecuado, competitivo y útil. El product Backlog tiene como atributos su
descripción, su priorización y el valor de negocio que aporta. Los cambios en los
requerimientos de negocio, las condiciones de mercado o la tecnología podrían
generar cambios sobre el Product Backlog.
La definición a detalle de cada elemento del Product Backlog se lleva a tiempo
parcial dentro el Sprint entre el Product Owner y el Equipo de Desarrollo. El
equipo de desarrollo es el responsable de proporcionar todas las estimaciones
para cada elemento de la lista.

• Seguimiento del Avance (Burndown)

En cualquier momento durante el Sprint es posible sumar las horas del trabajo
total restante para alcanzar el objetivo y medir el avance. Existen varias
tendencias de trabajo consumido como el Burndown Chart que pueden ayudar a
predecir el progreso.
 • Sprint Backlog
Es el conjunto de elementos seleccionados del Product Backlog para el Sprint,
más un plan para entregar un incremento del producto. Es una predicción hecha
por el Equipo de Desarrollo acerca de que funcionalidad formara parte del
incremento del producto y del trabajo necesario para realizarlo. En el Sprint
Backlog el Equipo de Desarrollo detalla cada tarea necesaria para construir el
incremento y le asigna el tiempo necesario. Esta lista y su detalle pueden ir
cambiando durante la ejecución del Sprint si el Equipo de Desarrollo lo considera
así. Es importante que el Equipo de Desarrollo vaya actualizando su avances
sobre las tareas realizadas ya que esto actualiza la estimación de trabajo
restante.

1.2 EXTREME PROGRAMMING

HISTORIA
El origen Extreme Programming (XP) inicio en los 90’s cuando Kent Beck trabajando en un
13
proyecto para Chrysler buscaba una mejor forma de crear software . Una de las
características principales de este método que lo diferencia del modelo en cascada es que se
basa en la adaptabilidad en lugar de la predictibilidad. La razón de este enfoque se basa en
que el desarrollo de software es un proceso muy fluido y cambiante, donde no se puede
prever la totalidad de los requisitos desde el principio ya que estos van cambiando durante el
proyecto. Por lo tanto el desarrollo de software requiere de una metodología que sea capaz
de adaptarse a los constantes cambios de los requerimientos.

CICLO DE VIDA.
El enfoque de esta metodología es generar el más alto valor al cliente de la manera más
rápida posible. A diferencia del modelo en cascada que tiene que seguir de manera
secuencial las etapas de planeación, análisis y diseño, en XP los programadores hacen
todas estas actividades en cada iteración del desarrollo.
La metodología Extreme Programming o XP inicia con la planeación y todas las
iteraciones consisten de cuatro fases básicas: Planear, Diseñar, Codificar y Probar. Los
valores primordiales para llevar este ciclo de vida son la comunicación continua entre el
cliente y los programadores, la simplicidad para diseñar la solución, la retroalimentación
de las pruebas de aceptación y el coraje para enfrentar los problemas proactivamente y
para aceptar los cambios en la fase de desarrollo.

Figura 0.4 Ciclo de Vida Extreme Programming

• PLAN DE LIBERACIÓN (RELEASE PLANNING).
En esta etapa se organiza la reunión de Planning Game donde el cliente se
reúne con el equipo de desarrollo para presentarle los requerimientos
funcionales o historias de usuario. El equipo de desarrollo organiza las historias
de usuario en iteraciones y estima el esfuerzo necesario para cada una de ellas.
Con el esfuerzo estimado y el conocimiento que se tiene de la importancia de
cada funcionalidad el cliente elabora un plan de liberación inicial el cual será la
base para la planeación de las iteraciones.

• PLANEACIÓN DE LA ITERACIÓN (ITERATION PLANNING).

En esta etapa se organiza una reunión para elaborar el plan de las tareas que el
equipo de desarrollo necesita realizar para entregar un incremento del producto al
final de la iteración. Para ello el cliente selecciona las historias de usuario del plan de
liberación que desea sean incluidas en la iteración, posteriormente el equipo de
desarrollo divide cada historia en tareas a realizar y le asigna un tiempo estimado
para llevarlas a cabo. Con esto se consigue un plan detallado a nivel técnico del
trabajo que el equipo de desarrollo va a realizar

• DISEÑO (DESIGNING).
La iteración en XP inicia con el diseño, un buen diseño es lo que te permite
realizar cambios de manera simple al software sin afectar la funcionalidad. La
idea principal del diseño incremental es la simplicidad, es decir, hacer solo lo
necesario sin agregar funcionalidad extra que no se necesita en ese momento,
emplear buenas prácticas para el diseño de las clases, como estándares de
nombres y usar las tarjetas de responsabilidades y colaboración de clases (CRC),
esto permite que los miembros del equipo contribuyan con ideas y considerarlas
en el diseño. No es una actividad que se realiza una sola vez en el proyecto, sino
que es una actividad de todo el tiempo. El equipo de desarrollo se reúne en
sesiones rápidas de diseño antes de la iteración y revisiones de diseño durante
la iteración a través de la refactorización de código. Extreme Programming
emplea técnicas como la integración continua de código, las pruebas unitarias y
la refactorización de código.

• CODIFICACIÓN (CODING)
Uno de los elementos más importantes en un proceso de desarrollo de software
es el código, sin él no existirá un producto funcional. En XP Codificar es una
forma de aprendizaje, es tener un pensamiento y luego probarlo para saber si
fue una buena idea.
La programación en pares (Pair Programming) por dos programadores
trabajando juntos en un solo equipo, permite la generación de código de alta
calidad. El código da la oportunidad de comunicar de una forma clara y
consistente una idea, esta comunicación se transforma en aprendizaje y reduce
la probabilidad de malas interpretaciones.

• DESARROLLO GUIADO POR PRUEBAS (TEST-DRIVEN DEVELOPMENT)

XP incluye una serie de prácticas para pruebas. Cada miembro del Equipo,
Desarrolladores, Clientes y Testers realizan su propia contribución para obtener
un producto de calidad. Primero los Desarrolladores a través del desarrollo
orientado a pruebas (test-driven development) proveen la primera línea de
defensa, realizando pruebas unitarias automatizadas de cada parte construida,
asegurando que el código tecleado no presenta ninguna falla técnica.
Posteriormente el Cliente realiza las pruebas funcionales y de lógica del
producto, verificando que el producto realiza lo que se espera que haga y
 finalmente los Testers mediante pruebas de exploración buscan fallas. Cuando el
Tester identifica la falla, el equipo debe realizar un análisis de causa raíz y
considerar como mejorar el proceso para prevenir fallas similares en el futuro.
Los Testers también son responsables de explorar las características no
funcionales del software como son el rendimiento y la estabilidad. Cuando las
fallas son corregidas los Desarrolladores deben ejecutar las pruebas
automatizadas para asegurarse de que no ocurren nuevamente. La idea
principal de las pruebas en XP es realizar pruebas mientras se está codificando,
esta es la forma más rápida de generar un producto de calidad.

• PRUEBAS DE ACEPTACIÓN (ACCEPTANCE TEST)

Las pruebas de aceptación son escenarios de prueba que define el cliente para
cada historia de usuario, lo cual representa un resultado o comportamiento
esperado del sistema. Los clientes son los responsables de validar que las
pruebas de aceptación fueron exitosas. Una historia de usuario no se considera
terminada si alguna de sus pruebas de aceptación no paso. Es responsabilidad
del equipo de desarrollo calendarizar el tiempo en cada iteración para la
corrección de fallas. Es recomendable que estas pruebas de aceptación sean
automatizadas para que sean realizadas de manera más ágil y frecuente.

• ESCUCHAR (LISTENING)
Los Desarrolladores deben estar preparados para escuchar a la gente del
negocio o al Cliente, para entender las necesidades y los requerimientos. La
actividad de escuchar debe ser recíproca y básicamente se basa en la
retroalimentación del cliente durante la fase de desarrollo y sobre todo de las
pruebas de aceptación. Cada retroalimentación del cliente se convierte en la
base para volver a entrar al ciclo de diseño, código, prueba y escuchar, si el
cliente está satisfecho con los resultados la iteración termina en ese momento y
el diseño de la nueva iteración comienza.

ROLES.
CLIENTE (CUSTOMER).
Los clientes en XP son los responsables de definir que funcionalidades debe tener el
software. Su principal actividad es en la planificación de la liberación (reléase planning).
Son los encargados de transmitir la visión, identificar y describir las historias de usuario,
determinar cómo agrupar las funcionalidades en pequeñas liberaciones, gestionar
riesgos y realizar el plan del juego (Planning Game). Adicionalmente el cliente es
responsable de proporcionar a los programadores detalles sobre los requisitos cuando
se lo soliciten, también ayudan a comunicar los requisitos, a través, de la creación de
pantallas prototipo, en la revisión de los trabajos en curso y creando pruebas de usuario
detalladas para clarificar reglas de negocio complejas.

PROGRAMADORES (PROGRAMMERS).
Los programadores son los responsables de encontrar la forma más efectiva de entregar
las historias dentro el plan. Para lograr esto, los programadores deben realizar
estimaciones de esfuerzo, sugieren alternativas y ayudan a los clientes a crear un plan
alcanzable para el juego de planificación (Planning Game). Los programadores invierten
la mayoría del tiempo haciendo programación en parejas, codificando, realizando
pruebas unitarias, refactorización y generando incrementalmente el diseño y la
arquitectura de la aplicación. Otras actividades son la corrección de fallas, la
preparación de las liberaciones y de realizar integración continua. Los programadores
tienen que trabajar en conjunto con el cliente para aclarar dudas sobre lo que se tiene
que construir.
VERIFICADORES (TESTERS).
Los Testers ayudan a los equipos XP a producir aplicaciones de calidad. Los Tester deben
colaborar con el Cliente para generar buenos casos de prueba e identificar posibles
mejoras al producto. Los Testers deben realizar pruebas exploratorias para identificar
proactivamente posibles fallas antes de que se finalice la codificación y deben
proporcionar información sobre exploraciones que se apliquen a requerimientos no
funcionales como son el rendimiento, la escalabilidad y estabilidad. Cuando los testers
encuentran fallas deben de apoyar a todo el equipo a averiguar la causa, así todo el
equipo puede prevenir que la falla se repita en el futuro.

ENTRENADORES (COACHES).
Los Coaches o Entrenadores son básicamente las personas que se encargan de motivar
al equipo a alcanzar su potencial en lugar de estar asignando tareas. El concepto
principal es que los Equipos XP sean auto-organizados, es decir que tomen sus propias
decisiones para ser eficientes. Los coaches ayudan al equipo a iniciar su proceso
facilitándoles un espacio de trabajo compartido y de asegurarse de que el equipo
cuenta con la gente correcta para realizar el trabajo. Ayudan a crear las condiciones
para que el equipo sea productivo. Una de las actividades más importantes del Coach es
ayudar al equipo a interactuar con el resto de la organización. Pero sobre todo los
coaches ayudan a los miembros del equipo a ser disciplinados, ayudándolos a que sigan
las prácticas de gestión de riesgos, desarrollo orientado a pruebas y el uso de diseño
incremental.

PRÁCTICAS.
Extreme Programming tiene 12 prácticas agrupadas en cuatro áreas, derivadas de las
mejores prácticas de la ingeniera de software:

Figura 0.5 Prácticas Extreme Programming

EL EQUIPO COMPLETO (WHOLE TEAM).

✔ Todos los contribuidores de un proyecto en XP son un solo equipo.
✔ Debe incluir un representante del negocio. El Cliente.
✔ Los miembros del equipo son programadores, testers, analistas, coaches o
entrenadores, managers.

JUEGO DE LA PLANIFICACIÓN (PLANNING GAME).

Es una reunión que ocurre una sola vez por iteración y se define lo siguiente:
 ✔ Dos preguntas clave en el desarrollo de software:
1. Predecir que se puede lograr en la fecha comprometida
2. Determinar que se puede hacer posteriormente

✔ Predicción exacta no es necesaria

✔ Planeación de Liberación XP (Release Planning):
o El Cliente presenta las funcionalidades requeridas
o Programadores estiman dificultad
✔ Planeación de Iteración XP (Iteration Planning)
o Iteraciones de 2 semanas
o Cliente presenta las
funcionalidades requeridas o Programadores
detallan las tareas necesarias
o Los miembros del equipo se comprometen por las
tareas o Entregar software funcional al final de la
iteración.

PRUEBAS DEL CLIENTE (CUSTOMER TEST).

✔ El cliente define las pruebas de aceptación por funcionalidad.
✔ El equipo implementa pruebas automatizadas de cada funcionalidad.

LIBERACIONES PEQUEÑAS (SMALL REALEASES).

✔ En cada iteración el Equipo libera software funcional y probado
✔ El cliente puede evaluar y liberar a usuarios finales y proveer retroalimentación

DISEÑO SIMPLE (SIMPLE DESIGN).

✔ Durante la planeación y codificación del software mantener un diseño simple y
orientado únicamente a lo que se necesita construir en la iteración.
✔ Los equipos diseñan y revisan el diseño a través de la refactorización en cada
iteración.

PROGRAMACIÓN EN PAREJAS (PAIR PROGRAMMING).

✔ La codificación del software debe realizarse en parejas de 2 programadores en
el mismo equipo.
✔ La resolución de problemas de código en pares da como resultado una mejor
calidad en el código
✔ Trabajar en parejas también permite transferir conocimiento.

DESARROLLO DIRIGIDO POR PRUEBAS (TEST-DRIVEN DEVELOPMENT O TDD).

✔ Equipos usan TDD durante la codificación probando al momento lo que se
construye.
✔ Facilidad de producir código probado al 100%

MEJORA DEL DISEÑO (DESIGN IMPROVEMENT).

✔ Refactorización de las clases y métodos utilizando técnicas y patrones para un
mejor diseño.

INTEGRACIÓN CONTINUA (CONTINUOS INTEGRATION).

✔ Liberaciones frecuentes del producto funcional, después de la codificación y las
pruebas automatizadas.
PROPIEDAD COLECTIVA DEL CODIGO (COLLECTIVE CODE OWNERSHIP).
✔ Cualquier pareja de programadores puede mejorar cualquier código en cualquier
momento
✔ Todo el código obtiene beneficios de todo el equipo

CODIFICACIÓN STANDAR (CODING STANDARD).

✔ Usar un estándar de codificación.
✔ Todo el código del sistema debe verse como si fuese codificado por una sola
persona.
✔ el código debe ser familiar para todos

METAFORA (METAPHOR).
✔ Los equipos XP deben desarrollar una visión común del sistema
✔ Asegurar que todos entiendan como el sistema debe trabajar.

RITMO SOSTENIBLE (SUSTAINABLE PACE).

✔ Trabajar a un ritmo que pueda ser sostenido durante la iteración
✔ Evitar tiempos extras y mantener el trabajo de 40 horas a las semana
✔ Proyectos de marchas forzadas son improductivos y de mala calidad

COMUNICACIÓN.
Una de las causas de que los proyectos fracasen se deben a una mala comunicación del
equipo, XP a través de las prácticas como la programación por parejas y el desarrollo
dirigido por pruebas permite que programadores y clientes estén siempre comunicados,
por otro lado XP usa el rol de Coach quien tiene la función de detectar cuando no haya
una buena comunicación y establecer canales claros de comunicación entre el equipo.

SIMPLICIDAD.
La simplicidad en XP se enfoca en el diseño y la codificación de las necesidades que se
tengan en el presente y no preocuparse por hacer algo por las futuras. Por otra parte el
emplear un diseño y codificación simple, ayuda a dar claridad y entendimiento del
producto a todo el equipo.

RETROALIMENTACIÓN.
En XP la retroalimentación ocurre durante todo el ciclo de vida, por ejemplo durante la
planeación del juego, durante las pruebas unitarias y de aceptación y en general
durante todo el proyecto las mismas prácticas impulsan a tener una clara
retroalimentación del estado del sistema. Una buena retroalimentación se basa en una
buena comunicación y en la simplicidad.

CORAJE.
El coraje es un valor que todo el equipo debe usar constantemente en el proyecto, para
enfrentar los retos y los problemas que se presenten, los programadores por ejemplo
deben tener el coraje para aceptar que el código se puede mejorar siempre, para
reconocer cuando algo no funciona y se debe cambiar, coraje para apoyarse de otro
miembro del equipo y resolver un problema.