menttes
www.menttes.com
Extreme Programming
Roberto Allende
rallende@menttes.com

¿ QUE ES XP ?

metodología de
desarrollo ágil

PROMESAS

promesas...
● Orientada a la satisfacción del
cliente
Mejora el proceso de
desarrollo en cuatro frentes:
comunicación, simplicidad,
feedback, coraje

promesas...
● Orientada a la satisfacción del
cliente
● Mejora el proceso de
desarrollo en:
comunicación, simplicidad y
elegancia, feedback, coraje

promesas...
● código que sea fácil de
entender y extender
red de tests automáticos
productividad, menores
costos
simple y sencillo

promesas...
● código que sea fácil de
entender y extender
● conjunto de tests automáticos
productividad, menores
costos
simple y sencillo

promesas...
● código que sea fácil de
entender y extender
● conjunto de tests automáticos
● productividad, menores
costos
simple y sencillo

promesas...
● código que sea fácil de
entender y extender
● conjunto de tests automáticos
● productividad, menores
costos
● simple y sencillo

CUANDO USAR XP

cuando...
● cambios de requerimienos
son constantes
proyectos con un gran
margen de riesgo

cuando...
● cambios de requerimienos
son constantes
● proyectos con un gran
margen de riesgo

cuando...
desarrollo basado en
REUSABILIDAD
de componentes

cuando...
aunque...
Extreme programming development
methodology has a real influence in Zope 3
development process. Automated testing is a
major strength of Zope 3.
http://wiki.zope.org/zope3/ZopeGuideIntroduction

REQUERIMIENTOS

requerimientos...
● equipos de 2 a 12 programadores
(aunque se reportaron éxitos en equipos de 30...)
Involucrar al cliente en el
equipo de desarrollo
Crear y correr tests de forma
automática

requerimientos...
● equipos de 2 a 12 programadores
(aunque se reportaron éxitos en equipos de 30...)
● involucrar al cliente en el
equipo de desarrollo
Crear y correr tests de forma
automática

requerimientos...
● equipos de 2 a 12 programadores
(aunque se reportaron éxitos en equipos de 30...)
● involucrar al cliente en el
equipo de desarrollo
● crear y correr tests de forma
automática

ELEMENTOS
PRINCIPALES

elementos principales...
● user stories
● tarjetas crc
● escribir casos test antes de codificar
● refactoring

planificación: user stories
similares a casos de uso pero:
● creadas para hacer estimaciones de tiempo
son breves y concretas, no son extensos
documentos
son escritas por el cliente en vocabulario del
cliente sin tecnicismos

planificación: user stories
similares a casos de uso pero:
● creadas para hacer estimaciones de tiempo
● son breves y concretas, no son extensos
documentos
son escritas por el cliente en vocabulario del
cliente sin tecnicismos

planificación: user stories
similares a casos de uso pero:
● creadas para hacer estimaciones de tiempo
● son breves y concretas, no son extensos
documentos
● son escritas por el cliente en vocabulario del
cliente y sin tecnicismos

planificación: user stories
similares a casos de uso pero:
● expresadas en términos de las necesidades del
cliente
duración sugerida: 1 a 3 semanas
definen los tests de aceptación

planificación: user stories
similares a casos de uso pero:
● expresadas en términos de las necesidades del
cliente
● duración sugerida: 1 a 3 semanas
definen los tests de aceptación

planificación: user stories
similares a casos de uso pero:
● expresadas en términos de las necesidades del
cliente
● duración sugerida: 1 a 3 semanas
● definen los tests de aceptación

planificación: plan de release
● ~80 user stories (± 20)
● Definido en una reunión en la que participan
técnicos y la gente de negocios.
Conjuntamente acordan el plan de entregas.

planificación: plan de release
1. El equipo de desarrollo estima la duración de
cada user story.
El cliente decide que user story posee mayor
importancia o prioridad
Se imprimen las user stories, se colocan las
tarjetas en una mesa y se agrupan formando
diferentes entregas

planificación: plan de release
1. El equipo de desarrollo estima la duración de
cada user story.
2. El cliente decide que user story posee mayor
importancia o prioridad
Se imprimen las user stories, se colocan las
tarjetas en una mesa y se agrupan formando
diferentes entregas

planificación: plan de release
1. El equipo de desarrollo estima la duración de
cada user story.
2. El cliente decide que user story posee mayor
importancia o prioridad
3. Se imprimen las user stories, se colocan las
tarjetas en una mesa y se agrupan formando
la próxima entrega

planificación: plan de release
● Las metas de cada entrega son lograr un
sistema usable, testeable, y entregado antes
de tiempo
Los planes se pueden fijar por tiempo o
alcance
Se emplea la velocidad de proyecto para
determinar tiempo o alcance

planificación: plan de release
● Las metas de cada entrega son lograr un
sistema usable, testeable, y entregado antes
de tiempo
● Los planes se pueden fijar por tiempo o
alcance
Se emplea la velocidad de proyecto para
determinar tiempo o alcance

planificación: plan de release
● Las metas de cada entrega son lograr un
sistema usable, testeable, y entregado antes
de tiempo
● Los planes se pueden fijar por tiempo o
alcance
● Se emplea la velocidad de proyecto para
determinar tiempo o alcance

planificación: plan de release
● Los lanzamientos son planeados antes de cada
iteración y no con anticipación
Los plazos deben ser los fijados en la reunión
de release. No se deben subestimar plazos.
En la reunión, el cliente, gestores de proyecto
y desarolladores tienen que negociar hasta
ponerse de acuerdo en el plan de release.

planificación: plan de release
● Los lanzamientos son planeados antes de cada
iteración y no con anticipación
● Los plazos deben ser los fijados en la reunión
de release. No se deben subestimar plazos.
En la reunión, el cliente, gestores de proyecto
y desarolladores tienen que negociar hasta
ponerse de acuerdo en el plan de release.

planificación: plan de release
● Los lanzamientos son planeados antes de cada
iteración y no con anticipación
● Los plazos deben ser los fijados en la reunión
de release. No se deben subestimar plazos.
● En la reunión, el cliente, gestores de proyecto
y desarolladores tienen que negociar hasta
ponerse de acuerdo en el plan de release.

planificación: plan de release
● Las user stories de un plan son traducidas a
tareas que deben ser implementadas
Las user stories también son traducidas en
test de aceptación
Si el proyecto va muy rápido de acuerdo al
plan, se reunen todos en una nueva reunión de
release y se define un nuevo plan

planificación: plan de release
● Las user stories de un plan son traducidas a
tareas que deben ser implementadas
● Las user stories también son traducidas en
test de aceptación
Si el proyecto va muy rápido de acuerdo al
plan, se reunen todos en una nueva reunión de
release y se define un nuevo plan

planificación: plan de release
● Las user stories de un plan son traducidas a
tareas que deben ser implementadas
● Las user stories también son traducidas en
test de aceptación
● Si el proyecto va muy rápido de acuerdo al
plan, se reunen todos en una nueva reunión de
release y se define un nuevo plan

regla:
HACER RELEASES
FRECUENTES Y PEQUEÑOS
(release earlier, release often)

planificación: velocidad de proyecto
● Mide cuanto del trabajo está hecho p/release
Total de user stories terminadas p/release
Total de tareas terminadas p/release

planificación: velocidad de proyecto
● Mide cuanto del trabajo está hecho p/release
● Total de user stories terminadas p/release
Total de tareas terminadas p/release

planificación: velocidad de proyecto
● Mide cuanto del trabajo está hecho p/release
● Total de user stories terminadas p/release
● Total de tareas terminadas p/release

DESARROLLO
ITERATIVO

desarollo iterativo
● Dividir agenda de proyecto en iteraciones
de 1 a 3 semanas de duración
(~12 iteraciones p/proyecto)
Mantener duración de iteraciones constantes
a lo largo de todo el proyecto
No agendes tareas de programación con
anticipación
SE PROHIBE IMPLEMENTAR ALGO QUE NO ES
REQUERIDO EN LA ITERACION ACTUAL

desarollo iterativo
● Dividir agenda de proyecto en iteraciones
de 1 a 3 semanas de duración
(~12 iteraciones p/proyecto)
● Mantener duración de iteraciones constantes
a lo largo de todo el proyecto
No agendes tareas de programación con
anticipación
SE PROHIBE IMPLEMENTAR ALGO QUE NO ES
REQUERIDO EN LA ITERACION ACTUAL

desarollo iterativo
● Dividir agenda de proyecto en iteraciones
de 1 a 3 semanas de duración
(~12 iteraciones p/proyecto)
● Mantener duración de iteraciones constantes
a lo largo de todo el proyecto
● No agendes tareas de programación con
anticipación
SE PROHIBE IMPLEMENTAR ALGO QUE NO ES
REQUERIDO
EN LA ITERACION ACTUAL

desarollo iterativo
● Dividir agenda de proyecto en iteraciones
de 1 a 3 semanas de duración
(~12 iteraciones p/proyecto)
● Mantener duración de iteraciones constantes
a lo largo de todo el proyecto
● No agendes tareas de programación con
anticipación
● SE PROHIBE IMPLEMENTAR CUALQUIER COSA
QUE NO SEA REQUERIDA EN LA ITERACION
ACTUAL

desarollo iterativo, regla
NUNCA AGREGAR UNA
FUNCIONALIDAD ANTES
DE TIEMPO

desarollo iterativo, regla
SIMPLICIDAD ES LA
CLAVE
mantener las cosas
tan sencillas como sea posible,
refactoring soluciona las consecuencias

desarollo iterativo
● Tomar en serio los plazos de cada iteración y
si es necesario renegociar fechas de entrega.
● Concentrar esfuerzos en completar tareas mas
importantes para el cliente

planificación de iteraciones
Está formado por:
● User stories seleccionadas por el cliente
ordenadas en importancia
● Tests de aceptación que fallaron, se
convierten en tareas

planificación de iteraciones
● Cada tarea debería tener una duración
aproximada de entre 1 a 3 días
● El desarrollador que estima, es el que
implementa la tarea

SOLUCIONES
DE PUNTOS
(SPIKE SOLUTIONS)

soluciones de puntos
para encontrar soluciones
técnicas y predecir duración,
aislar el problema y
solucionarlo
fuera del contexto del sistema

TARJETAS
CRC

tarjetas crc
● CRC Clases, responsabilidad, colaboración
● Son tarjetas que permiten diseñar el
sistema como si fuera un equipo
● Se sugiere que muchas personas trabajen en
el diseño

ESCRIBIR CASO
DE TEST PRIMERO

caso de test primero
import random
import unittest
class TestSequenceFunctions(unittest.TestCase):
def setUp(self):
self.seq = range(10)
def testshuffle(self):
# make sure the shuffled sequence does not lose any elements
random.shuffle(self.seq)
self.seq.sort()
self.assertEqual(self.seq, range(10))
def testchoice(self):
element = random.choice(self.seq)
self.assert_(element in self.seq)
def testsample(self):
self.assertRaises(ValueError, random.sample, self.seq, 20)
for element in random.sample(self.seq, 5):
self.assert_(element in self.seq)
if __name__ == '__main__':
unittest.main()

caso de test primero
● Facilita la codificación -> fuerza al
programador que tiene que hacer antes de
escribir código
Define el alcance de cada funcionalidad,
sabiendo con precisión cuando se ha
terminado y se posee un test para asegurarlo
Solo se va a implementar lo que satisface el
test
Otros programadores pueden aprender sobre
el código viendo los casos de test

caso de test primero
● Facilita la codificación -> fuerza al
programador que tiene que hacer antes de
escribir código
● Define el alcance de cada funcionalidad,
sabiendo con precisión cuando se ha
terminado y se posee un test para asegurarlo
Solo se va a implementar lo que satisface el
test
Otros programadores pueden aprender sobre
el código viendo los casos de test

caso de test primero
● Facilita la codificación -> fuerza al
programador que tiene que hacer antes de
escribir código
● Define el alcance de cada funcionalidad,
sabiendo con precisión cuando se ha
terminado y se posee un test para asegurarlo
● Solo se va a implementar lo que satisface el
test
Otros programadores pueden aprender sobre
el código viendo los casos de test

caso de test primero
● Facilita la codificación -> fuerza al
programador que tiene que hacer antes de
escribir código
● Define el alcance de cada funcionalidad,
sabiendo con precisión cuando se ha
terminado y se posee un test para asegurarlo
● Solo se va a implementar lo que satisface el
test
● Otros programadores pueden aprender sobre
el código viendo los casos de test

caso de test primero
● El tiempo que se ahorra al escribir un caso de
test se paga muchas veces mas durante el
desarollo de un sistema sin casos de test.
Arreglar pequeños problemas varias veces al
día toma mucho menos tiempo que arreglar
grandes problemas momentos previos a la
entrega.

caso de test primero
● El tiempo que se ahorra al escribir un caso de
test se paga muchas veces mas durante el
desarollo de un sistema sin casos de test.
● Arreglar pequeños problemas varias veces al
día toma mucho menos tiempo que arreglar
grandes problemas momentos previos a la
entrega.

caso de test primero
NO SE PUEDE ENTREGAR
CODIGO SIN POSEER Y
APROBAR LOS CASOS DE
TEST

CUANDO SE
ENCUENTRA UN
BUG

cuando se encuentra un bug
● Se escribe el caso de test que lo detecta
● Se agrega a la proxima iteración
● Se soluciona el bug
● Se prueba la solución corriendo el test

TEST DE
ACEPTACION

test de aceptación
● Creado en el momento en que se definen las
user stories
● Diferentes escenarios de una user stories y
sus resultados asociados
● User story no está completa hasta que paso
el test de aceptación

REFACTOREO
SIN PIEDAD

refactoreo sin piedad
● quitar redundancias, eliminar funcionalidades
sin usar, actualizar diseños obsoletos de modo
que el código sea fácil de entender, modificar
y extender
● refactorización ahorra tiempo e incrementa
calidad

PAIR
PROGRAMMING

pair programming
● Evita dependencia de conocimiento y
cuellos de botella
● Induce el entrenamiento cruzado
● El equipo es mas flexible si todos conocen el
las partes del sistema

STAND UP
MEETINGS
(reuniones de pie)

reuniones de pie
el equipo se reune al inicio de
todos los dias, y de pie
forman un circulo

reuniones de pie
es mas eficiente tener breves
reuniones donde todos estan
obligados a atender, que
muchas reuniones por
separado

reuniones de pie
centradas en las necesidades
de uno o mas desarrolladores y
quienes pueden contribuir

GENERALIDADES

CLIENTE SIEMPRE
DISPONIBLE COMO
MIEMBRO DEL
EQUIPO

SEGUIR
ESTANDARES
DE PROGRAMACION

INTEGRAR SEGUIDO
REPOSITORIO
COLECTIVO
DE CODIGO

SVN
INTEGRAR SEGUIDO
REPOSITORIO
COLECTIVO
DE CODIGO

NO OVERTIME

OPTIMIZAR AL
ULTIMO

CUANDO XP
NO FUNCIONA
ARREGLAR Y
DOCUMENTAR

IMPLEMENTACIONES
CASERAS

implementaciones
● listas de correo, dev y proyecto c/cliente
extreme managemente (producto plone)
comunicación con el cliente (telefono)
stand up meetings semanales (irc / voip)
toda disponibilidad posible del equipo
en una sala común vía irc

implementaciones
● listas de correo, dev y proyecto c/cliente
● extreme managemente (producto plone)
comunicación con el cliente (telefono)
stand up meetings semanales (irc / voip)
toda disponibilidad posible del equipo
en una sala común vía irc

implementaciones
● listas de correo, dev y proyecto c/cliente
● extreme managemente (producto plone)
● comunicación con el cliente (telefono)
stand up meetings semanales (irc / voip)
toda disponibilidad posible del equipo
en una sala común vía irc

implementaciones
● listas de correo, dev y proyecto c/cliente
● extreme managemente (producto plone)
● comunicación con el cliente (telefono)
● stand up meetings semanales (irc / voip)
toda disponibilidad posible del equipo
en una sala común vía irc

implementaciones
● listas de correo, dev y proyecto c/cliente
● extreme managemente (producto plone)
● comunicación con el cliente (telefono)
● stand up meetings semanales (irc / voip)
● toda disponibilidad posible del equipo
en una sala común vía irc

ultima página
● la gente es tu recurso mas preciado
● como comenzar:
www.extremeprogramming.org
-> how to start
● Extreme Programming Exaplined
Kent Beck et.al.

menttes
www.menttes.com
Muchas Gracias
Roberto Allende
rallende@menttes.com
http://labs.menttes.com