Extreme Programming

6,205 views

Published on

Introducción a la metodologia extreme programming

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,205
On SlideShare
0
From Embeds
0
Number of Embeds
109
Actions
Shares
0
Downloads
504
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Extreme Programming

  1. 1. menttes www.menttes.com Extreme Programming Roberto Allende rallende@menttes.com
  2. 2. ¿ QUE ES XP ?    
  3. 3. metodología de desarrollo ágil    
  4. 4. PROMESAS    
  5. 5. promesas... ● Orientada a la satisfacción del cliente Mejora el proceso de desarrollo en cuatro frentes: comunicación, simplicidad, feedback, coraje    
  6. 6. promesas... ● Orientada a la satisfacción del cliente ● Mejora el proceso de desarrollo en: comunicación, simplicidad y elegancia, feedback, coraje    
  7. 7. promesas... ● código que sea fácil de entender y extender red de tests automáticos productividad, menores costos simple y sencillo    
  8. 8. promesas... ● código que sea fácil de entender y extender ● conjunto de tests automáticos productividad, menores costos simple y sencillo    
  9. 9. promesas... ● código que sea fácil de entender y extender ● conjunto de tests automáticos ● productividad, menores costos simple y sencillo    
  10. 10. promesas... ● código que sea fácil de entender y extender ● conjunto de tests automáticos ● productividad, menores costos ● simple y sencillo    
  11. 11. CUANDO USAR XP    
  12. 12. cuando... ● cambios de requerimienos son constantes proyectos con un gran margen de riesgo    
  13. 13. cuando... ● cambios de requerimienos son constantes ● proyectos con un gran margen de riesgo    
  14. 14. cuando... desarrollo basado en REUSABILIDAD de componentes    
  15. 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. 16. REQUERIMIENTOS    
  17. 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. 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. 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. 20. ELEMENTOS PRINCIPALES    
  21. 21.    
  22. 22. elementos principales... ● user stories ● tarjetas crc ● escribir casos test antes de codificar ● refactoring    
  23. 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. 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. 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. 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. 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. 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    
  29. 29.    
  30. 30.    
  31. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 44. regla: HACER RELEASES FRECUENTES Y PEQUEÑOS (release earlier, release often)    
  45. 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. 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. 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. 48. DESARROLLO ITERATIVO    
  49. 49.    
  50. 50.    
  51. 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. 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. 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. 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. 55. desarollo iterativo, regla NUNCA AGREGAR UNA FUNCIONALIDAD ANTES DE TIEMPO    
  56. 56. desarollo iterativo, regla SIMPLICIDAD ES LA CLAVE mantener las cosas tan sencillas como sea posible, refactoring soluciona las consecuencias    
  57. 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. 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. 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. 60. SOLUCIONES DE PUNTOS (SPIKE SOLUTIONS)    
  61. 61. soluciones de puntos para encontrar soluciones técnicas y predecir duración, aislar el problema y solucionarlo fuera del contexto del sistema    
  62. 62. TARJETAS CRC    
  63. 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. 64. ESCRIBIR CASO DE TEST PRIMERO    
  65. 65.    
  66. 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. 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. 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. 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. 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. 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. 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. 73. caso de test primero NO SE PUEDE ENTREGAR CODIGO SIN POSEER Y APROBAR LOS CASOS DE TEST    
  74. 74.    
  75. 75.    
  76. 76. CUANDO SE ENCUENTRA UN BUG    
  77. 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. 78. TEST DE ACEPTACION    
  79. 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. 80. REFACTOREO SIN PIEDAD    
  81. 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. 82. PAIR PROGRAMMING    
  83. 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. 84. STAND UP MEETINGS (reuniones de pie)    
  85. 85. reuniones de pie el equipo se reune al inicio de todos los dias, y de pie forman un circulo    
  86. 86. reuniones de pie es mas eficiente tener breves reuniones donde todos estan obligados a atender, que muchas reuniones por separado    
  87. 87. reuniones de pie centradas en las necesidades de uno o mas desarrolladores y quienes pueden contribuir    
  88. 88.    
  89. 89. GENERALIDADES    
  90. 90. CLIENTE SIEMPRE DISPONIBLE COMO MIEMBRO DEL EQUIPO    
  91. 91. SEGUIR ESTANDARES DE PROGRAMACION    
  92. 92. INTEGRAR SEGUIDO REPOSITORIO COLECTIVO DE CODIGO    
  93. 93. SVN INTEGRAR SEGUIDO REPOSITORIO COLECTIVO DE CODIGO    
  94. 94. NO OVERTIME    
  95. 95. OPTIMIZAR AL ULTIMO    
  96. 96. CUANDO XP NO FUNCIONA ARREGLAR Y DOCUMENTAR    
  97. 97. IMPLEMENTACIONES CASERAS    
  98. 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. 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. 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. 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. 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    
  103. 103.    
  104. 104.    
  105. 105.    
  106. 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. 107. menttes www.menttes.com Muchas Gracias Roberto Allende rallende@menttes.com http://labs.menttes.com

×