¿ 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
REUSABILIDADde 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
SOLUCIONESDE 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
TARJETASCRC
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 CASODE TEST PRIMERO
caso de test primero
import randomimport 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
REFACTOREOSIN 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 UPMEETINGS
(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 SIEMPREDISPONIBLE COMO
MIEMBRO DEL EQUIPO
SEGUIR ESTANDARES
DE PROGRAMACION
INTEGRAR SEGUIDO
REPOSITORIO COLECTIVO DE CODIGO
INTEGRAR SEGUIDO
REPOSITORIO COLECTIVO DE CODIGO
SVN
NO OVERTIME
OPTIMIZAR ALULTIMO
CUANDO XP NO FUNCIONA
ARREGLAR Y DOCUMENTAR
IMPLEMENTACIONESCASERAS
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.