Ing.

Manuel Alcntara Ramrez

Programacin Extrema

Como surge XP
Creado por Kent Beck

En el proyecto C3 en Chrysler
Kent dirigi el proyecto
Durante el proceso naci esta nueva metodologa: eXtreme

Programming (XP)
C3 concluy exitosamente en 1997

UNTECS - Manuel Alcntara R.

Qu es XP?
Es una metodologa gil que se caracteriza por:
Estar diseada para entornos dinmicos.

Es Flexible.
Es Predecible.

Para equipos pequeos (mximo 10 programadores).

Orientada fuertemente hacia la codificacin.

nfasis en la comunicacin informal, verbal.

De bajo riesgo

UNTECS - Manuel Alcntara R.

Comparacin Ciclos de vida

Tradicionales con el de XP

UNTECS - Manuel Alcntara R.

Caractersticas de XP
Metodologa creada a base de prueba y error.

Considera 4 valores que pueden mejorar cualquier

proyecto de software:

Simplicidad,
Comunicacin,
Realimentacin,
Coraje.

Expresada en forma de 12 prcticas (algunas ya

existentes desde hace aos), que se soportan las unas a

las otras y conforman un conjunto completo.

UNTECS - Manuel Alcntara R.

Simplicidad
Hacer que el sistema funcione lo mas simple posible

Mantener el sistema en la condicin mas simple posible.

En relacin al proceso y la codificacin, el principio es hacerlo

simple que pueda funcionar,

Es mejor hacer algo simple hoy, que hacerlo ms complicado hoy y
probablemente nunca usarlo.

UNTECS - Manuel Alcntara R.

Comunicacin
El cliente es parte del equipo de desarrollo.

Comunicacin constante entre el equipo de gestin y el

equipo de desarrollo.
Comunicacin constante entre desarrolladores.
XP hace casi imposible la falta de comunicacin.

UNTECS - Manuel Alcntara R.

Retroalimentacin
Retroalimentacin concreta y frecuente del cliente, del equipo y

de los usuarios finales da una mayor oportunidad de dirigir el

esfuerzo.
Testeo continuo a travs de todo el proceso
Testeo como herramienta de especificacin y desarrollo

Testeo como garanta de integridad del cdigo frente a

cambios.
Velocidad, pero adems calidad

UNTECS - Manuel Alcntara R.

Coraje
Se requiere coraje para comunicarse con los dems

cuando eso podra exponer la propia ignorancia.

Se requiere coraje para mantener el sistema simple,
dejando para maana las decisiones de maana.
Se requiere coraje para confiar en que la
retroalimentacin durante el camino es mejor que tratar
de adivinar todo con anticipacin.
Es difcil ser valeroso.
Se requiere coraje para enfrentar la reaccin frente a los

cambios

10

UNTECS - Manuel Alcntara R.

Proceso de desarrollo de software con XP

11

UNTECS - Manuel Alcntara R.

Proceso de Desarrollo de Software con XP

Escenarios de testeo

Historias de
usuario

Prototipo
arquitectnico

requerimientos

Metfora de
sistema

Historias nuevas
Velocidad del proyecto
Plan de entregas

Planificacin de
entregas

Estimacin
incierta

Iteracin
Estimacin
confiable

bugs

Versin mas
reciente

Prxima
iteracin

Prototipo

12

UNTECS - Manuel Alcntara R.

Tests de
aceptacin

Aprobacin del
cliente

Pequeas
entregas

Proceso de Desarrollo de Software con XP

13

UNTECS - Manuel Alcntara R.

Iteracin

14

UNTECS - Manuel Alcntara R.

Iteracin
Historias nuevas,
Velocidad de proyecto
Plan de entregas

Prxima
iteracin

Bugs

Historias de
usuario

Velocidad de
proyecto

Aprender y
comunicar

Planificacin de
iteracin

Plan de
iteracin

Funcionalidades
nuevas

Desarrollo

Tests de
aceptacin
fallados

15

Correccin de bugs

Da a da

UNTECS - Manuel Alcntara R.

Versin mas
reciente

Desarrollo

16

UNTECS - Manuel Alcntara R.

Desarrollo

Aprender y
comunicar
Tareas sin terminar

Plan de iteracin
tareas

Demasiado por
hacer

Reunin de
pie

Da a da
17

Tests de
aceptacin
fallados

UNTECS - Manuel Alcntara R.

Prxima tarea o test de

aceptacin fallido

Programacin en pares
Reconstruccin de cdigo

Tests de unidad
pasados al 100%

Nueva
funcionalidad

Manejo colectivo del

software
Test de
aceptacin
aprobado

Correccin de
bugs

Manejo colectivo del cdigo

Mover Gente
Cambio de
par

Prxima tarea o
test de
aceptacin

Pares

Creacin de
unidad de testeo

Unidad de
testeo fallida
Unidad de
testeo aprobada

Se necesita ayuda

Programacin en
pares
Cdigo
complejo

Cdigo
simple

Reconstruccin
despiadada
18

UNTECS - Manuel Alcntara R.

100% de
unidades de
testeo pasados
Ejecutar
todas las
unidades
de testeo

Ejecutar test
de aceptacin
fallados

Test de
aceptacin
aprobado

Proceso de Desarrollo de Software con XP

UNTECS - Manuel Alcntara R.

19

Resumen de prcticas

20

Proceso de planificacin

Programacin en pares

Entregas pequeas

Propiedad colectiva

Metfora del sistema

Integracin continua

Diseo simple

Semana de 40 horas

Testeo

Cliente siempre disponible

Reconstruccin

Estndares de codificacin

UNTECS - Manuel Alcntara R.

Interaccin entre las Prcticas

21

UNTECS - Manuel Alcntara R.

Roles en XP
Programador (Programmer)
Responsable de decisiones tcnicas
Responsable de construir el sistema
Sin distincin entre analistas, diseadores o codificadores

En XP, los programadores disean, programan y realizan las pruebas

22

UNTECS - Manuel Alcntara R.

Roles en XP
Jefe de Proyecto (Manager)
Organiza y gua las reuniones
Asegura condiciones adecuadas para el proyecto

Cliente (Customer)
Es parte del equipo

Determina qu construir y cundo

Establece las pruebas funcionales

23

UNTECS - Manuel Alcntara R.

Roles en XP
Encargado de Pruebas (Tester)
Ayuda al cliente con las pruebas funcionales
Se asegura de que las pruebas funcionales se superen

Rastreador (Tracker)
Hace el seguimiento del proyecto.
Observa sin molestar.

Conserva datos histricos.

24

UNTECS - Manuel Alcntara R.

Roles en XP
Entrenador (Coach)
Responsable del proceso
Tiende a estar en un segundo plano a medida que el equipo madura

25

UNTECS - Manuel Alcntara R.

Artefactos esenciales en XP
Historias del Usuario

Tareas de Ingeniera
Pruebas de Aceptacin
Pruebas Unitarias y de Integracin
Plan de la Entrega
Cdigo

26

UNTECS - Manuel Alcntara R.

Captura de Requisitos en XP
Se usan Historias del Usuario (User-

Stories)
Establecen los requisitos del cliente

Trozos de funcionalidad que aportan valor

Se les asignan tareas de programacin con un n de

horas de desarrollo.
Las establece el cliente.
Son la base para las pruebas funcionales.

27

UNTECS - Manuel Alcntara R.

Historias (Relatos) de Usuario

Una Historia de usuario es un relato acerca de qu problema debe resolver el

28

sistema.
Cada relato se escribe en una tarjeta y representa una parte de la funcionalidad
que es coherente para el cliente.
Son escritos por el cliente o usuario, con la ayuda de los desarrolladores, para
permitir estimar los tiempos y asignar prioridades.
Los clientes ayudan a asegurar que la mayora de la funcionalidad deseada para el
sistema est cubierta con las historias.
Constan de 3 4 lneas escritas por el cliente en un lenguaje no tcnico sin
hacer mucho hincapi en los detalles.
No se debe hablar ni de posibles algoritmos para su implementacin.
No se debe considerar los diseos de base de datos, etc.

UNTECS - Manuel Alcntara R.

Ejemplo de Historia de Usuario

Historia de Usuario
Nmero: 1 Nombre: Enviar artculo
Usuario: Autor
Modificacin de Historia Nmero: Iteracin Asignada: 2
Prioridad en Negocio: Alta
Puntos Estimados:
(Alta / Media / Baja)
Riesgo en Desarrollo:
Puntos Reales:
(Alto / Medio / Bajo) : Alto
Descripcin:
Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos) y de
los autores (nombre, e-mail, afiliacin). Uno de los autores debe indicarse como
autor de contacto. El sistema confirma la correcta recepcin del artculo enviando un
e-mail al autor de contacto con un usuario y clave para que el autor pueda
posteriormente acceder al artculo.

Spike para Historia de Usuario

30

UNTECS - Manuel Alcntara R.

Tarea de Ingeniera

Tarea
Nmero tarea:

Nmero historia:

Nombre tarea:
Tipo de tarea :
Puntos estimados:

Desarrollo / Correccin / Mejora / Otra

Fecha inicio:
Programador responsable:
Descripcin:

Fecha fin:

Prueba de Aceptacin
Caso de Prueba
Nmero Caso de Prueba:
Nombre Caso de Prueba:
Descripcin:

Condiciones de ejecucin:

Entradas:

Resultado esperado:
Evaluacin:

Nmero Historia de Usuario:

Prcticas XP
El juego de la
planificacin
Entregas pequeas
Metfora
Diseo simple
Pruebas
Refactoring

33

UNTECS - Manuel Alcntara R.

Programacin en parejas
Propiedad colectiva
Integracin continua

Semana de 40 horas
Cliente in situ

Estndares de programaci

Escenarios en XP : Exploracin
?

Historias de Usuario
Prioridad

Riesgo
Esfuerzo (puntos)

Definir
Historias
de Usuario

Elaborar
Spikes

34

UNTECS - Manuel Alcntara R.

Spikes (Bosquejos)

Estimar Esfuerzo
y Riesgo

Escenarios en XP:
Planificacin de la Entrega
Velocidad de
Proyecto (VP)
puntos/semana
Historias
de Usuario
Primera
Iteracin

Segunda
Iteracin

N-sima
Iteracin

2a3
semanas
35

UNTECS - Manuel Alcntara R.

Entrega
<= 3 meses

ltima
Iteracin

Historias
fuera de la
entrega

Escenarios en XP :
Comenzar Iteracin

Historias de la
Iteracin

Definir y
ordenar
Tareas de
Ingeniera

Tareas de
la iteracin
36

UNTECS - Manuel Alcntara R.

Escenarios en XP :
Programacin

Historias de la
Iteracin
Tareas de
Historias de
la iteracin
Programacin
en Parejas

37

Versin del
Producto

UNTECS - Manuel Alcntara R.

Diseo
Refactoring
Programacin
Pruebas Unitarias
Integracin
Pruebas de Integracin
Pruebas de Aceptacin

Pruebas de
Aceptacin
de Historias
de la iteracin

Escenarios en XP :
Pruebas de Aceptacin

Definir Pruebas
de Aceptacin

Pruebas de
Aceptacin

Corregir errores
Definir nuevas Historias
Aplicar Pruebas
de Aceptacin
38

UNTECS - Manuel Alcntara R.

Entorno y clima de trabajo

Espacio de trabajo XP
Espacio abierto
Mesas centrales
Cubculos en el espacio exterior

Espacio de trabajo
del proyecto C3 de
DaimlerChrysler

39

UNTECS - Manuel Alcntara R.

 Entorno y clima de trabajo

Reunin diaria XP
Reunin diaria: Stand-up Meeting
Todo el equipo
Problemas
Soluciones

De pie en un crculo
Evitar discusiones largas
Sin conversaciones separadas

40

UNTECS - Manuel Alcntara R.

Entorno y clima de trabajo

Gantt de Pared

Centro del universo del proyecto

Punto de reunin para la Stand-up Meeting
Obtenida de www.agiletek.com

41

UNTECS - Manuel Alcntara R.

XP en la prctica (i)
Retroalimentacin a escala fina:
Desarrollo guiado por pruebas
Planificacin iterativa
Cliente como parte del equipo
Programacin en pares

Proceso continuo:
Integracin continua
Refactorizacin
Liberacin pequea, entregas frecuentes

42

UNTECS - Manuel Alcntara R.

XP en la prctica (ii)
Entendimiento compartido:
Diseo simple

Metforas del sistema

Propiedad colectiva del cdigo
Estndares de codificacin

Bienestar del programador:

Ritmo sostenible (Semanas de 40 horas)

43

UNTECS - Manuel Alcntara R.

Diseo simple
El diseo debe ser lo ms simple posible: no introducir

estructura, ni funcionalidad antes de tiempo.

Se puede aadir complejidad ms adelante.
Inconveniente: Vencer la tendencia al gran diseo previo

44

UNTECS - Manuel Alcntara R.

Pruebas automatizadas (i)

Todo cdigo que puede fallar debe tener una prueba.
Hacer la prueba an antes de la implementacin.
Inconveniente: Obliga a imponer una forma de trabajar y puede

ser necesaria formacin/experiencia.

Dos tipos: Prueba de Unidad (o del Programador) y Prueba de
Aceptacin (o Funcional, o del Cliente).
La Prueba de Aceptacin es una prueba formal conducida para
determinar si un sistema satisface los criterios de aceptacin y
permite al cliente determinar si acepta o no el sistema.

45

UNTECS - Manuel Alcntara R.

Pruebas automatizadas (ii)

Para cada lenguaje de programacin hay herramientas de Prueba

de Unidad que permiten automatizar la ejecucin de las mismas,

como JUnit para Java. (ver
http://www.xprogramming.com/software.htm)
Frecuentemente una Prueba de Unidad es mejor que un
comentario para ayudar a entender por qu una determinada
funcin es necesaria, para demostrar cmo es llamada una funcin
y cuales son los resultados esperados, y para documentar defectos
en versiones previas del programa que queremos asegurarnos de
que no vuelvan.

46

UNTECS - Manuel Alcntara R.

Integracin continua
Todos los cambios deben ser integrados a la base del

cdigo al menos diariamente.

Las pruebas deben correr al 100% antes y despus de la
integracin.
Cada nueva versin debe tener la mnima funcionalidad
extra que tiene sentido.
Encaja con release early, release often
Ventajas: tener realimentacin de los usuarios y ofrecer
pronto nueva funcionalidad (+xito).

47

UNTECS - Manuel Alcntara R.

Programacin en pares
La Programacin en Pares requiere que dos desarrolladores participen en un

proyecto en una misma estacin de trabajo.

Cada miembro lleva a cabo la accin que el otro no est haciendo en ese
momento: Mientras uno redacta Pruebas de Unidad el otro piensa acerca de la
clase que satisfar a dicha prueba, por ejemplo.
Los estudios demuestran que, tras aprender Habilidades Personales dos
programadores son ms que doblemente productivos que uno slo para una
tarea determinada.

UNTECS - Manuel Alcntara R.

48

Refactorizacin (i)
Es una tcnica disciplinada de

reestructurar cualquier cdigo

existente, alterando su
estructura interna sin modificar
su comportamiento externo.

49

UNTECS - Manuel Alcntara R.

Si su software fuera un
edificio, se parecera mas a
uno de la izquierda o de la
derecha?

Refactorizacin (ii)
Si un programa funciona pero est mal diseado, pronto surgirn problemas a la hora

de actualizarlo. Los problemas ms comunes pueden ser catalogados como olor de

cdigo (ya que la acumulacin de los mismos provocan que el cdigo apeste).
Existen listas de refactorizaciones. Ejemplo:

Add Parameter
A method needs more information from its caller.

Add a parameter for an object that can pass on this information.

50

UNTECS - Manuel Alcntara R.

ltimas ideas
El mtodo de desarrollo empleado por la programacin extrema y el que suele

llevarse a cabo en la generacin de Software Libre tienen grandes parecidos.

Hay algunas prcticas de la programacin extrema que no se usan de manera
mayoritaria (pruebas de unidad y de aceptacin, metfora y refactorizacin) y
que son muy interesantes y provechosas.
XP y bases de datos: cuidar que tanto BDs relacionales como orientadas al
objeto sean flexibles, de manera de migrar fcilmente los datos en caso de
cambios.
En cuanto al lanzamiento de cada mini-versin, usar una estacin de integracin
que permite a los desarrolladores observar quin y cundo se est realizando,
manteniendo estabilidad en el sistema.

51

UNTECS - Manuel Alcntara R.

Referencias
http://www.extremeprogramming.org/
http://www.programacionextrema.org/
http://www.jera.com/techinfo/xpfaq.html
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
http://clabs.org/caseforxp.htm
http://ootips.org/xp.html
http://www.bobjectsinc.com/cstug/xpslides/
http://www.xp123.com/
http://c2.com/cgi/wiki?XpGlossary

52

UNTECS - Manuel Alcntara R.

Conclusiones
Apostolado de metodologas exitosas

Aporte de la experiencia prctica a los modelos tericos

Enfoque de conjunto de prcticas como rompecabezas

Tecnologa en expansin
Importancia de revisitar las metodologas desde la

experiencia prctica

53

UNTECS - Manuel Alcntara R.

Referencias
K. Beck, Embracing change with Extreme Programing, Computer, Vol. 32, No. 5 Oct.

54

1999, pp 70-77
L. Williams, R. Kessler, W. Cunningham and R. Jeffries, Strenghthening the Case for
Pair Programing, IEEE Software, Vol. 17, No. 4 Jul/Aug 2000, pp 19-25
R. Martin, Extreme Programing Development through dialog, IEEE Software, Vol. 17,
No. 4 Jul/Aug 2000, pp 12-13
C3 Team, Chrysler goes to Extremes, Distributed Computing, Oct 1998, pp 24-28
http://www.xprogramming.com
http://www.extremeprogramming.org
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

UNTECS - Manuel Alcntara R.