eXtreme Programming y "métodos" Ágiles (año 2001)

1. Agile Methods y eX Xtreme Programming Javier Garzás jgarzas@altransdb.com jgarzas@acm.org

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. De Nada a lo Monumental y a lo Ágil § La Metodología: - Nace para solucionar los problemas anteriores Todo resuelto - Produce disciplina … - Mas predecible (¿Seguro?) - Más eficiente Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001

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. 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. 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. El error de lo predecible

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. 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. 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. 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. 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. 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. El mito de la metodología única

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. 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. Una metodología precisa un alcance definido Activities project development rest and recreation vacations and basic business technical education timesheets project sponsor project manager expert user business expert lead designer UI expert Roles reuse point designer/programmer tester writer trainer secretary contractor night watchman janitor Project Lifecycle envisioning proposal sales setup requirements design & code test deploy train alter Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001

18. Metodología, seleccionar en función de… . . . Prioritized for Legal Liability Prioritized for Productivity & Tolerance Criticality (defects cause loss of...) Life (L) L6 L20 L40 L100 L200 L500 L1000 Essential money (E) E6 E20 E40 E100 E200 E500 E1000 Discretionary money (D) D6 D20 D40 D100 D200 D50 D1000 Comfort (C) C6 C20 C40 C100 C200 C500 C1000 1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000 Number of people involved +20% XP Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001

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. 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. eX Xtreme Programming

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. “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. 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. La asunción fundamental de XP y el error de un proceso predecible

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. 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. 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. 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. 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. 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. Sobre la Planificación / Gestión de proyectos XP (Planning XP)

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. 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. 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. 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. 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. 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. 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. El proceso de desarrollo XP

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. 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. 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. 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. 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. Las 12 prácticas § On-site Customer § Coding standars Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001

47. El ciclo XP Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001

48. El ciclo XP Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001

49. El ciclo XP Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001

50. El ciclo XP Javier Garzás, “Agile Methods y XP” ©, Madrid, Junio 2001