1. Extreme Programming (XP)
Grupo 03

2. Extreme Programming - Agenda
 Introducción
 Proceso y Fases
 Roles
 Prácticas
 Conclusiones

3. Extreme Programming - Introducción
 Proceso : conjunto de actividades ordenadas para
lograr una serie de objetivos
 Proceso Pesado :
* fuerte dependencia de planificaciones
* se establecen actividades
* se establecen artefactos
* se establecen herramientas y notaciones
* ESTAMOS MUY CONTROLADOS

4. Extreme Programming - Introducción
 Como contraposición : Métodología Ágil
 Características :
A los individuos y su interacción de los procesos y las herramientaspor encima
El software que funciona de la documentación exhaustivapor encima
La colaboración con el cliente la negociación contractualpor encima
La respuesta al cambio seguimiento de un planpor encima

5. Extreme Programming - Introducción
 Resumen
* Estamos menos controlado
* Preparados para el cambio
* Cliente forma parte del equipo
* Pocos artefactos
* Más importante software funcionando que
documentación

6. Extreme Programming - Introducción
 XP es una Métodología Ágil
 Desarrollado por Kent Beck
«Todo en el software cambia. Los
requisitos cambian. El diseño
cambia. El negocio cambia. La tecnología
cambia. El equipo
cambia. Los miembros del equipo cambian.
El problema no es el
cambio en sí mismo, puesto que sabemos
que el cambio va a
suceder; el problema es la incapacidad de
adaptarnos a dicho
cambio cuando éste tiene lugar.»

7. Extreme Programming - Introducción
 Estadísticas : método que más popularidad ha
alcanzado de las metodologías ágiles
 Se basa en la suposición de que es posible
desarrollar software de gran calidad a pesar, o
incluso como consecuencia del cambio continuo
 Asume que con un poco de planificación, un poco de
codificación y unas pocas pruebas se puede decidir
si se está siguiendo un camino acertado o
equivocado, evitando así tener que echar marcha
atrás demasiado tarde.

8. Extreme Programming - Introducción
 Valores que inspiran XP
FEEDBACK CORAJE COMUNICACIÓNSIMPLICIDAD

9. Extreme Programming - Introducción
 Simplicidad
 La simplicidad consiste en desarrollar sólo el sistema
que realmente se necesita. Implica resolver en cada
momento sólo las necesidades actuales.
 Con este principio de simplicidad, junto con la
comunicación y el feedback resulta más fácil conocer
las necesidades reales
Los costos y la complejidad de predecir el futuro son muy elevados, y la mejor
forma de acertar es esperar al futuro.

10. Extreme Programming - Introducción
 FeedBack
 Una metodología basada en el desarrollo incremental
iterativo de pequeñas partes, con entregas y pruebas
frecuentes y continuas, proporciona un flujo de retro-
información valioso para detectar los problemas o
desviaciones.
 De esta forma fallos se localizan muy pronto.
 La planificación no puede evitar algunos errores, que
sólo se evidencian al desarrollar el sistema.
 La retro-información es la herramienta que permite
reajustar la agenda y los planes.

11. Extreme Programming - Introducción
 Coraje
 Implica saber tomar decisiones difíciles.
 Reparar un error cuando se detecta
 Mejorar el código siempre que tras el feedback y las
sucesivas iteraciones se manifieste susceptible de
mejora
 Tratar rápidamente con el cliente los desajustes de
agendas para decidir qué partes y cuándo se van a
entregar

12. Extreme Programming - Introducción
 Comunicación
 XP pone en comunicación directa y continua a
clientes y desarrolladores. El cliente se integra en el
equipo para establecer prioridades y resolver dudas.
De esta forma ve el avance día a día, y es posible
ajustar la agenda y las funcionalidades de forma
consecuente

13. Extreme Programming – Proceso y Fases
 1. El cliente define el valor de negocio a implementar
 2. El programador estima el esfuerzo necesario para
su implementación
 3. El cliente selecciona qué construir, de acuerdo con
sus prioridades y las restricciones de tiempo
 4. El programador construye ese valor de negocio
 5. Vuelve al paso 1

14. Extreme Programming – Proceso y Fases
 El costo del cambio

15. Extreme Programming – Proceso y Fases
 Historias de Usuario
 Técnica para especificar los reqs.
 Son tarjetas de papel
 Debe ser lo suficientemente comprensible y
delimitada para que los programadores puedan
implementarla en unas semanas

16. Extreme Programming – Proceso y Fases
 Fases
 Exploración
 Planificación de la Entrega
 Iteraciones
 Producción
 Mantenimiento
 Muerte del Proyecto

17. Extreme Programming – Proceso y Fases

18. Reglas y prácticas de XP
 Conjunto de actividades simples que guían
los diferentes aspectos del desarrollo para
seguir el proceso.
 Se dividen en áreas del desarrollo
 Planificación
 Diseño
 Codificación
 Verificación

19. Reglas y prácticas de XP - Planificación
 El “Juego de la Planificación”
 Planificación se vuelve “emocional”
 Todos quieren planificar mejor
 Conflictos
 Mirar la planificación como un Juego
 Objetivos
 Jugadores
 Piezas
 Reglas

20. Reglas y prácticas de XP - Planificación
 El “Juego de la Planificación”
 Piezas: Historias de Usuario
 Objetivo: Poner en producción la mayor
cantidad de Historias de Usuario
 Jugadores: Desarrolladores y Encargados del
Negocio

21. Reglas y prácticas de XP - Planificación
 El “Juego de la Planificación”
 Movimientos:
 Escribir Historia de Usuario
 Estimarla
 Comprometerse a realizar:
 Por Historia
 Por Fecha
 Valor y Riesgo Primero
 Recuperación por Sobrecarga
 Cambio de Valor de Historia
 Introducir nueva Historia
 Dividir una Historia
 Salto
 Re-estimar

22. Reglas y prácticas de XP - Planificación
 Escribir Historias de Usuario
 Similar a los Casos de Uso
 Usadas para estimaciones de tiempo en la
planificación de las liberaciones
 Usados en lugar del Documento de
Requerimientos
 Escritas por el Cliente en términos del Cliente
 Guían la creación de Pruebas de Aceptación

23. Reglas y prácticas de XP - Planificación
 Los Planes de Liberación organizan el
Calendario
 Surgen en las reuniones de Planificación de
Liberaciones
 Utilizados para crear Planes de Iteraciones
 Decisiones Técnicas por el personal Técnico y
decisiones de negocio por el personal de
Negocio

24. Reglas y prácticas de XP - Planificación
 El equipo estima la duración de la
implementación de cada Historia de Usuario
en “Semanas Ideales de Implementación”
 El cliente prioriza las Historias teniendo en
cuenta el valor que le aporta al sistema
tenerla completa

25. Reglas y prácticas de XP - Planificación
 Medir la “Velocidad del Proyecto”
 ¿Cuánto trabajo está siendo completado en el
proyecto?
 Suma de las estimaciones de las Historias de
Usuario completas al fin de la Iteración
 Utilizada para planificar la siguiente Iteración

26. Reglas y prácticas de XP - Planificación
 Utilizamos la “Velocidad del Proyecto” para
planificar
 Por Fecha
 Por Alcance

27. Reglas y prácticas de XP - Planificación
 Liberaciones pequeñas y frecuentes
 Producir rápidamente versiones operativas del
sistema
 No debería tardar más de 3 meses

28. Reglas y prácticas de XP - Planificación
 Rotación del Equipo
 Ayuda a evitar “Islas de Conocimiento”
 Mejora la flexibilidad del equipo
 Evita la sobrecarga de una persona

29. Reglas y prácticas de XP - Planificación
 Mejorar el proceso cuando sea necesario
 Es bueno tener reglas para saber qué esperar
del equipo
 Si se detectan problemas en el avance se
debe revisar qué está mal
 Debe consultarse al equipo sobre qué cosas
dificultan el funcionamiento

30. Reglas y prácticas de XP - Diseño
 Diseño simple:
 Implementar la solución más simple que
pueda funcionar
 La complejidad innecesaria y el código extra
debe ser removido inmediatamente
 No agregar nuevas funcionalidades antes de
que sean agendadas

31. Reglas y prácticas de XP - Diseño
 Metáforas:
 El sistema es definido mediante una metáfora
o un conjunto de metáforas compartidas por el
cliente y el equipo de desarrollo
 Es una historia compartida que describe cómo
debería funcionar el sistema
 Solventan el hecho de no contar con una
definición de la arquitectura desde el
comienzo, ya que en XP la arquitectura se
asume evolutiva

32. Reglas y prácticas de XP - Diseño
 Tarjetas CRC:
 Las Tarjetas CRC (Class, Responsibilities and
Collaboration) sirven para diseñar el sistema
en conjunto entre todo el equipo
 Permiten reducir el modo de pensar
procedural y apreciar la tecnología de objetos

33. Reglas y prácticas de XP - Diseño
 No agregar funcionalidades antes de lo
planeado:
 Parecería que fuera más rápido agregarlas
ahora pero nosotros debemos recordarnos
constantemente que no las necesitamos
ahora realmente y quizás nunca las
necesitemos
 Funcionalidades extra siempre nos hacen
atrasar y malgastar nuestros recursos

34. Reglas y prácticas de XP - Diseño
 Refactorización:
 Es una actividad constante de
reestructuración del código con el objetivo de
remover duplicación de código, mejorar su
legibilidad, simplificarlo y hacerlo más flexible
para facilitar los posteriores cambios
 Mejora la estructura interna del código sin
alterar su comportamiento externo
 Nos ahorra tiempo e incrementa la calidad

35. Reglas y prácticas de XP - Codificación
 El cliente está siempre disponible:
 Gran parte del éxito del proyecto XP se debe
a que es el cliente quien conduce
constantemente el trabajo hacia lo que
aportará mayor valor de negocio
 La comunicación oral es más efectiva que la
escrita, ya que esta última toma mucho tiempo
en generarse y puede tener más riesgo de ser
mal interpretada

36. Reglas y prácticas de XP - Codificación
 Las historias de usuario son escritas por los
clientes con la ayuda de los desarrolladores
 El cliente debe negociar la selección de las
historias de usuario que serán incluidas en
una liberación
 Como los detalles no son incluidos en las
historias de usuario, los desarrolladores
necesitarán hablar con los clientes para
obtenerlos
 El cliente es necesario con las pruebas

37. Reglas y prácticas de XP - Codificación
 El tiempo del cliente es ahorrado al principio
por no requerir una especificación detallada
de los requerimientos y ahorrado después ya
que el sistema es mucho más probable que
sea de su agrado

38. Reglas y prácticas de XP - Codificación
 Estándares de programación:
 XP enfatiza la comunicación de los
programadores a través del código, con lo
cual es indispensable que se sigan ciertos
estándares de programación
 Mantienen el código legible para los miembros
del equipo, facilitando los cambios

39. Reglas y prácticas de XP - Codificación
 Pruebas unitarias:
 La producción de código está dirigida por las
pruebas unitarias
 Las pruebas unitarias son establecidas antes
de escribir el código y son ejecutadas
constantemente ante cada modificación del
sistema
 Otros desarrolladores podrán ver como usar el
código observando las pruebas

40. Reglas y prácticas de XP - Codificación
 Programación en parejas:
 Incrementa la calidad del software sin
impactar el tiempo para cumplir lo prometido
 Muchos errores son detectados conforme son
introducidos en el código
 Los diseños son mejores y el tamaño del
código menor
 Los problemas de programación se resuelven
más rápido

41. Reglas y prácticas de XP - Codificación
 Se posibilita la transferencia de conocimientos
de programación entre los miembros del
equipo
 Varias personas entienden las diferentes
partes del sistema
 Los programadores conversan mejorando así
el flujo de información y la dinámica del
equipo

42. Reglas y prácticas de XP - Codificación
 Integración secuencial:
 Solo una pareja de desarrolladores puede
integrar, testear y liberar cambios al
repositorio de código en un momento
determinado
 Se permite que la última versión esté
consistentemente identificada

43. Reglas y prácticas de XP - Codificación
 Integración continua:
 Cada pieza de código es integrada en el
sistema una vez que esté lista.
 Así, el sistema puede llegar a ser integrado y
construido varias veces en un mismo día
 Es una forma de que todo el mundo esté
trabajando con casi la última versión
 Evita o detecta antes los problemas de
compatibilidad

44. Reglas y prácticas de XP - Codificación
 Propiedad colectiva del código:
 Cualquier programador puede cambiar
cualquier parte del código en cualquier
momento.
 Motiva a todos a contribuir con nuevas ideas
en todos los segmentos del sistema,
 Evita que algún programador sea
imprescindible para realizar cambios en
alguna porción de código

45. Reglas y prácticas de XP - Codificación
 40 horas por semana:
 Se debe trabajar un máximo de 40 horas por
semana
 No se trabajan horas extras en dos semanas
seguidas
 El trabajo extra desmotiva al equipo

46. Extreme Programming – Roles en XP
 Los roles siempre presentes en esta
metodología son los siguientes:
 Programador
 Cliente
 Encargado de pruebas (Tester)
 Encargado de seguimiento (Tracker)
 Entrenador (Coach)
 Gestor (Big Boss)

47. Extreme Programming – Roles en XP
 Roles Opcionales en los proyectos:
 Consultor
 Doomsayer (Augur de desastres)

48. Extreme Programming – Roles en XP
 El programador escribe las pruebas
unitarias y produce el código del sistema.
Define las tareas que conlleva cada historia
de usuario, y estima el tiempo que requerirá
cada una.
 El cliente escribe las historias de usuario y
las pruebas funcionales para validar su
implementación. Asigna la prioridad a las
historias de usuario y decide cuáles se
implementan en cada iteración centrándose
en aportar mayor valor al negocio.

49. Extreme Programming – Roles en XP
 El encargado de pruebas ayuda al cliente a
escribir las pruebas funcionales. Ejecuta las
pruebas regularmente, difunde los resultados en
el equipo y es responsable de las herramientas
de soporte para pruebas.
 El encargado de seguimiento verifica las
estimaciones realizadas, evalúa el progreso de
cada iteración y así como la factibilidad de los
objetivos con las restricciones de tiempo y
recursos presentes. Mantiene contacto directo
con el equipo de desarrollo, realizando cambios
para lograr los objetivos de cada iteración.

50. Extreme Programming – Roles en XP
 El entrenador es responsable del proceso global.
Experto en XP, provee de las guías a los miembros
del equipo para que se apliquen las prácticas XP y se
siga el proceso correctamente. Determina la
tecnología y metodologías a usar por el equipo de
desarrollo.
 El Gestor es el dueño del equipo y sus problemas.
Experto en tecnología y labores de gestión.
Construye el plantel del equipo, obtiene los recursos
necesarios y maneja los problemas que se generan.
Administra a su vez las reuniones (planes de
iteración, agenda de compromisos, etc).
No le dice al grupo lo que tiene que hacer, cuando
hacerlo, ni verifica el avance de las tareas.

51. Extreme Programming – Roles en XP
 Roles Opcionales
 Consultor
Es un miembro externo del equipo con un
conocimiento específico en algún tema necesario
para el proyecto. Guía al equipo para resolver un
problema específico.
 Doomsayer (Augur de desastres)
Es el responsable de que se conozcan los riesgos
involucrados, que las malas noticias sean
notificadas en la medida correcta, y que no se
sobredimensionen. Busca posibles riesgos en
forma constante, presentándolos al equipo siempre
con una posible solución.

52. Extreme Programming – Roles en XP
 Combinación de Roles
Algunos roles pueden ser combinados en un
mismo individuo. Por ejemplo, el Gestor y el
Tracker.
Sin embargo, otras combinaciones no son
recomendadas; como ser:
 Programador–Tracker, Programador–Tester
 Cliente-Programador, Entrenador-Tracker.

53. Extreme Programming – Conclusiones
 XP es la metodología mas popular dentro de
la familia surgida luego del manifiesto Ágil,
las cuales buscan simplificar los procesos a
través de la reducción de irreversibilidad de
los mismos .
Dicha metodología ha probado ser de gran
utilidad en proyectos pequeños y con
requerimientos altamente cambiantes,
aunque posee características que la hacen
aplicable en ciertos ambientes únicamente.

54. Extreme Programming – Conclusiones
 Conceptos conocidos en los que se basa XP:
 La alta comunicación funciona. Un único ambiente
para el equipo aumenta la productividad
dramáticamente.
 La importancia de la Validación. XP reduce el tiempo
entre una idea, su criterio de validación, y su
implementación. Requiere disponer de pruebas
repetibles automatizadas que aseguren la consistencia
en el futuro.
 El iterar funciona. XP obliga a iterar al establecer
múltiples integraciones por día, iteraciones de una a
tres semanas de largo que concluyan con un sistema
funcionando, y nuevos lanzamientos cada pocos
meses.

55. Extreme Programming – Conclusiones
 El futuro de XP
 Simplificación del proceso de planificación e
integración continua.
 Búsqueda de valores y principios ocultos que
puedan informar de métodos útiles.
 Límites de XP. Cuando se debe seguir? Cual
es su limite de integrantes?
 El rol del Cliente. Es un rol complejo de
interpretar, y probablemente su papel en el
proceso de desarrollo de software continúe
generando nuevas ideas.

56. Preguntas