eXtreme Programming y los métodos ágiles (2001)

79,024 views

Published on

Published in: Technology

eXtreme Programming y los métodos ágiles (2001)

  1. 1. Agile Methods y eXtreme Programming Javier Garzás jgarzas@altransdb.com jgarzas@acm.org Madrid, 11 de junio de 2001
  2. 2. De Nada a lo Monumental y a lo Ágil  La mayoría del desarrollo software actual se caracteriza por…  Actividad Caótica  “Code and Fix” Esto no funciona en proyectos grandes Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  3. 3. De Nada a lo Monumental y a lo Ágil  La Metodología: ­ Nace para solucionar los problemas anteriores ­ Produce disciplina ­ Mas predecible Todo resuelto … (¿Seguro?) ­ Más eficiente Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  4. 4. De Nada a lo Monumental y a lo Ágil Principal crítica: Burocracia: tantas cosas que desarrollar que la velocidad de desarrollo baja. Por lo anterior se les denomina “Metodologías pesadas (hightweight)” o “Metodologías Monumentales” (J. Highsmith). Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  5. 5. De Nada a lo Monumental y a lo Ágil Para reaccionar al anterior problema aparecen otras metodologías, denominadas “Metodologías de peso ligero” y ahora “Metodologías Ágiles” Reacción ante la burocracia. Compromiso entre el no proceso y el proceso monumental. No están orientadas por la documentación, enfatizan poca documentación. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  6. 6. Diferencias entre lo Pesado y lo Ágil Pesados Ágiles Predictivos Adaptativos Orientados al proceso Orientados a la gente Trabajan bien hasta que cambian las cosas, su naturaleza es restringir el cambio. Bienvenido el cambio, adaptación y evolución en el cambio. Plan largo y documental Plan corto y casi sin documentos Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  7. 7. El error de lo predecible
  8. 8. Error 1: Separación de Diseño y Construcción  La inspiración inicial partió de las ingenierías clásicas (mecánica, civil, etc.): ­ Enfatizan la planificación antes de la construcción. ­ Planos precisos. ­ La construcción tiene poca destreza intelectual y más manual, por tanto existen dos actividades diferenciadas: el diseño y la construcción (fácil de predecir).  Está es la aproximación de muchas metodologías software ­ El diseño pretende controlar la implementación ­ En software las notaciones de diseño, como UML, pretenden hacer todas las decisiones de diseño y construir un plan de construcción Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  9. 9. Cuestiones cruciales  ¿Se puede conseguir un diseño capaz de poder moldear la codificación en la actividad de construcción?  ¿Cómo de difícil es conseguir un diseño UML en un estado para poder pasarse a los programadores?  El diseño UML puede ser correcto en papel, pero erróneo para la codificación.  A los diseños mecánicos no les sucede esto pues están soportados por las matemáticas.  Además, en software, el tiempo (coste) de codificación es menor al de diseñar, esto no ocurre en otras ingenierías Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  10. 10. Conclusiones  En Software el diseño requiere creatividad y talento.  Los procesos creativos no son fáciles de planificar,  La predictibilidad puede ser imposible. Deberíamos ser muy cuidadosos a la hora de hacer símiles entre ingenierías clásicas e ingeniería del software. Son actividades diferentes y requieren procesos diferentes Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  11. 11. Error 2: Lo impredecible de los requisitos  Comprender los requisitos es duro  Uno de los motivos es la naturaleza intangible del software: sólo cuando se usa una primera versión se comprende qué es valioso y qué no lo es  Si esperásemos a tener un conjunto de requisitos estables estaríamos muertos  Economía, principal fuerza del negocio  Buenos requisitos ahora no lo serán mañana  Algunos requisitos de negocios son impredicibles Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  12. 12. Error 2: Lo impredecible de los requisitos Si los requisitos no son estables… ¡No se puede predecir un plan! Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  13. 13. Cómo controlar un proceso impredecible  Entonces, si no tiene sentido un proceso predecible… ¿cómo controlar? ­ Lo más difícil es saber dónde estamos. ­ Necesitamos un mecanismo de feedback que nos diga donde estamos a intervalos frecuentes, ­ la clave de este feedback es el desarrollo iterativo (esto no es nuevo, ha tenido muchos nombres, espiral, evolucional, incremental, etc.). ­ Producir versiones de trabajo con un subconjunto de las características requeridas. ­ Cómo de largas son las iteraciones: En XP de 1 a 3 semanas, en SCRUM un mes, etc. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  14. 14. El mito de la metodología única
  15. 15. Mito: "A methodology per project"  Son necesarias múltiples metodologías dependiendo del tamaño del proyecto (gente a coordinar), lo crítico del sistema y las prioridades del proyecto.  Cada proyecto merece su propia metodología y a medida.  “Peso ligero” y comunicación cara a cara son atributos deseables. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  16. 16. 4 principios en el diseño de una metodología  Grandes metodologías para grandes equipos.  Densas metodologías para los proyectos más críticos.  El peso es costoso.  La comunicación interactiva y cara a cara es la más efectiva. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  17. 17. Una metodología precisa un alcance definido Roles Ac tiv iti es rest and recreation vacations and basic business technical education timesheets project development project sponsor project manager expert user business expert lead designer UI expert reuse point designer/programmer tester writer trainer secretary contractor night watchman janitor envisioning proposal sales setup requirements design & code test deploy train alter Project Lifecycle Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  18. 18. Metodología, seleccionar en función de… Criticality (defects cause loss of...) . . . Prioritized for Legal Liability Prioritized for Productivity & Tolerance Life (L) L6 L20 L40 L100 L200 L500 L1000 Essential money (E) E6 E20 E40 E100 E200 E500 E1000 Discretionary money D6 (D) D20 D40 D100 D200 D50 D1000 C20 C40 C100 C200 C500 C1000 Comfort (C) C6 1-6 XP - 20 - 40 - 100 Number of people - 200 - 500 - 1,000 involved +20% Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  19. 19. Errores estándars 1. Sólo un tamaño de metodología… los proyectos varían 2. Metodología intolerante… la gente varía 3. Embellecer 4. Pesado… menos escribir 5. No probada Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  20. 20. Principales metodologías Ágiles  XP (Extreme Programming)  Crystal Family  Adaptive Software Development  SCRUM  Feature Driven Development  DSDM (Dynamic System Development Method) Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  21. 21. eXtreme Programming
  22. 22. Definición  XP es una deliberada y disciplinada aproximación light al desarrollo software  Formada por pequeñas reglas o guidelines que juntas crean una nueva disciplina de desarrollo  Principal autor: ­ Kent Beck  Proyecto origen: ­ “Chrysler Comprehensive Compensation” (C3), iniciado en 1990 y convertido a XP en 1997. Para el salario de 10000 empleados Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  23. 23. “XP es el movimiento más importante hoy en nuestro campo. Predigo que será tan esencial para la presente generación como el SEI y su CMM lo fueron en el pasado” Tom DeMarco Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  24. 24. La polémica XP  XP cambia las asunciones comunes sobre el desarrollo software  NO al desarrollo up­front (Análisis, Diseño, etc.)  NO escribir y mantener documentación  NO a los CASEs  NO a las técnicas de diseño cómo UML, principios y patrones  Para sus detractores es volver al “code and fix” Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  25. 25. La asunción fundamental de XP y el error de un proceso predecible
  26. 26. La curva del coste : cambio de asunción  La histórica curva del cambio Cambio cuando hay un error Los métodos tradicionales se han centrado en la prevención de errores en fases tempranas Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  27. 27. La curva del coste: cambio de asunción  El diseño anticipado (antes de codificar) ­ crea facilidades extra para anticipar futuros requisitos (cambios) ­ Invertir tiempo presente para tiempo futuro. ­ Asume que un poco de tiempo ahora ahorrará mucho después Pero, pudiera ser más rápido diseñar después (rediseñar el código), cuando ya sabemos de verdad que es lo que hay que cambiar y no tenemos que adivinarlo Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  28. 28. La curva del coste: cambio de asunción  La nueva curva del cambio En los entornos de hoy NO podemos prevenir lo que no conocemos Los cambios aparecen iterativamente Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  29. 29. La curva del coste: cambio de asunción  Diseñar después…Rediseñar…Refactoring  Refactoring: “cambio hecho a la estructura interna del software para hacerlo más fácil de entender y más barato de modificar sin cambiar su comportamiento observable” (Fowler)  Si los cambios son continuos nunca completaremos un desarrollo software tradicional  ¡¡Cuánto más impredecibles sean los cambios más diseño anticipado derrocharemos!! Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  30. 30. La curva del coste: cambio de asunción  Era pre­Internet: Ratio de cambio bajo Más Anticipatory Design que Refactoring puede ser razonable Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  31. 31. La curva del coste: cambio de asunción  En la actualidad Ratio de cambio alto Se impone el diseño a posteriori, el Refactoring Según esta idea el Diseño (UML) pierde sentido Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  32. 32. Sobre la Planificación / Gestión de proyectos XP (Planning XP)
  33. 33. La idea subyacente en XP: Riesgo El problema básico del desarrollo software es el RIESGO  El calendario varía: “el software no estará hasta dentro de 6 meses”  Proyecto cancelado.  Ratio de defectos: tantos defectos que el software deja de usarse  Incomprensión del negocio: el software es puesto en producción pero no soluciona el problema de negocio para el que se propuso  Rotación de personal: los programadores empiezan a odiar el programa y se van Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  34. 34. La idea subyacente en XP: Riesgo “El desarrollo software falla en las entregas, y falla al entregar valor. Este fallo tiene terrible impacto económico y humano. Necesitamos otra manera de desarrollar software” Kent Beck Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  35. 35. XP, el Miedo El desarrollo software es un riesgo. La gente involucrada tiene miedo de lo que pueda salir mal. Para desarrollar eficientemente necesitamos reconocer ese miedo  Debido al miedo debe imponerse un proceso software Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  36. 36. Explicitación de los miedos Miedos del Cliente Miedos del Desarrollador No conseguir lo que pidieron Se les pedirá más de lo que saben hacer De pedir algo equivocado Se les pedirán cosas sin sentido Pagar demasiado De ser muy estúpidos A técnicas que no controlan Caer por la técnica Nunca ver un plan significativo Tomar responsabilidad sin autoridad No saber que ocurre Definiciones no claras No poder rehacer sus decisiones Sacrificar calidad por plazos No saber la verdad Solucionar problemas complejos sin ayuda No tener tiempo para finalizar con éxito Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  37. 37. El cliente tiene derecho a…  un plan general, a saber qué puede realizarse, cuándo y a qué coste.  conseguir el mayor valor posible de cada semana de programación  ver la evolución en un sistema ejecutable,  cambiar de opinión, sustituir funcionalidad, y cambiar prioridades sin pagar un coste exagerado  ser informado de cambios en la agenda, en tiempo para escoger como reducir el alcance para retornar a la fecha original.  Puede cancelar en cualquier momento y quedarse con un sistema que trabaje de forma útil que refleje la inversión hasta la fecha. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  38. 38. El programador tiene derecho a…  saber lo que es necesario, con claras declaraciones de prioridad  producir trabajo de calidad en todo momento.  pedir y recibir ayuda de iguales, managers y clientes.  hacer y modificar sus propias estimaciones.  aprobar sus responsabilidades en vez de que sean asignadas. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  39. 39. Las cuatro variables  Para controlar un proyecto software existen cuatro variables:  Coste  Tiempo  Calidad  Alcance Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  40. 40. El proceso de desarrollo XP
  41. 41. Los cuatro valores  Comunicación: ­ XP enfoca construir persona a persona, mutua comprensión del entorno del problema mediante mínima información documental y máxima interacción cara a cara  Simplicidad ­ Hacer las cosas lo más simple posibles ­ YAGNI (You aren’t going need it) ­ Trabajar en una cosa errónea temprano es más derrochador que trabajar en la solución correcta después ­ Diseño complejo = dificil de entender = dificil de modificar ­ Según esto… ¿los patrones no tienen sentido? Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  42. 42. Los cuatro valores  Feedback ­ La aceptación del cambio ocurre por el constante feedback ­ Feedback vs feedforward  Coraje Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  43. 43. Las 12 prácticas  Planning Game: Tres semanas por ciclo y asignando historias (características requeridas)  Small release: los más pequeñas y con el mayor valor de negocio  Metaphor: descripción general del proyecto Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  44. 44. Las 12 prácticas  Diseño simple: ­ Diseñar sólo la funcionalidad requerida, NADA de futura funcionalidad ­ Crear el diseño que mejor pueda comunicar esa funcionalidad ­ “Si el futuro es incierto y puedes cambiar tus pensamientos fácilmente entonces poner funcionalidad especulante es de locos”  Refactoring: ­ El rediseño continuo mejora la respuesta al cambio  Testing Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  45. 45. Las 12 prácticas  Pair Programming  Posesión colectiva: ­ Cualquiera del proyecto puede cambiar cualquier código en cualquier momento  Integración Continua  40 horas por semana: ­ “Don´t burn out the troops” (Hightsmit) ­ No más de una semana con sobre tiempo Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  46. 46. Las 12 prácticas  On­site Customer  Coding standars Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  47. 47. El ciclo XP Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  48. 48. El ciclo XP Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  49. 49. El ciclo XP Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  50. 50. El ciclo XP Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  51. 51. Valores y prácticas “El éxito de XP no vendrá sólo de cosas como el pair programming o 40 hour work for week, dependerá de que principios y valores se alineen con la organización” Jim Hightsmit Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  52. 52. ¿Son los patrones 23 errores en XP?  La esencia de este argumento es que los patrones son con frecuencia sobre usados.  Son buenas ideas, el problema está en su mal uso.  XP puede tratar de otra forma el uso de patrones pero no los elimina.  Los patrones son de vital importancia. Los patrones son las espina dorsal del conocimiento de diseño, tan importante como pueda serlo el proceso.  Diferentes procesos pueden enfocar el uso de patrones de diferente manera. XP enfatiza no usar patrones hasta que sea necesario. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  53. 53. ¿XP contra UML?  Slogan XP: ­ “Úselo si es útil” con el sub­texto “Xper no hacen diagramas” ¡¿Ya no tiene sentido el uso de UML?! Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  54. 54. XP y UML  El problema tiene dos causas: ­ Algunas personas encuentran útiles los diagramas software, otras no. Esto debe ser aceptado. ­ Diagramas software tienden a asociarse con procesos pesados que gastan mucho tiempo dibujando diagramas que no ayudan y que pueden ser dañinos. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  55. 55. Cómo usar bien los diagramas  Dibujar diagramas para una comunicación efectiva: ­ Seleccionar las cosas importantes y pasar por alto cosas menos importantes:  Un problema común con los diagramas es que la gente tiende ha hacerlos comprensivos. El código es la mejor fuente de información comprensiva.  Cambiar el diseño no implica necesariamente cambiar los diagramas.  Es razonable el dibujar diagramas para comprender el diseño y después tirarlos. Los diagramas no pueden ser artefactos. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  56. 56. ¿XP contra los CASEs?  Otro uso de diagramas UML es la documentación, que generalmente reside en un CASE.  La idea es que mantener esta documentación ayuda a la gente a trabajar en el sistema.  Esto en la práctica no funciona: ­ Demasiado grandes para actualizarse, mala sincronización con el código. ­ Quedan ocultos en el CASE y nadie los mira. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  57. 57. ¿Está muerto el Diseño?  NO, pero su naturaleza a cambiado. En XP el diseño: ­ Deseo constante por mantener el código lo más claro posible. ­ Refactoring permite hacer las mejoras necesarias de forma confiada ­ Buen conocimiento de patrones: no sólo las soluciones, también cuando usarlos y cómo evolucionan ­ Conocer cómo comunicar el diseño a quien necesita comprenderlo, usando código, diagramas y lo mejor… conversando. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  58. 58. Conclusiones
  59. 59. A tener en cuenta sobre los procesos Ágiles  No deben ser usados por todo el mundo, aunque si deberían usarse por más gente de lo que ahora los usa.  Donde se utiliza mucho un “codifica y prueba” es más fácil implantar un Ágil que un Pesado.  Problema: equipos grandes  Deben usarse cuando los requisitos son volátiles.  Barrera importante: el cliente. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  60. 60. A tener en cuenta sobre los procesos Ágiles  Problema: ¿proyecto grande y requisitos cambiantes?  Se debe apostar por los desarrolladores: si estos están poco preparados y con poca motivación entonces es preferible un proceso predecible.  Si los requisitos son volátiles o inciertos, los desarrolladores están motivados y son responsables y el cliente comprende y se involucra, entonces Adaptativo.  Con equipos de más de 50 personas, precios fijos o alcance fijo y contrato cerrado, entonces Predictivo. Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  61. 61. Las light son mejores pero tienen límites Heavy methodology Personas para Lograr con éxito el proyecto Medium methodology Light methodology Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001
  62. 62. “Un experimento nunca puede ser un fracaso pues siempre viene a demostrar algo” T. Alva Edison Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001

×