Programación Extrema

1. USMP Programación Extrema

2. Origen de Extreme Programming (XP) • XP no es una metodología que se diseño con un gran plan maestro, sino que fue un estilo de programación que se destiló con el paso de los años hasta convertirse en lo que conocemos ahora por eXtreme Programming (XP). • Sus orígenes se remontan a principios de la década de los 80’s dentro de la comunidad de Smalltalk, aunque no se formalizó como metodología hasta 1996 cuando uno de sus precursores, Kent Beck, la puso en práctica para un desarrollo de Chrysler (*). (*)http://www.xprogramming.com/publications/dc9810cs.pdf

3. El Problema El desarrollo de software falla en las entregas y falla en la entrega de valor. Esta falla tiene un enorme impacto tanto humano como económico. Necesitamos encontrar una nueva manera de desarrollar el software Kent Beck (y muchos más…!!!)

4. Atrasos en los calendarios. Cancelaciones de proyectos. Aplicaciones que envejecen muy pronto. Tasa alta de defectos. Falta de comprensión del negocio. Cambios en el negocio. Características atractivas pero con poco valor. Rotación de los programadores. Riesgo: El problema básico El problema básico del desarrollo de software es EL RIESGO. ALGUNOS EJEMPLOS DE RIESGO:

5. Nuestra misión Si aceptamos el RIESGO del proyecto como el problema a ser resuelto, ¿Dónde vamos a buscar la solución? Lo que necesitamos es inventar un estilo de desarrollo de software que enfrenta esos riesgos. Debemos comunicarla a: Programadores, gerentes y clientes.

6. Economía del Software de Desarrollo Necesitamos hacer que nuestro desarrollo de software sea económicamente MÁS VALIOSO: • Gastando el dinero necesario más lentamente. • Generando ganancias más rápidamente. • Aumentando la expectativa de vida de nuestro proyecto.

7. Opciones • Opción de abandono:podemos lograr algo de valor si lo cancelamos ahora. • Opción de cambiar: cambiar la dirección del proyecto a pedido del cliente. Mientras más frecuentemente cambien los requerimientos, mejor. • Opción de diferir: podemos esperar hasta que la situación se ordene. Mientras más se difiera la inversión, mejor. • Opción de crecer: si el mercado parece que despega podemos crecer rápidamente para sacar ventaja. Mientras más rápidamente crezca el proyecto, mejor. La gerencia del proyecto de software tiene las siguientes cuatro opciones:

8. Cuatro variables • Costo • Tiempo • Calidad • Alcance Controlaremos cuatro variables en nuestros proyectos:

9. Cuatro variables • Costo • Tiempo • Calidad • Alcance Algunos gerentes y clientes presionan por lograr lo máximo de cada variable, con eso sólo se logra sacrificar la calidad: GERENTES CLIENTES De todas ellas, el ALCANCE es la variable de MAYOR CONTROL!!

10. Cuatro variables La solución es hacer visibleslas cuatro variables. Si todos (programadores, clientes y gerentes) pueden ver las cuatro variables, ellos elegirán concientemente que variables controlar. • Costo • Tiempo • Calidad • Alcance

11. Interacción entre variables • Costo: ni que falta ni que sobre, ambos extremos traerán problemas. • Tiempo: mucho tiempo retrasa la retroalimentación de la producción, poco tiempo hace peligrar la calidad y a veces el alcance e incluso los costos. • Calidad: es terrible como variable de control. Se logran pocas ganancias (días o semanas) sacrificando la calidad con enormes costos (humanos, de negocios y técnicos). • Alcance: menos alcance hace posible entregar una mejor calidad, a tiempo y a menor costo.

12. Enfocándose en el ALCANCE Mucha gente entiende que el costo, calidad y tiempo son variables de control, pocas comprenden la cuarta variable: EL ALCANCE. Una de las decisiones más poderosas en la gerencia de proyectos es la gestión del ALCANCE. Si administramos activamente el ALCANCE, podemos brindarles a los clientes y gerentes control sobre el costo, la calidad y el tiempo.

13. Enfocándose en el ALCANCE Una de las mejores cosas que pasan con el ALCANCE es que es una variable que VARIA mucho. “Los clientes no nos pueden decir que es lo que ellos quieren. Cuando les entregamos lo que ello dijeron que querían, no les gusta.” ¡Esto es totalmente cierto! Los requerimientos nunca están claros al inicio porque los clientes nunca pueden decirte exactamente lo que quieren.

14. Enfocándose en el ALCANCE ¡El desarrollo de una pieza de software cambia a sus propios requerimientos! Tan pronto como el cliente ve el primer “release”, ellos aprenden que es lo que ellos desean en el siguiente “release”o ¡QUE ES LO QUE REALMENTE QUERIAN EN EL PRIMER “RELEASE”¡

15. Enfocándose en el ALCANCE ¿Podríamos ver esta poca firmeza de los requerimientos del cliente como una oportunidad y no como un problema? Si es así, el ALCANCE se convertiría en la variable más sencilla de las cuatro variables de control.Si creamos una disciplina de desarrollo de software basada en este modelo, podríamos resolver los problemas de tiempo, calidad y costo de cada pieza de software.

16. Enfocándose en el ALCANCE En esa nueva disciplina de desarrollo de software, conforme el desarrollo progrese, podríamos ajustar el continuamente el ALCANCE para que coincida con las condiciones conforme las vayamos encontrando. Debe TOLERAR el CAMBIO fácilmente porque el proyecto podría cambiar de dirección con frecuencia.

17. Enfocándose en el ALCANCE Para lograr eso la Programación Extrema (XP)usa dos estrategias: • Consigues mucha práctica haciendo estimados y retroalimentándote de los resultados actuales. • Mejores estimados reducen las probabilidades de dejar de lado funcionalidad. • Implementas primero los requerimientos más importantes del cliente. • Así, si hay que dejar funcionalidad de lado, será menos importante que la que ya estaría corriendo en el sistema.

18. El Costo del Cambio Una de los supuestos universales de la Ingeniería de Software es que los costos de cambio de un programa crecen exponencialmente en el tiempo.

19. El Costo del Cambio “Un problema que puede costar arreglarlo $1 si se encuentra en la etapa del análisis de requerimientos puede costar arreglarlo miles de dólares una vez que el software esté en producción.”

20. El Costo del Cambio EL PROBLEMA ES QUE ESTA CURVA YA NO ES VÁLIDA. Con una combinación de tecnología y prácticas de programación es posible experimentar una curva totalmente opuesta.

21. El Costo del Cambio Ahora son posibles historias como la que siguen: • 17:00 – Descubrimos que en nuestro sistema no es necesario que cada transacción tenga débitos y créditos en varias cuentas a la vez. • 17:02 – Le pido a mi compañero de programación que examinemos la situación. De 300,000 transacciones en el sistema, confirmamos que todas usan una sóla cuenta de débito y una sóla cuenta de crédito. • 17:05 - ¿Cómo corregimos el error? Cambiando la INTERFASE de la transacción y cambiando la IMPLEMENTACIÓN. Escribimos los cuatro métodos necesarios y empezamos las pruebas. Continuará…

22. El Costo del Cambio • 17:15 – Las pruebas (más de 1000 pruebas unitarias y funcionales) corren al 100%. No hay razón para creer que los cambios no funcionarán bien. Empezamos la migración en la base de datos. • 17:20 – Los ”bacheros” de respaldo han terminado. Instalamos la nueva versión y ejecutamos la migración. • 17:30 – Ejecutamos algunas pruebas de lógica, todo funciona bien. No se nos ocurre nada más que hacer. Nos vamos a casa. • Al día siguiente: Las bitácoras de error están limpias. No hay quejas de los usuarios. El cambio funcionó.

23. El Costo del Cambio La comunidad de desarrollo de software ha invertido enormes cantidades de recursos en las décadas recientes para reducir el costo del cambio: • Mejores lenguajes. • Mejor tecnología de bases de datos. • Mejores prácticas de programación. • Mejores ambientes y herramientas. • Nuevas notaciones.

24. El Costo del Cambio ¿Qué podría suceder si toda esta inversión reportara sus beneficios? ¿Qué pasaría si el costo de cambio no subiese exponencialmente con el tiempo? Esta es una de las premisas de la Programación Extrema (XP). ES LA PREMISA TÉCNICA DE LA PROGRAMACION EXTREMA (XP).

25. El Costo del Cambio Si el costo de cambio sube lentamente con el tiempo, nosotros podríamos actuar de manera muy distinta de cómo ahora nos obligan nuestro actual supuesto de que el costo crece exponencialmente en el tiempo.

26. El Costo del Cambio • Podríamos tomar las grandes decisiones lo más tarde posible • Difiriendo el costo de decidir y teniendo la mayor posibilidad de que las decisiones sean correctas. • Podríamos implementar sólo lo que tenemos que implementar • Esperando que las necesidades que anticipamos para mañana no sean ciertas.

27. El Costo del Cambio Si una curva de costos aplanada hace posible la Programación Extrema (XP), una curva de costos ascendente la haría totalmente imposible.

28. Los Cuatro Valores de la XP Las metas de corto plazo suelen entrar en conflicto con las metas de largo plazo. Las sociedades han aprendido a enfrentar este problema desarrollando un conjunto de valores. Los cuatro valores de la Programación Extrema son: • Comunicación • Simplicidad • Retroalimentación • Coraje

29. Los Cuatro Valores de la XP COMUNICACIÓN (i) Los problemas con los proyectos pueden casi indefectiblemente rastrearse hasta el momento en que alguien no está conversando con alguien más acerca de algo importante. Esto no pasa sólo por azar. Hay muchas circunstancias que conducen a la ruptura de las comunicaciones.

30. Los Cuatro Valores de la XP COMUNICACIÓN (ii) La Programación Extrema (XP) mantiene la comunicación fluida empleando muchas prácticas que no se podrían hacer sin comunicación fluida. • Prueba unitaria. • Programación por pares. • Estimación de tareas. El efecto de probar, emparejar y estimar es que los programadores y los clientes tienen que comunicarse.

31. Los Cuatro Valores de la XP SIMPLICIDAD(i) ¿Cuál es la cosa más simple que podría funcionar para este requerimiento? La simplicidad no es fácil. Lo más difícil es dejar de mirar las cosas que necesitaremos implementar mañana, la próxima semana, el próximo mes. ¡Pensar compulsivamente en el futuro es hacerle caso al miedo a la curva de costos de cambio exponenciales!

32. Los Cuatro Valores de la XP SIMPLICIDAD(ii) La Programación Extrema (XP) es hacer una apuesta: apostar que es mejor hacer una cosa simple hoy y pagar un poco más mañana por cambiarla si se hace necesario,en lugar de hacer algo más complicado hoy que podría no usarse nunca mañana.

33. Los Cuatro Valores de la XP RETROALIMENTACIÓN ¡No me preguntes a mí, pregúntale al sistema! La retroalimentación concreta sobre el estado actual del sistema es absolutamente invalorable. El optimismo es una amenaza ocupacional en el desarrollo de software. La retroalimentación es el tratamiento.

34. Los Cuatro Valores de la XP CORAJE Si no estás yendo a tu máxima velocidad, alguien más lo hará, y ellos se comerán tu almuerzo.Cada cierto tiempo alguien en el equipo tendrá una idea descabellada que podría reducir la complejidad de todo el sistema a la mitad. Si tienen CORAJE, la probarán. Funcionará (A VECES). Si tienen CORAJE, la pondrán en producción.

35. Principios básicos Los cuatro valores nos dan un criterio para una solución exitosa, pero son muy vagos aún para indicarnos qué prácticas utilizar. Necesitamos destilar los valores en principios concretos que podamos usar. Estos principios nos ayudarán a elegir entre las alternativas. Preferiremos las alternativas que cumplan más con los principios que aquellas que no lo hacen.

36. Principios básicos Estos son los principios fundamentales de la Programación Extrema (XP): • Rápida retroalimentación • Adoptar la simplicidad • Cambio incremental • Adoptar el cambio • Trabajo de calidad

37. Rápida retroalimentación • La psicología del aprendizaje enseña que el tiempo entre la acción y la retroalimentación es crítica para el aprendizaje. • Los experimentos en animales demuestran que incluso pequeñas diferencias de tiempo en la retroalimentación resultan en grandes diferencias en el aprendizaje. • Una pequeña demora entre el estímulo y la respuesta y el ratón no aprende que el botón rojo significa comida. • Por eso uno de los principios es conseguir retroalimentación, interpretarla e incluir lo aprendido dentro del sistema tan pronto como sea posible. • La retroalimentación debe ser en segundo o minutos en lugar de días, semanas o meses.

38. Adoptar la simplicidad • Trate cada problema como si pudiese ser resuelto con una simplicidad casi ridícula. • El tiempo que ahorraremos así en el 98% de problemas nos darán los recursos para aplicarlos al otro 2%. • En muchos casos este es el principio más difícil de digerir por parte de los programadores. Nos han dicho tradicionalmente que planeemos para el futuro, que diseñemos para reusar. • En lugar de eso, la Programación Extrema(XP) nos dice que resolvamos el problema de hoy y confiemos en nuestra habilidad para añadirle complejidad en el futuro, cuando sea necesario.

39. Cambio incremental Los grandes cambios hechos todos a la vez simplemente no funcionan. Encontraremos que el cambio incremental es aplicable a la Programación Extrema (XP) de muchas maneras. El diseño cambia un poco en cada vez, el plan cambia un poco en cada vez, el equipo cambio un poco en cada vez. Incluso la adopción de la Programación Extrema (XP) debe ser hecha en pequeños pasos.

40. Adoptar el cambio La mejor estrategia es aquella que preserva la mayoría de las opciones mientras que resuelve inmediatamente tu problema más apremiante.

41. Trabajo de calidad • A nadie le gusta trabajar con negligencia. • A todos nos gusta hacer un buen trabajo. • De las cuatro variables del desarrollo de proyectos – alcance, costo, tiempo y calidad – la calidadno es realmente una variable gratuita. • Las únicas notas posibles son “excelente” o “demencialmente excelente”, dependiendo sólo de sí hay vidas en juego o no. • De otra forma nadie disfrutará del trabajo, nadie trabajará bien y el proyecto se irá por el drenaje.

42. Otros principios menos básicos • Enseñar a aprender. • Inversiones iniciales pequeñas. • Jugar a ganar. • Experimentos concretos. • Comunicación abierta y honesta. • Trabajar con el instinto de la gente, no contra el. • Responsabilidad aceptada. • Adaptación local. • Viajar ligero. • Medición honesta.

43. Las Prácticas • El juego del planeamiento: rápidamente determine el alcance de la próxima entrega combinando las prioridades del negocio y los estimados técnicos. Conforma la realidad sobrepase al plan, actualice el plan. • Pequeñas entregas: ponga sistemas simples en producción rápidamente, luego libere nuevas versiones durante ciclos muy cortos. • Metáfora: conduzca todo el desarrollo usando y compartiendo una historia simple de cómo todo el sistema funcionará.

44. Las Prácticas • Diseño simple: el sistema debe diseñarse tan simple como sea posible en un momento dado. La complejidad extra debe removerse tan pronto como se descubra. • Prueba: los programadores continuamente escriben pruebas unitarias, que deben correr sin falla para que el desarrollo continúe. Los clientes escriben pruebas que demuestren que las características están terminadas. • Mejora interna: los programadores reestructuran el sistema sin cambiar su comportamiento, para remover duplicidades, mejorar la comunicación, simplificar y agregar flexibilidad.

45. Las Prácticas • Programación por pares: toda la producción de código es escrita con dos programadores en cada máquina. • Propiedad colectiva: cualquiera puede cambiar cualquier código en cualquier parte del sistema en cualquier momento. • Integración continua: integrar y construir el sistema muchas veces al día, cada vez que una tarea sea terminada.

46. Las Prácticas • 40 horas a la semana: como regla, no trabaje más de 40 horas a la semana. Nunca trabaje con sobretiempo dos semanas seguidas. • Cliente en el lugar: incluya un usuario real, en persona, dentro del equipo, disponible a tiempo completo para responder preguntas. • Estándares de programación: los programadores escriben código de acuerdo con reglas que enfatizan la comunicación a través del propio código.

47. El ciclo de vida de un proyecto ideal El proyecto ideal de la Programación Extrema (XP) pasa a través de una muy corta fase de desarrollo inicial, seguida por años de un soporte de producción y refinamiento simultáneos, y finalmente un elegante retiro cuando el proyecto ya no tiene mayor sentido. • Exploración • Planeamiento • Iteracciones para la primera versión • Produccionamiento(Producción y Refinamiento) • Mantenimiento • Muerte

48. El ciclo de vida de un proyecto ideal EXPLORACIÓN No estar en producción es estar gastando dinero sin estar haciendo dinero. Antes de ir a producción, sin embargo, uno debe estar seguro que puede ir a producción, tener suficiente confianza en las herramientas que utilizará y que se tienen las habilidades necesarias. En la fase de exploración es cuando todo esto sucede y dura una pocas semanas.

49. El ciclo de vida de un proyecto ideal PLANEAMIENTO El propósito de la fase de planeamiento es que los clientes y programadores lleguen a un acuerdo confiable sobre una fecha, la más corta posible, en la que las características más valiosas estén concluidas. Si ha habido una buena preparación durante la exploración, el planeamiento (producción del calendario de compromisos) debe tomar un día o dos.

50. El ciclo de vida de un proyecto ideal ITERACIONES PARA LA 1ra. VERSIÓN El calendario de compromisos se divide entre 1 a 4 cuatro iteraciones de una semana. Cada iteración produce un juego de casos de pruebas funcionales para cada característica incluida en el calendario para esa iteración. Al final de la última iteración estamos listos para ir a producción.