1 Agustín Villena M. [email protected] Introducción a eXtreme Programming Agustín Villena M.
2 Agustín Villena M. [email protected] Motivación Software fails to deliver… and fails to deliver value! Kent Beck, Extreme Programming Explained z¿Problemas comunes al desarrollar software?... yCaos, yFalta de un método sistemático de trabajo, que se sigue a veces yLa dura realidad: Code like hell yEntregas llenas de cool features que el cliente nunca utiliza (tiempo y dinero desperdiciados) ySoftware lleno de bugs, o de código inmantenible
3 Agustín Villena M. [email protected] Motivación (cont) zUna solución: UML y el Rational Unified Process (RUP). yCompletísimo y apoyado por muchas herramientas yTan grande, que nadie lo usa completamente z¿Y si además tengo pocos recursos? ¿Y necesito producir rápidamente para sobrevivir? y¿Puedo gastar tiempo en actividades burocráticas? yLas herramientas no pueden ser más importantes que el producto final
4 Agustín Villena M. [email protected] Fundamentos de XP zProblema fundamental del desarrollo del software Lidiar con el Riesgo z¿Causa del Riesgo? La incertidumbre z¿La única certeza? El cambio
5 Agustín Villena M. [email protected] Fundamentos de XP Cómo disminuir la incertidumbre zObteniendo retroalimentación exacta y precisa del avance de un proyecto y¡Incluyendo la perspectiva del cliente! zInvirtiendo los menos recursos posibles al comienzo zOfreciendo la oportunidad de ir más rápido zPermitiendo cambiar drásticamente los requerimientos
6 Agustín Villena M. [email protected] Fundamentos de XP Las variables de todo proyecto de software zTiempo, Costo, Alcance, Calidad zPor lo regular se fijan las 3 primeras variables: y“Hazme un administrador de estas tablas de la base de datos, en una semana, con dos programadores” yEntonces la variable que sufre es la calidad zPero la calidad no es algo realmente negociable (¿A quién le gusta hacer un mal trabajo?) zEl tiempo suele estar restringido, y la disposición a pagar también z¿Y si lo variable fuera el Alcance?
7 Agustín Villena M. [email protected] Fundamentos de XP Los costos del cambio en el alcance de un proyecto de software zVisión tradicional z¿Y si fuera así?
8 Agustín Villena M. [email protected] Fundamentos de XP Cómo aplanar la curva de costos zNo sucede mágicamente… zHay tecnologías que son más “amigables” con el cambio yProgramación Orientada a Objetos yBases de Datos Orientadas a Objetos yPero la tecnología sola no sirve… zPrácticas útiles yUn diseño simple del sistema, sin “áreas desiertas” (código que no se usa) yUn sistema automático de Pruebas xPermite hacer cambios y comprobar fácilmente la coherencia del sistema yMucha práctica en cambiar diseños de sistemas
9 Agustín Villena M. [email protected] Fundamentos de XP Cómo aplanar la curva de costos zDiseño XP yLo más simple que pueda funcionar yHacer ahora lo que se necesita ahora, no lo que se cree que necesitará a futuro Complejidad del Diseño Tiempo AhoraDespués Actual Necesitado Lo que se cree necesitado a Futuro Complejidad del Diseño Tiempo AhoraDespués Actual Necesitado Lo que se cree necesitado a Futuro En un proyecto común En XP Trabajo perdido
10 Agustín Villena M. [email protected] Fundamentos de XP El valor entregado del proyecto en su tiempo de desarrollo zTradicionalmente tiempo funcionalidades tiempo funcionalidades z¿Y si fuera así?
11 Agustín Villena M. [email protected] Fundamentos de XP El valor entregado del proyecto en su tiempo de desarrollo (cont) zVentajas de la nueva curva yEl sistema tiene una utilidad promedio superior yAl fin de cada iteración del desarrollo, se tiene un sistema funcional y útil z¿Cómo se logra? yEl cliente decide qué funcionalidad se implementa primero, según su valor yEl desarrollo se realiza en incrementos pequeños yContinuamente se integran los cambios en el sistema
12 Agustín Villena M. [email protected] Fundamentos de XP Pero esta innovación exige valores comunes zValores Comunes: son los que permiten que las personas trabajen por el beneficio común antes que el propio zY en definitiva, el desarrollo de software es una actividad humana yEs afectada por la motivación, creencias y los instintos de las personas
13 Agustín Villena M. [email protected] Fundamentos de XP Valores de XP Comunicación (Centro de todo problema humano) Abierta y honesta Enseñar a aprender Trabajar con los instintos de las personas Simplicidad Asumirla siempre Viajar con equipaje: poco, simple y valioso Cambios paso a paso Adaptación local Coraje Jugar a ganar Responsabilidad aceptada (antes que asumida) Trabajo de Calidad Atacar problema urgente, dejando la mayor cantidad de opciones Retroalimentación Rápida (favorece el aprendizaje) Medir honestamente Experimentos concretos
14 Agustín Villena M. [email protected] Fundamentos de XP Prácticas : Lo “extremo” de XP zKent Beck: y“Llevar buenas prácticas de Ingeniería de Software al extremo” zAlgunos ejemplos: yRevisiones de código => Programación de a pares ySistema de Pruebas Estructurado => Desarrollo Guiado por Pruebas ySoftware funcionando => Entregas Incrementales e Integración Contínua
15 Agustín Villena M. [email protected] Fundamentos de XP Prácticas : Lo “extremo” de XP (cont) zKent Beck: y“Llevar buenas prácticas de Ingeniería de Software al extremo” zEn vez de ydiseñar-programar-probar-depurar-armar-entregar, pasar a yDiseñar continuamente, Probar continuamente, Armar continuamente, Revisar continuamente y Entregar temprana y frecuentemente.
16 Agustín Villena M. [email protected] Workgroup Development XP Values Communication Feedback Courage Simplicity Planning & Management Short Releases Continuous Integration Coding Standards Collective Code Ownerships Pair Programming (+ Move people Around) Metaphor On-Site Customer (a.k.a. One Team) Planning Game (+ Tracking) Refactoring Test First Development 40 Hours Week No Overtime Sustainable Pace Simple Design Customer (Acceptance) Tests XP Practices
17 Agustín Villena M. [email protected] Trabajo en equipo Desarrollo Valores de XP Comunicación Retroalimentación Coraje Simplicidad Planificación y Gestión Entregas cortas Integración continua Estándares de Código Propiedad Colectiva de Código Programación de a pares (+ Mantener el equipo en movimiento) Metáfora Cliente en terreno (a.k.a. Un sólo equipo) Planning Game (+ Control de avance) Refactorizar Desarrollo Guiado por Tests 40 Horas por semana No a las horas extra Ritmo sostenido de avance Diseño Simple Tests de Aceptación del Cliente Prácticas de XP
18 Agustín Villena M. [email protected] Prácticas de XP: Desarrollo ySimpleDesign xDoSimpleThings: Implementar la solución más simple posible que pase el test xYouArentGonnaNeedIt: NO implementar para lo que “podría pasar” xOnceAndOnlyOnce: una funcionalidad debe estar implementada en un solo segmento de código xRegla de oro: Lograr la implementación más simple que corra la suite de pruebas actual
19 Agustín Villena M. [email protected] Prácticas de XP: Desarrollo : SimpleDesign (cont.) z¿Qué define el mejor y más simple diseño? Se siguen 4 guías en orden de prioridad 1.El sistema (código y pruebas incluidos) debe comunicar todo lo que se desea comunicar 2.No debe existir código duplicado 3.El sistema debe tener el menor número de clases 4.El sistema debe tener el menor número de métodos
20 Agustín Villena M. [email protected] Prácticas de XP: Desarrollo : SimpleDesign (cont.) zEl rol de los diagramas ySi aplicamos principios XP xMenor inversión inicial: solo dibujar pocos diagramas a la vez xViajar ligero: si no se puede sincronizar automáticamente con el código, el bosquejo se pasa a código y luego se bota xTrabajar con los instintos: No es algo obligatorio, pero debe estimularse en quienes se comunican bien con ellos
21 Agustín Villena M. [email protected] Prácticas de XP: Desarrollo yTestFirstDevelopment xTests son programados antes de programar la implementación. Luego de programar, se verifica la correctitud automáticamente xAumenta la confianza del desarrollador en su código xFacilita el mejorar el código sin provocar errores en cascada yRefactorMercilessly xCuando dos segmentos de código hagan los mismo, se refactoriza para combinarlos y simplificar el código resultante… SIEMPRE xPermite el llamado “Diseño Emergente”, en contraste con “Diseño detallado”
22 Agustín Villena M. [email protected] Prácticas de XP: Planificación y Gestión yPlanningGame xCon reglas claras y simples, permite definir qué se hará, y cuanto costará hacerlo xInvolucra a Clientes y Desarrolladores xPermite llevar un registro claro de lo desarrollado yCustomerTests (aka AcceptanceTests) xEl Cliente define un conjunto de pruebas que el producto debe ser capaz de pasar, para ser aprobado
23 Agustín Villena M. [email protected] Prácticas de XP: Planificación y Gestión ySmallReleases xCada iteración es muy corta, y sólo se crear el código para un muy pequeño conjunto de funcionalidades yContinuousIntegration x Generar ejecutables funcionales periódicamente (diaramente) xDepende de tener un sistema de pruebas contínuo yStandUpMeeting xMini-reunión al comenzar la jornada, en que todos, de pie, definen lo que harán
24 Agustín Villena M. [email protected] Prácticas de XP: Trabajo en equipo yPairProgramming xUn computador, un teclado, un mouse, y dos programadores xEmpírico código un 20% más simple 15% adicional de productividad sobre el trabajo separado yCollectiveCodeOwnership: todos son propietarios (y responsables) de todo el código yCodingStandards: Usar convenciones que permitan que cualquier desarrollador pueda entender, usar y modificar el código desarrollado por el equipo
25 Agustín Villena M. [email protected] Prácticas de XP: OnsiteCustomer (a.k.a. WholeTeam) zTener todos los involucrados en el mismo lugar, en el mismo horario y¡Incluyendo al cliente! zEl cliente estará disponible para yResponder dudas en el momento que ocurran yEntregar retroalimentación acerca del trabajo x“esta ok” x“hay que cambiar esto x“necesito canjear esta fucionalidad por esta otra” zAsí nos aseguramos de que el cliente no tenga sorpresas ylas que casi siempre son desagradable)
26 Agustín Villena M. [email protected] Prácticas XP System Metaphor z“A story that everyone - customers, programmers, and managers - can tell about how the system works." [Kent Beck, XP Explained] zUsar un lenguaje común (conceptos y metáforas) para describir el producto zDebe soportar los siguientes elementos yVisión Común yVocabulario Compartido yAyudar a crear yArquitectura : sólo como herramienta de comunicación xEvoluciona a partir de la primera iteración xNo se mantiene estática
27 Agustín Villena M. [email protected] Prácticas de XP: Productividad Sostenida en 40 hrs x semana zLos equipos XP trabajan duro, y a un ritmo que puede sostenerse indefinidamente. Esto significa: ySe trabaja sobretiempo sólo cuando es efectivo, pero se entiende como algo extra-ordinario yUn proceso ordenado saca el mejor provecho del tiempo ya asignado yUn desarrollador cansado no produce más que uno descansado zTambién llamado “No Overtime”
28 Agustín Villena M. [email protected] Cómo funciona XP Plan de Entregas con Historias de Usuario Reunión de Planificación de Entregas Escribir código y Pruebas de Módulos Refactorizar la iteración previa ¿Pruebas de aceptación OK? Pruebas de Aceptación El Cliente selecciona la lista de historias para la iteración / mini-entrega Mantenerse iterando para pasar las Pruebas de Aceptación: Pruebas de sistema (Bugs) Pruebas de Módulos Pruebas de usuario Entregas pequeñas al cliente Aprobación del cliente
29 Agustín Villena M. [email protected] Actores del desarrollo XP zSe abstraen las individualidades en dos “bandos” yClientes (Bussiness) yDesarrolladores (Development) zCada cual posee derechos y deberes
30 Agustín Villena M. [email protected] Actores del desarrollo XP Derechos del Cliente zTiene el derecho y el deber de… yDecidir qué será implementado (Alcance del proyecto), definiendo la prioridad, composiciones y fechas de las entregas yConocer el estado actual y el progreso del proyecto. yAgregar, cambiar y remover requerimientos en cualquier momento. yObtener el mayor valor de cada semana de desarrollo. yTener un sistema funcional cada 3 o 4 semanas zOJO: La tecnología es una decisión del cliente
31 Agustín Villena M. [email protected] Actores del desarrollo XP Derechos del Desarrollador zTiene el derecho y el deber de… yDecidir cómo se implementarán las cosas yCrear sistemas con la más alta calidad posible yConsultar al cliente aclaraciones a los requerimientos en cualquier momento yEstimar el esfuerzo de implementar un sistema, y cambiar las estimaciones basado en nuevos descubrimientos yDefinir las consecuencias técnicas de una decisión del cliente
32 Agustín Villena M. [email protected] Gestión de un proyecto XP z¿Cómo alcanzar el justo medio entre…? yGestión centralizada yCaos zSe definen dos roles yCoach (Entrenador) yTracker (Medidor de avance) … pueden ser cumplidos por la misma persona
33 Agustín Villena M. [email protected] Rol del Entrenador zAyudar al resto a hacer un trabajo aún mejor zQue todos tomen buenas decisiones zEstar disponible para ser socio de desarrollo (en especial de los novicios) zVislumbrar objetivos de refactorización de gran escala, y promover las refactorizaciones pequeñas que ayuden zAyudar a los programadores con destrezas individuales yTesting, yFormateo y estandarización de código yrefactorización zExplicar el proceso a gerentes de mayor nivel zProveer de juguetes y comida
34 Agustín Villena M. [email protected] Rol del Medidor de Avance zUsar métricas para medir el avance del proyecto (solo las indispensables) yPor ejemplo: Tiempo de desarrollo / Tiempo calendario zActualizarlas mínimo 2 veces por semana zMostrar la información en una Carta Grande y Visible para todo el equipo zAyudar al Entrenador a yMotivar al cambio de una manera gentil y no coercitiva
35 Agustín Villena M. [email protected] Cómo interviene la gestión un proyecto XP zEs importante reaccionar ante los problemas apenas aparecen zSe reflexiona acerca de qué provoco el problema zSi hay que tomar medidas impopulares, hacerlo firme pero humildemente zEjemplos de intervención yCambios de personal yEn las estrategias de desarrollo yMatar el proyecto
36 Agustín Villena M. [email protected] Instalaciones Físicas en XP Área de Desarrollo zPlanta Abierta, sin grandes muros zEn la periferia, mini-cubículos para trabajo individual y pizarras zEn el centro yPC’s más poderosos yDos puestos por PC Cubículos Información comunitaria
37 Agustín Villena M. [email protected] ¿Cómo adoptar XP? zSe sugiere adoptar una práctica a la vez zSeguir el siguiente algoritmo 1.Elegir el peor problema 2.Resolverlo al estilo XP 3.Cuando no sea el pero problema, partir de nuevo zY puede refinarse -1. Reacomodar todo para programar de pares y que el cliente pueda sentarse con uno 0.Comprar algunos snacks
38 Agustín Villena M. [email protected] (Algunos) Recursos Enlaces de Internet zwww.extremeprogramming.orgwww.extremeprogramming.org zwww.xprogramming.comwww.xprogramming.com zwww.pairprogramming.comwww.pairprogramming.com zrolemodelsoft.com/XP/index.htm#pairPro grammingDotComrolemodelsoft.com/XP/index.htm#pairPro grammingDotCom zwww.xp123.com/xplorwww.xp123.com/xplor zwww.xpuniverse.com/pastXpuwww.xpuniverse.com/pastXpu zwww.refactoring.comwww.refactoring.com
39 Agustín Villena M. [email protected] (Algunos) Recursos Bibliografía zExtreme Programming Explained: Embrace Change Kent Beck zExtreme Programming Installed by Ron Jeffries, Ann Anderson, Chet Hendrickson zExtreme Programming Applied: Playing to Win by Ken Auer and Roy Miller zExtreme Programming in Practice by Robert C. Martin, James W. Newkirk