Introducción a la metodologia extreme programming

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

2. ¿ QUE ES XP ?

3. metodología de
desarrollo ágil

4. PROMESAS

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

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

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

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

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

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

11. CUANDO USAR XP

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

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

14. cuando...
desarrollo basado en
REUSABILIDAD
de componentes

15. 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

16. REQUERIMIENTOS

17. 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

18. 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

19. 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

20. ELEMENTOS
PRINCIPALES

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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

31. 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.

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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.

39. 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.

40. 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.

41. 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

42. 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

43. 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

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

45. 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

46. 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

47. 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

48. DESARROLLO
ITERATIVO

51. 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

52. 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

53. 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

54. 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

55. desarollo iterativo, regla
NUNCA AGREGAR UNA
FUNCIONALIDAD ANTES
DE TIEMPO

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

57. 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

58. 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

59. 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

60. SOLUCIONES
DE PUNTOS
(SPIKE SOLUTIONS)

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

62. TARJETAS
CRC

63. 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

64. ESCRIBIR CASO
DE TEST PRIMERO

66. 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()

67. 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

68. 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

69. 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

70. 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

71. 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.

72. 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.

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

76. CUANDO SE
ENCUENTRA UN
BUG

77. 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

78. TEST DE
ACEPTACION

79. 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

80. REFACTOREO
SIN PIEDAD

81. 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

82. PAIR
PROGRAMMING

83. 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

84. STAND UP
MEETINGS
(reuniones de pie)

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

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

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

89. GENERALIDADES

90. CLIENTE SIEMPRE
DISPONIBLE COMO
MIEMBRO DEL
EQUIPO

91. SEGUIR
ESTANDARES
DE PROGRAMACION

92. INTEGRAR SEGUIDO
REPOSITORIO
COLECTIVO
DE CODIGO

93. SVN
INTEGRAR SEGUIDO
REPOSITORIO
COLECTIVO
DE CODIGO

94. NO OVERTIME

95. OPTIMIZAR AL
ULTIMO

96. CUANDO XP
NO FUNCIONA
ARREGLAR Y
DOCUMENTAR

97. IMPLEMENTACIONES
CASERAS

98. 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

99. 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

100. 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

101. 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

102. 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

106. 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.

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