0
T x 5: T ips &  T ricks... T ools,  T echniques &  T echnologies eXtreme Programming Juan Carlos Fidalgo Fernández T echni...
T x 5 – XP Convenciones usadas y aclaraciones <ul><li>Colores utilizados: </li></ul><ul><ul><li>Código fuente </li></ul></...
T x 5 – XP Agile Development, Extreme Programming (XP) 2ª ed. 2004 2004
T x 5 – XP Test-Driven Development (TDD) 2002 2010
T x 5 – XP Refactoring 1999 2007
T x 5 – XP Patterns 2004 2002 1996 1994
T x 5 – XP Modelo waterfall (en cascada) <ul><li>El más antiguo, conocido y básico de todos los modelos para el desarrollo...
T x 5 – XP La crisis del software  I: Standish Group  I <ul><li>En 1985, un conjunto de profesionales de Massachussets se ...
T x 5 – XP La crisis del software  I: Standish Group  II <ul><li>¿La respuesta a la vista de estos fracasos? </li></ul><ul...
T x 5 – XP La crisis del software  I: Standish Group  y III <ul><li>Según el informe de Standish, las 10 causas principale...
T x 5 – XP Agile (“Agilismo”)  I <ul><li>Como reacción a los constantes fracasos de los métodos más pesados derivados del ...
T x 5 – XP Agile (“Agilismo”)  II <ul><li>“ Estamos descubriendo mejores formas de desarrollar software, haciéndolo y ayud...
La orientación a objetos  El desarrollo convencional vs. el desarrollo OO  II <ul><li>En   las metodologías funcionales  (...
La orientación a objetos  “ ¿Si cambian los requisitos?  Ah, entonces no me preocupa …” “ (*)  El desarrollo iterativo es ...
T x 5 – XP Agile (“Agilismo”)  y III <ul><li>Tras este manifiesto se encuentran 12 principios de vital importancia para en...
T x 5 – XP ¿Qué es eXtreme Programming (XP)?  I <ul><li>XP es una metodología ligera que combina una serie de principios, ...
T x 5 – XP ¿Qué es eXtreme Programming (XP)?  y II <ul><li>Historia: </li></ul><ul><ul><li>C3 ( “Chrysler Comprehensive Co...
T x 5 – XP Las 12 prácticas de XP  I <ul><li>Las 12 prácticas de XP: </li></ul><ul><li>(ninguna de las prácticas establece...
T x 5 – XP Las 12 prácticas de XP  y II <ul><li>Las 12 prácticas de XP, agrupadas en 4 áreas, son: </li></ul><ul><ul><li>“...
T x 5 – XP Los valores de XP <ul><li>XP fomenta los siguiente 4/5 valores: </li></ul><ul><ul><li>Comunicación </li></ul></...
T x 5 – XP Los roles de XP  I <ul><li>Cada proyecto XP tiene varios roles diferentes, cada uno con su propio conjunto de d...
T x 5 – XP Los roles de XP  II <ul><li>Customer  (Cliente): </li></ul><ul><ul><li>Es parte del equipo </li></ul></ul><ul><...
T x 5 – XP Los roles de XP  y III <ul><li>Existen un par de roles suplementarios que no están presentes en todos los equip...
T x 5 – XP XP vs. Agile <ul><li>Algunas veces los términos “XP” y “Agile” se utilizan para referirse a lo mismo, mientras ...
T x 5 – XP La crisis del software  y II: MIT Sloan Management Review <ul><li>Un estudio de 2 años, presentado en el MIT Sl...
T x 5 – XP La tierra llamando al Jefe… <ul><li>¿En qué consiste el programa de cortes de precios en temporada? </li></ul><...
T x 5 – XP User Stories <ul><li>Una “user story” o historia de usuario es la representación de un requerimiento de softwar...
T x 5 – XP User Stories: características <ul><li>Una historia de usuario debe ser: </li></ul><ul><ul><li>Independiente : D...
T x 5 – XP User Stories: beneficios <ul><li>Si están bien escritas, los beneficios de las historias de usuario son: </li><...
T x 5 – XP User Stories: limitaciones e inconvenientes <ul><li>Sin pruebas de validación pueden quedar abiertas a distinta...
T x 5 – XP User Stories vs. IEEE 830 <ul><li>El IEEE publicó un conjunto de directrices sobre cómo escribir las especifica...
T x 5 – XP User Stories vs. Use Cases  I <ul><li>Los casos de uso fueron introducidos por primera vez por Ivar Jacobson en...
T x 5 – XP User Stories vs. Use Cases  y II <ul><li>Ambos describen escenarios y, si están bien escritos, deben añadir lo ...
T x 5 – XP CCPPT: User Stories <ul><li>El responsable comercial puede crear un corte de cadena nuevo a partir de un corte ...
T x 5 – XP ATDD  I <ul><li>¿Cómo podemos garantizar que …? </li></ul><ul><ul><li>El objetivo se ha entendido bien (análisi...
T x 5 – XP ATDD  II
T x 5 – XP ATDD  III <ul><li>Están basados en ejemplos de historias de usuario </li></ul><ul><li>Son escritos antes del de...
T x 5 – XP ATDD  y IV <ul><li>http ://www.concordion.org/Example.html </li></ul><ul><li>http://www.concordion.org/Tutorial...
T x 5 – XP CCPPT: Acceptance Tests <ul><li>User Story: El responsable comercial puede suscribir países a un corte de caden...
T x 5 – XP TDD  I <ul><li>“ Test-Driven Development (TDD) is a deceptively simple idea: </li></ul><ul><li>write the tests ...
T x 5 – XP TDD  II <ul><li>“ Of all the Agile methods, XP is the only method that provides deep and profound disciplines f...
T x 5 – XP TDD  y III <ul><li>El testing sucede a varios niveles: </li></ul><ul><ul><li>“ Acceptance Tests”, para determin...
T x 5 – XP Críticas a XP  I <ul><li>“ PP no puede funcionar: muchos programadores tienen gran sentimiento de posesión del ...
T x 5 – XP Críticas a XP  y II <ul><li>“ El mito de las 40 horas semanales es un lujo para las exigencias del mercado” </l...
T x 5 – XP Bajando el telón  I <ul><li>Otros recursos: </li></ul><ul><ul><li>“ Test Driven Development Primer with Peter P...
T x 5 – XP Bajando el telón  II <ul><li>Recomendaciones: </li></ul><ul><ul><li>TDD sí y ahora; XP “no” aún – no de forma c...
T x 5 – XP Sumario  I <ul><li>Metodologías ágiles: </li></ul><ul><ul><li>Procesos iterativos e incrementales: se entrega p...
T x 5 – XP Sumario  y II <ul><li>XP: </li></ul><ul><ul><li>Metodología de desarrollo ágil </li></ul></ul><ul><ul><li>Busca...
Upcoming SlideShare
Loading in...5
×

Introducción a la programación extrema (XP)

10,937

Published on

Introducción a la programación extrema (extreme programming).

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

  • Be the first to like this

No Downloads
Views
Total Views
10,937
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
78
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • (*) Antes de iniciar este slide, hablar del desarrollo en cascada y de su problemática asociada: amplificación de los errores, poca y tardía participación de los usuarios en un proyecto, etc., etc. (**) Símil del desarrollo iterativo con las muñecas rusas (Matrioshkas) (***) Cuando tras días de prototipaje el usuario ve éste y dice que no es lo que esperaba, ¿es para cabrearse o para alegrarse? RE: para alegrarse; el usuario ha clarificado su visión gracias al prototipo y de no ser por éste el desarrollo completo habría implicado seguramente bastante más tiempo
  • (*) Filosofías: “Los programadores que descansan son más productivos” y “La frescura aporta mejores ideas” El exceso de trabajo es un serio problema en los proyectos (síndrome del quemado o burn-out: http://es.wikipedia.org/wiki/Burn-out) (**) Son fundamentales cuando los programadores cambian de pareja o hacen refactoring del código de otros Se consigue un código con el mismo estilo, homogéneo, legible, así como evitar las clásicas situaciones “esto no puede modificarse hasta que venga Pepito de sus vacaciones; lo lleva él y es el único que sabe cómo funciona…” (***) El mejor diseño es el más simple de todos aquellos que pasen todos los tests Para XP simple significa (por orden de prioridad): El sistema (tanto el código como los tests) deben comunicar todo lo que se deba comunicar El sistema no debe contener código duplicado Debe tener la menor cantidad de clases Debe tener la menor cantidad de métodos
  • Transcript of "Introducción a la programación extrema (XP)"

    1. 1. T x 5: T ips & T ricks... T ools, T echniques & T echnologies eXtreme Programming Juan Carlos Fidalgo Fernández T echniques
    2. 2. T x 5 – XP Convenciones usadas y aclaraciones <ul><li>Colores utilizados: </li></ul><ul><ul><li>Código fuente </li></ul></ul><ul><ul><li>Comentarios </li></ul></ul><ul><ul><li>Pregunta/petición lanzada al público </li></ul></ul>
    3. 3. T x 5 – XP Agile Development, Extreme Programming (XP) 2ª ed. 2004 2004
    4. 4. T x 5 – XP Test-Driven Development (TDD) 2002 2010
    5. 5. T x 5 – XP Refactoring 1999 2007
    6. 6. T x 5 – XP Patterns 2004 2002 1996 1994
    7. 7. T x 5 – XP Modelo waterfall (en cascada) <ul><li>El más antiguo, conocido y básico de todos los modelos para el desarrollo de software y ha servido como bloque de construcción para los demás paradigmas de ciclo de vida </li></ul><ul><li>Está basado en el ciclo convencional de una ingeniería y su visión es muy simple: el desarrollo de software se debe realizar siguiendo una secuencia de fases </li></ul><ul><li>Esencialmente, nos movemos al paso N+1 sólo cuándo se ha completado el 100% de N </li></ul><ul><li>Las etapas o actividades del modelo en cascada son requerimientos, diseño, programación, testing y mantenimiento </li></ul><ul><li>El modelo presente la ventaja evidente de su sencillez, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software </li></ul><ul><li>Sin embargo, presenta un gran número de [serios] inconvenientes: </li></ul><ul><ul><li>Los proyectos reales raras veces siguen el flujo secuencial propuesto por el modelo </li></ul></ul><ul><ul><li>Al cliente le es difícil establecer todos los requisitos de forma explícita al principio del proyecto (es habitual que se den situaciones descritas en el antipatrón “Analysis paralysis”) </li></ul></ul><ul><ul><li>El cliente debe ser paciente: no verá la solución hasta el final (ausencia de retroalimentación) </li></ul></ul><ul><ul><li>Si un requerimiento no fue tomado correctamente, o una decisión de diseño no fue acertada, … (amplificación de los errores) </li></ul></ul>
    8. 8. T x 5 – XP La crisis del software I: Standish Group I <ul><li>En 1985, un conjunto de profesionales de Massachussets se unió bajo el nombre de Standish Group </li></ul><ul><li>Su objetivo: obtener información de los proyectos fallidos en IT y así poder encontrar y combatir las causas de los fracasos </li></ul><ul><li>A lo largo del tiempo, el Standish Group reveló 50.000 proyectos fallidos </li></ul><ul><li>Concretamente, en 1994: </li></ul><ul><ul><li>El 31% de los proyectos fueron cancelados </li></ul></ul><ul><ul><li>El 53% registró enormes desvíos en presupuesto y en cronograma </li></ul></ul><ul><ul><li>El 16% se completó a tiempo y dentro de los costos presupuestados </li></ul></ul><ul><ul><li>(la funcionalidad comprometida sólo se cumplió, de promedio, ¡en el 61%!) </li></ul></ul><ul><li>Sobre las causas de los problemas relacionadas con requerimientos: </li></ul><ul><ul><li>El 13% eran debidas a requerimientos erróneos </li></ul></ul><ul><ul><li>El 12% a requerimientos incompletos </li></ul></ul><ul><ul><li>Otro 12% a cambios en los requerimientos </li></ul></ul>
    9. 9. T x 5 – XP La crisis del software I: Standish Group II <ul><li>¿La respuesta a la vista de estos fracasos? </li></ul><ul><ul><li>La de la industria: durante los siguientes 10 años se invirtieron varios miles de millones de dólares destinadas a mejorar la administración y la productividad </li></ul></ul><ul><ul><li>(desarrollo y perfeccionamiento de metodologías y tecnologías – PMI, CMMI, …) </li></ul></ul><ul><ul><li>La del ciclo de vida en cascada: intentar con ahínco pulir, estabilizar y fijar los requerimientos antes de cualquier diseño o implementación </li></ul></ul><ul><li>Los resultados de la encuesta del 2004 (10 años después) demuestran que estas inversiones no sirvieron de mucho: </li></ul><ul><ul><li>Los proyectos exitosos crecieron sólo al 29% </li></ul></ul><ul><ul><li>Los proyectos fracasados representan el 71% </li></ul></ul><ul><ul><li>E. d.: </li></ul></ul><ul><ul><ul><li>7 de cada 10 proyectos se cancelaron o bien registraron desvíos del 45% sobre lo presupuestado en costos y del 63% en tiempos </li></ul></ul></ul><ul><ul><ul><li>Además apenas se cumplió con el 67% de la funcionalidad comprometida </li></ul></ul></ul>
    10. 10. T x 5 – XP La crisis del software I: Standish Group y III <ul><li>Según el informe de Standish, las 10 causas principales de los fracasos son las siguientes ( por orden de importancia ): </li></ul><ul><ul><li>Escasa participación de los usuarios </li></ul></ul><ul><ul><li>Requerimientos y especificaciones incompletas </li></ul></ul><ul><ul><li>Cambios frecuentes en los requerimientos y especificaciones </li></ul></ul><ul><ul><li>Falta de soporte ejecutivo </li></ul></ul><ul><ul><li>Incompetencia tecnológica </li></ul></ul><ul><ul><li>Falta de recursos </li></ul></ul><ul><ul><li>Expectativas no realistas </li></ul></ul><ul><ul><li>Objetivos poco claros </li></ul></ul><ul><ul><li>Cronogramas irreales </li></ul></ul><ul><ul><li>Nuevas tecnologías </li></ul></ul><ul><ul><li>( 7 de estos factores son factores humanos ) </li></ul></ul>
    11. 11. T x 5 – XP Agile (“Agilismo”) I <ul><li>Como reacción a los constantes fracasos de los métodos más pesados derivados del modelo en cascada, … </li></ul><ul><li>… fueron apareciendo una serie de métodos llamados “ligeros” </li></ul><ul><li>XP era uno de ellos, pero había muchos más: SCRUM, FDD, Crystal, … </li></ul><ul><li>Cada uno de estos métodos ligeros tenía su propio conjunto de principios, valores y prácticas, así como su propio grupo de partidarios </li></ul><ul><li>En el año 2000, Kent Beck reunió a los 17 más influentes de todos ellos </li></ul><ul><li>http ://www.agilemanifesto.org/authors.html </li></ul><ul><li>El objetivo era ver si los valores y principios de los distintos métodos podían mezclarse de un modo consistente </li></ul><ul><li>Los asistentes, dejando a un lado sus diferencias, acordaron crear un manifiesto y un conjunto de principios que abarcase a todos los métodos </li></ul><ul><li>A estos principios también les dieron un nombre: Agile </li></ul>
    12. 12. T x 5 – XP Agile (“Agilismo”) II <ul><li>“ Estamos descubriendo mejores formas de desarrollar software, haciéndolo y ayudando a otros a hacerlo. </li></ul><ul><li>A través de este trabajo hemos llegado a valorar: </li></ul><ul><li> Individuos e interacciones por encima de procesos y herramientas </li></ul><ul><li> Software que funciona por encima de documentación exhaustiva </li></ul><ul><li> Colaboración con clientes por encima de negociación de contratos </li></ul><ul><li> Respuesta al cambio (*) por encima de seguir un plan” </li></ul><ul><li>Firmaban: Kent Beck , Mike Beedle, Arie van Bennekum, Alistair Cockburn , Ward Cunningham , Martin Fowler , James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries , Jon Kern, Brian Marick, Robert C. Martin , Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas </li></ul><ul><li>http://www.agilemanifesto.org/ </li></ul><ul><li>http://es.wikipedia.org/wiki/Manifiesto_%C3%A1gil </li></ul><ul><li>(*) Respuesta al cambio… ¿os suena? RE: Formación OO día 1 de 4; año 2008 </li></ul>
    13. 13. La orientación a objetos El desarrollo convencional vs. el desarrollo OO II <ul><li>En las metodologías funcionales (Yourdon, DeMarco, …) se hace un especial hincapié en especificar y descomponer la funcionalidad del sistema </li></ul><ul><li>Este enfoque puede parecer la forma más directa de implementar un objetivo deseado pero el sistema resultante puede ser muy frágil </li></ul><ul><li>Si cambian los requisitos, un sistema basado en la descomposición funcional puede requerir una importante reestructuración </li></ul><ul><li>En cambio, el enfoque OO se centra primordialmente en identificar objetos del dominio de la aplicación y ajustarles después los procedimientos </li></ul><ul><li>Puede parecer más indirecto, pero soporta mejor las evoluciones de los requisitos porque ... </li></ul><ul><li>... está basado en el entorno subyacente del dominio de la aplicación en si, más que en los requisitos funcionales de un único problema </li></ul>
    14. 14. La orientación a objetos “ ¿Si cambian los requisitos? Ah, entonces no me preocupa …” “ (*) El desarrollo iterativo es un enfoque en el que el desarrollo se organiza en una serie de mini-proyectos cortos, de duración fija (p. ej., cuatro semanas) llamados iteraciones. El resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado. (**) Cada iteración incluye sus propias actividades de análisis de requisitos, diseño, implementación y pruebas. (…) El subtítulo de un libro que trata el desarrollo iterativo es Aceptar el cambio [Beck00]. Esta frase evoca una aptitud clave del desarrollo iterativo: en lugar de luchar contra el inevitable cambio que ocurre en el desarrollo de software intentando (normalmente sin éxito) especificar, congelar y ‘firmar’ de manera completa y correcta a partir de un conjunto de requisitos fijos y diseñar antes de implementar, el desarrollo iterativo se basa en una aptitud de aceptación del cambio y la adaptación como motores inevitables y, de hecho, esenciales . Esto no quiere decir que el desarrollo iterativo (y el UP) fomenten un proceso dirigido por ‘una adición de características’ de manera incontrolada y reactiva. El UP llega a un equilibro entre la necesidad – por un lado – de llegar a un acuerdo y estabilizar un conjunto de requisitos, y – por otro lado – la realidad de los requisitos cambiantes, cuando el personal involucrado clarifica su visión o cambia el mercado .” (***) “ UML y patrones” – Craig Larman
    15. 15. T x 5 – XP Agile (“Agilismo”) y III <ul><li>Tras este manifiesto se encuentran 12 principios de vital importancia para entender su filosofía: </li></ul><ul><ul><li>Satisfacción cliente a través de entregas tempranas y continuas de software valioso (prioritario) </li></ul></ul><ul><ul><li>Requisitos cambiantes bienvenidos, tb en etapas finales desarrollo (ventaja competitiva cliente) </li></ul></ul><ul><ul><li>Entregamos s/w que funciona frecuentemente: de 2 semanas a 2 meses (común 3-4 semanas) </li></ul></ul><ul><ul><li>( subjconjuntos con calidad de producción del sistema final; ¡no prototipos!) </li></ul></ul><ul><ul><li>Gente de negocio y desarrollo deben trabajar juntos a diario durante todo el proyecto </li></ul></ul><ul><ul><li>Construimos proyectos entorno a individuos motivados, dándoles apoyo y confianza </li></ul></ul><ul><ul><li>La conversación cara a cara es el método más eficiente y efectivo de comunicar la información </li></ul></ul><ul><ul><li>La principal medida de avance es el software que funciona </li></ul></ul><ul><ul><li>Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante </li></ul></ul><ul><ul><li>La atención continua a la excelencia técnica y el buen diseño mejoran la agilidad </li></ul></ul><ul><ul><li>La simplicidad, es esencial </li></ul></ul><ul><ul><li>Las mejores arquitecturas, requisitos y diseños emergen de la autoorganización de los equipos </li></ul></ul><ul><ul><li>Reflexión a intervalos regulares sobre cómo ser más eficaces y mejora+ajuste en consecuencia </li></ul></ul><ul><li>http://www.agilemanifesto.org/principles.html </li></ul>
    16. 16. T x 5 – XP ¿Qué es eXtreme Programming (XP)? I <ul><li>XP es una metodología ligera que combina una serie de principios, prácticas y procesos </li></ul><ul><li>XP permite a equipos de desarrollo [¿pequeños?] construir s/w de forma rápida y con calidad a pesar de requisitos “vagos o cambiantes” </li></ul><ul><ul><li>¿“Y dos huevos duros”? – Groucho Marx </li></ul></ul><ul><ul><li>RE: no, XP no lo hace tan incompatible. ¿Alguien cree que futuros cambios en los requisitos en CCPPT – relativos a validaciones – podrían implicarme problemas serios? </li></ul></ul><ul><li>XP está orientada fuertemente hacia la codificación y hace un gran énfasis en la comunicación informal, verbal </li></ul><ul><li>XP puede ser desplegada con éxito en entornos de pequeña, mediana o gran empresa </li></ul><ul><li>Aunque XP es relativamente nueva, sus prácticas existen desde hace tiempo; la metodología simplemente une y exprime “mejores prácticas” </li></ul><ul><li>XP es actualmente la más destacada de todas las metodologías ágiles (Scrum lo es a nivel de gestión de proyectos) </li></ul>
    17. 17. T x 5 – XP ¿Qué es eXtreme Programming (XP)? y II <ul><li>Historia: </li></ul><ul><ul><li>C3 ( “Chrysler Comprehensive Compensation System”) se inició en 1995 </li></ul></ul><ul><ul><li>Su objetivo era crear para 1999 un nuevo sistema de nóminas (87.000 empleados) </li></ul></ul><ul><ul><li>Un año más tarde, Kent Beck fue contratado para dirigir el proyecto: ¡el sistema no había impreso hasta la fecha ni un solo cheque! </li></ul></ul><ul><ul><li>Kent Beck se trajo a Ron Jeffries </li></ul></ul><ul><ul><li>En marzo de 1996 estimaron que el sistema estaría listo para entrar en producción alrededor de un año después </li></ul></ul><ul><ul><li>C3 concluyó con éxito en 1997 (con un par de meses de retraso pero que se consideraron justificados) </li></ul></ul><ul><ul><li>Durante el proceso había nacido una nueva metodología: eXtreme Programming (XP) </li></ul></ul>
    18. 18. T x 5 – XP Las 12 prácticas de XP I <ul><li>Las 12 prácticas de XP: </li></ul><ul><li>(ninguna de las prácticas establece algo por sí misma; todas requieren de otras para conseguir un cierto “equilibrio”) </li></ul>
    19. 19. T x 5 – XP Las 12 prácticas de XP y II <ul><li>Las 12 prácticas de XP, agrupadas en 4 áreas, son: </li></ul><ul><ul><li>“ Fine scale feedback” (retroalimentación a pequeña escala) </li></ul></ul><ul><ul><ul><li>“ Pair programming” (programación por parejas) </li></ul></ul></ul><ul><ul><ul><li>“ Planning game” (el juego de la planificación) </li></ul></ul></ul><ul><ul><ul><li>“ Testing” / “Test-driven development” (pruebas / desarrollo guiado por tests) </li></ul></ul></ul><ul><ul><ul><li>“ On-site customer” / “Whole team” (cliente in situ / equipo completo) </li></ul></ul></ul><ul><ul><li>“ Continuous process” (proceso continuo) </li></ul></ul><ul><ul><ul><li>“ Continuous integration” (integración continua) </li></ul></ul></ul><ul><ul><ul><li>“ Short releases” / “Small releases” (pequeñas entregas) </li></ul></ul></ul><ul><ul><ul><li>“ Design improvement” / “Refactoring” (mejoras de diseño / refactorizar) </li></ul></ul></ul><ul><ul><li>“ Programmer welfare” (bienestar del programador) </li></ul></ul><ul><ul><ul><li>“ Sustainable pace” / “40 hour week” (ritmo sostenible / 40 horas semanales) (*) </li></ul></ul></ul><ul><ul><li>“ Shared understanding” (entendimiento compartido) </li></ul></ul><ul><ul><ul><li>“ [System] metaphor” (metáfora [del sistema]) – en STR limbo; otros: pizarra, saco, … </li></ul></ul></ul><ul><ul><ul><li>“ Coding standards” (estándares de codificación) (**) </li></ul></ul></ul><ul><ul><ul><li>“ Collective [code] ownership” (propiedad colectiva [del código]) </li></ul></ul></ul><ul><ul><ul><li>“ Simple design” (diseño simple) – no siempre simple es sinónimo de fácil (***) </li></ul></ul></ul><ul><li>http ://en.wikipedia.org/wiki/Extreme_Programming_Practices </li></ul>
    20. 20. T x 5 – XP Los valores de XP <ul><li>XP fomenta los siguiente 4/5 valores: </li></ul><ul><ul><li>Comunicación </li></ul></ul><ul><ul><li>(tanto entre todos los miembros del equipo como con el cliente y preferiblemente verbal en lugar de escrita) </li></ul></ul><ul><ul><li>Simplicidad </li></ul></ul><ul><ul><li>(diseñar la solución más simple que funcione hoy vs. una complicada pensando en mañana: YAGNI: http://es.wikipedia.org/wiki/No_vas_a_necesitarlo_( YAGNI) ) </li></ul></ul><ul><ul><li>Retroalimentación </li></ul></ul><ul><ul><li>(entre cliente, usuarios y equipo y además cuánto más inmediata mejor: PP, IPC, …) </li></ul></ul><ul><ul><li>Coraje o valor </li></ul></ul><ul><ul><li>(en el contexto de las otras: valor para refactorizar – tenemos tests para “cubrirnos” –, valor para la simplicidad – vs. YAGNI –, valor para el feedback – vs. la adivinación –, …) </li></ul></ul><ul><ul><li>Respeto </li></ul></ul><ul><ul><li>(añadido en la 2ª edición de “Extreme Programming Explained: Embrace Change” ) </li></ul></ul>
    21. 21. T x 5 – XP Los roles de XP I <ul><li>Cada proyecto XP tiene varios roles diferentes, cada uno con su propio conjunto de derechos y obligaciones </li></ul><ul><li>XP intenta mejorar la comunicación entre clientes y desarrolladores, para lo cuál divide claramente el trabajo entre los dos </li></ul><ul><li>Así, XP da a cada uno de ellos autoridad en su área de especialización: </li></ul><ul><li>a los desarrolladores sobre las decisiones técnicas y al cliente sobre las decisiones de negocio </li></ul><ul><li>De esta forma en XP se mejoran las posibilidades de éxito </li></ul>
    22. 22. T x 5 – XP Los roles de XP II <ul><li>Customer (Cliente): </li></ul><ul><ul><li>Es parte del equipo </li></ul></ul><ul><ul><li>Determina qué construir y cuándo </li></ul></ul><ul><ul><li>Establece las pruebas de aceptación </li></ul></ul><ul><li>Manager (Jefe de proyecto): </li></ul><ul><ul><li>Organiza y guía las reuniones </li></ul></ul><ul><ul><li>Asegura condiciones adecuadas para el proyecto </li></ul></ul><ul><li>Desarrollador (Developer): </li></ul><ul><li>(sin distinción entre analistas, diseñadores o programadores; en XP los programadores diseñan, programan y realizan las pruebas) </li></ul><ul><ul><li>Responsable de decisiones técnicas </li></ul></ul><ul><ul><li>Responsable de construir el sistema </li></ul></ul><ul><li>Tester (Probador / verificador): </li></ul><ul><ul><li>Enfocado en ayudar al cliente </li></ul></ul><ul><ul><li>Ayuda al cliente a encontrar y escribir pruebas funcionales </li></ul></ul><ul><ul><li>Es responsable de correr las pruebas regularmente y poner los resultados en un lugar visible </li></ul></ul>
    23. 23. T x 5 – XP Los roles de XP y III <ul><li>Existen un par de roles suplementarios que no están presentes en todos los equipos: </li></ul><ul><ul><li>Tracker (Rastreador): </li></ul></ul><ul><ul><ul><li>“ Metric Man”: mide las estimaciones del equipo y les informa en cuánto se equivocaron, para conseguir mejores resultados la próxima vez (las estimaciones son esenciales en XP) </li></ul></ul></ul><ul><ul><ul><li>Debe saber si no se llega a finalizar una iteración e informar al equipo a tiempo </li></ul></ul></ul><ul><ul><ul><li>Es responsable de tener una visión global </li></ul></ul></ul><ul><ul><ul><li>Observa sin molestar </li></ul></ul></ul><ul><ul><ul><li>Conserva datos históricos </li></ul></ul></ul><ul><ul><li>Coach (Entrenador / preparador): </li></ul></ul><ul><ul><ul><li>Guía al equipo a entender XP cuando se adopta éste por primera vez </li></ul></ul></ul><ul><ul><ul><li>Unas veces enseña directamente y otras “se remanga” y enseña a través de la práctica </li></ul></ul></ul><ul><ul><ul><li>Su principal virtud es la experiencia; debe entender XP en profundidad </li></ul></ul></ul><ul><ul><ul><li>Puede sugerir cambios en la implementación, ofrecer ideas para resolver un problema técnico espinoso, etc. pero siempre con una posición de respeto </li></ul></ul></ul><ul><ul><ul><li>Tiende a estar en un segundo plano a medida que el equipo madura </li></ul></ul></ul>
    24. 24. T x 5 – XP XP vs. Agile <ul><li>Algunas veces los términos “XP” y “Agile” se utilizan para referirse a lo mismo, mientras que otras significan cosas diferentes </li></ul><ul><li>¿Es “Agile” lo mismo que “XP”? ¿Es XP Agile? </li></ul><ul><li>El término “XP” es unos años anterior a “Agile” </li></ul><ul><li>XP es un conjunto de prácticas, principios y valores inventados por Kent Beck y que se ajustan a los de “Agile” </li></ul><ul><li>E. d., XP es un método concreto mientras que “Agile” es una clasificación </li></ul><ul><li>Así, hay muchos más métodos ágiles; XP es sólo uno de ellos </li></ul>
    25. 25. T x 5 – XP La crisis del software y II: MIT Sloan Management Review <ul><li>Un estudio de 2 años, presentado en el MIT Sloan Management Review sobre los proyectos software con éxito, identificó 4 factores comunes: </li></ul><ul><ul><li>Desarrollo iterativo en lugar de un proceso en cascada </li></ul></ul><ul><ul><li>Como mínimo una incorporación diaria de nuevo código para la construcción del sistema completo y una rápida retroalimentación de los cambios del diseño </li></ul></ul><ul><ul><li>(a través de las pruebas) </li></ul></ul><ul><ul><li>Equipo con experiencia en expedir múltiples productos </li></ul></ul><ul><ul><li>Centrarse pronto en la construcción y prueba de una arquitectura consistente </li></ul></ul><ul><li>3 de estos 4 factores son prácticas explícitas en la mayoría[?] de las metodologías ágiles </li></ul>
    26. 26. T x 5 – XP La tierra llamando al Jefe… <ul><li>¿En qué consiste el programa de cortes de precios en temporada? </li></ul><ul><li>Tras escuchar a Santi, cualquier programador que se precie habrá visto claro que necesitamos los patrones State, Command, Strategy, Façade,… </li></ul><ul><li>… ¿o no? 0;-) </li></ul><ul><li>RE: No, o no necesariamente, o sí pero ahora no es el momento de decidirlo. Dicho de otro modo, ¿sería eso aplicar “simplicidad”? </li></ul><ul><li>Cuando veamos TDD veremos como la arquitectura se va forjando en pequeños pasos a base de iterar y refactorizar, y no toda a priori </li></ul><ul><li>Carlos Blé hace una comparación muy ingeniosa: moldear una figura a golpe de cincel </li></ul><ul><li>Al final hay un artículo de Robert C. Martin sobre “Bowling” en el que también se puede apreciar esto de forma muy, muy clara </li></ul>
    27. 27. T x 5 – XP User Stories <ul><li>Una “user story” o historia de usuario es la representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario </li></ul><ul><li>Son usadas en las metodologías ágiles para la especificación de requerimientos (acompañadas de las discusiones con los usuarios y las pruebas de validación) </li></ul><ul><li>Dentro de XP las historias de usuario deben ser escritas por los clientes </li></ul><ul><li>Son una forma rápida de administrar los requerimientos de los usuarios sin tener que elaborar muchos documentos formales ni requerir mucho tiempo para administrarlos </li></ul><ul><li>Se caracterizan por prioridad, riesgo y esfuerzo </li></ul><ul><li>Permiten responder rápidamente a requerimientos cambiantes o poco claros </li></ul><ul><li>El estilo puede ser libre pero la historia de usuario debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio? </li></ul><ul><li>Por ello, algunos autores recomiendan redactarlas según el formato: </li></ul><ul><ul><li>Como (rol) quiero (algo) para poder (beneficio) </li></ul></ul>
    28. 28. T x 5 – XP User Stories: características <ul><li>Una historia de usuario debe ser: </li></ul><ul><ul><li>Independiente : De ser necesario, combinar las historias dependientes o buscar otra forma de dividir las historias de manera que resulten independientes </li></ul></ul><ul><ul><li>Negociable : La historia en si misma no lo suficientemente explícita como para considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación </li></ul></ul><ul><ul><li>“ Valiosa” (aportar valor a los clientes / usuarios): Los intereses de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos más que para el desarrollador </li></ul></ul><ul><ul><li>Estimable : Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Esto permite estimar el tiempo total del proyecto </li></ul></ul><ul><ul><li>Pequeña : Las historias muy largas son difíciles de estimar e imponen restricciones sobre la planificación de un desarrollo iterativo (tendrían que poder escribirse en un post-it). Generalmente se recomienda la consolidación de historias muy cortas en una sola historia </li></ul></ul><ul><ul><li>Verificable : Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables. Cuando sea posible, la verificación debe automatizarse, de manera que pueda ser verificada en cada entrega del proyecto </li></ul></ul>
    29. 29. T x 5 – XP User Stories: beneficios <ul><li>Si están bien escritas, los beneficios de las historias de usuario son: </li></ul><ul><ul><li>Son adecuadas para el desarrollo iterativo (son cortas y por tanto de rápida implementación – días, semanas –, de tamaño idóneo para la planificación, permiten dividir los proyectos en pequeñas entregas, son fáciles de estimar, …) </li></ul></ul><ul><ul><li>Son comprensibles por todo el equipo (usan vocabulario del cliente y no técnico, eliminan la posible ambigüedad, no son listas interminables y tediosas de “El sistema debería bla, bla, bla”, …) </li></ul></ul><ul><ul><li>Enfatizan la comunicación verbal (cara a cara), fomentando una relación cercana con el cliente </li></ul></ul><ul><ul><li>Dan soporte al diseño “oportunista” y permiten diferir los detalles a la implementación (una historia no es ni pretende ser un registro exhaustivo de un requerimiento; cuando llega el momento de implementar una historia, el cliente – cara a cara – proporciona los detalles) </li></ul></ul><ul><ul><li>Favorecen el crecimiento del conocimiento tácito (extienden el conocimiento) </li></ul></ul><ul><ul><li>Fomentan el diseño participativo </li></ul></ul><ul><ul><li>Tienen un bajo mantenimiento </li></ul></ul><ul><ul><li>Son ideales para proyectos con requerimientos cambiantes o no muy claros </li></ul></ul>
    30. 30. T x 5 – XP User Stories: limitaciones e inconvenientes <ul><li>Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones </li></ul><ul><li>Se requiere un contacto permanente con el cliente durante el proyecto, lo cuál puede llegar a ser algo difícil o costoso </li></ul><ul><li>Puede resultar difícil escalar a proyectos o equipos grandes </li></ul>
    31. 31. T x 5 – XP User Stories vs. IEEE 830 <ul><li>El IEEE publicó un conjunto de directrices sobre cómo escribir las especificaciones de los requerimientos software </li></ul><ul><li>Este documento, conocido como IEEE Standard 830, fue revisado en 1998 </li></ul><ul><li>Sus recomendaciones abarcan como organizar el documento de especificación de requisitos, el papel del prototipado o las características de unos buenos requermientos </li></ul><ul><li>Un documento que siga este estándar se caracteriza por el uso de frases “El sistema…”, ya que es la forma recomendada para escribir los requisitos funcionales </li></ul><ul><li>Documentar los requisitos de un sistema a este nivel es tedioso, propenso a errores y muy laborioso </li></ul><ul><li>Eso por no mencionar que con documentos de este tipo hay que acabar asumiendo que no serán leídos por todas las personas que deberían, que los acusan de “aburridos” </li></ul><ul><li>Incluso aunque un usuario, p.ej., lea 100 hojas en lugar de ojearlas y no se salte nada, con un documento escrito a este nivel es muy difícil poder entender “la foto global” </li></ul>
    32. 32. T x 5 – XP User Stories vs. Use Cases I <ul><li>Los casos de uso fueron introducidos por primera vez por Ivar Jacobson en 1992 </li></ul><ul><li>Un caso de uso es una descripción de un conjunto de interacciones entre el sistema y uno o más actores, dónde un actor puede ser un usuario u otro sistema </li></ul><ul><li>Hoy en día, los casos de uso están principalmente asociados al proceso unificado (UP) </li></ul><ul><li>Los casos de uso pueden ser escritos de forma no estructurada o siguiendo una plantilla, siendo las más utilizadas las propuestas por Alistair Cockburn </li></ul><ul><li>ausrInformaticaComunDesarrolloDocumentacionPlantillas WordOtrosAlistair Cockburn </li></ul><ul><li>ausrInformatica ComunDesarrolloDocumentacionPlantillas WordOtrosVicoDescripcion Use Cases </li></ul><ul><li>ausrInformaticaComunDesarrolloDocumentacionPlantillas WordProceso de desarrollo </li></ul><ul><li>Hay varios grados de formalidad al escribir un caso de uso: breve, informal y completo </li></ul>
    33. 33. T x 5 – XP User Stories vs. Use Cases y II <ul><li>Ambos describen escenarios y, si están bien escritos, deben añadir lo que se conoce como “valor cuantificable al negocio”. Sin embargo hay diferencias: </li></ul><ul><ul><li>Ámbito: </li></ul></ul><ul><ul><ul><li>Las historias de usuario suelen tener un ámbito más pequeño que un caso de uso debido a las restricciones que ponemos a su tamaño (e. j.: no más de una semana de desarrollo) </li></ul></ul></ul><ul><ul><li>Grado de completado: </li></ul></ul><ul><ul><ul><li>“ Text on a story card plus acceptance tests are basically the same thing as a use case.” – James Grenning </li></ul></ul></ul><ul><ul><ul><li>(e. d., que la historia es el camino feliz de un caso de uso y los tests de aceptación las extensiones) </li></ul></ul></ul><ul><ul><li>Longevidad: </li></ul></ul><ul><ul><ul><li>Los casos de uso son más longevos y continúan existiendo durante el desarrollo e incluso el mantenimiento. Las historias de usuario, en cambio, no suelen sobrevivir a su iteración </li></ul></ul></ul><ul><ul><li>Detalles (relativos al UI): </li></ul></ul><ul><ul><ul><li>Los casos de uso son más propensos a incluir detalles sobre el interfaz de usuario (prototipos), a pesar de que muchos autores lo desaconsejan </li></ul></ul></ul><ul><ul><li>Propósito: </li></ul></ul><ul><ul><ul><li>Los casos de uso son escritos en un formato comprensible para que clientes y desarrolladores trabajen con ellas y lleguen a un acuerdo </li></ul></ul></ul><ul><ul><ul><li>Las historias de usuario, en cambio, son escritas para facilitar la planificación de las iteraciones y sirven como “recordatorio” para las conversaciones sobre las necesidades de los usuarios </li></ul></ul></ul>
    34. 34. T x 5 – XP CCPPT: User Stories <ul><li>El responsable comercial puede crear un corte de cadena nuevo a partir de un corte efectivo realizado mediante el simulador de cortes. </li></ul><ul><li>El responsable comercial puede buscar las fechas de corte de los cortes efectivos, realizados mediante el simulador de cortes, asociados a una campaña. </li></ul><ul><li>El responsable comercial puede suscribir países a un corte de cadena. </li></ul><ul><li>El responsable comercial puede publicar un corte de cadena no publicado. </li></ul><ul><li>El responsable comercial puede publicar un corte de cadena ya publicado con países suscritos agregados. </li></ul><ul><li>El responsable comercial puede consultar en qué estado se encuentra un corte de cadena y sus cortes de país sugeridos asociados. </li></ul><ul><li>Un comercial puede validar corte de países sugeridos (incluso aunque los comerciales responsables de los países sean otros). </li></ul><ul><li>Un comercial puede eliminar referencias a recortar de un corte de país sugerido. </li></ul><ul><li>Un comercial puede rebajar el precio de venta nuevo de referencias de un corte de país sugerido. </li></ul><ul><li>Un comercial puede aumentar el precio de venta nuevo de referencias de un corte de país sugerido. </li></ul><ul><li>Dos días antes de la fecha de corte de un corte de cadena, se informará a comercial si éste tiene cortes de país sugeridos pendientes de validar. </li></ul><ul><li>. </li></ul><ul><li>. </li></ul><ul><li>. </li></ul>
    35. 35. T x 5 – XP ATDD I <ul><li>¿Cómo podemos garantizar que …? </li></ul><ul><ul><li>El objetivo se ha entendido bien (análisis) : </li></ul></ul><ul><ul><li>que si el objetivo es A, no entendemos A’ </li></ul></ul><ul><ul><li>La implementación se ajusta al objetivo (desarrollo) : </li></ul></ul><ul><ul><li>que si el objetivo es A y entendimos A, no acabamos implementando A’ </li></ul></ul><ul><ul><li>La implementación se mantiene ajustada al objetivo (mantenimiento) : </li></ul></ul><ul><ul><li>que si el objetivo fue A y en su momento implementamos A, los cambios posteriores no acaben convirtiendo la implementación en A’ </li></ul></ul><ul><li>RE: Tests de aceptación (ATDD) </li></ul>
    36. 36. T x 5 – XP ATDD II
    37. 37. T x 5 – XP ATDD III <ul><li>Están basados en ejemplos de historias de usuario </li></ul><ul><li>Son escritos antes del desarrollo y por el propio cliente (o por “alguien” en estricta colaboración con él) </li></ul><ul><li>Forman parte de la definición del “completado” </li></ul><ul><li>¡Normalmente son automatizados! </li></ul>
    38. 38. T x 5 – XP ATDD y IV <ul><li>http ://www.concordion.org/Example.html </li></ul><ul><li>http://www.concordion.org/Tutorial_es.html </li></ul>
    39. 39. T x 5 – XP CCPPT: Acceptance Tests <ul><li>User Story: El responsable comercial puede suscribir países a un corte de cadena. </li></ul><ul><ul><li>Verificar que un corte de cadena no publicado no tiene países suscritos. </li></ul></ul><ul><ul><li>Verificar que un corte de cadena no publicado no tiene países pendientes de suscribir. </li></ul></ul><ul><ul><li>Verificar que suscribir un país no pendiente de suscribir a un corte de cadena no publicado, lo registra como pendiente de suscribir. </li></ul></ul><ul><ul><li>Verificar que suscribir un país ya pendiente de suscribir a un corte de cadena no publicado, &quot;no hace nada&quot;. </li></ul></ul><ul><ul><li>Verificar que suscribir un país no pendiente de suscribir y no suscrito a un corte de cadena publicado, lo registra como pendiente de suscribir. </li></ul></ul><ul><ul><li>Verificar que suscribir un país ya pendiente de suscribir a un corte de cadena publicado, &quot;no hace nada&quot;. </li></ul></ul><ul><ul><li>Verificar que suscribir un país ya suscrito a un corte de cadena publicado, &quot;no hace nada&quot;. </li></ul></ul>
    40. 40. T x 5 – XP TDD I <ul><li>“ Test-Driven Development (TDD) is a deceptively simple idea: </li></ul><ul><li>write the tests for your code before writing the code itself. </li></ul><ul><li>We say “deceptively simple” because this transforms the role testing plays in the development process and challenges our industry’s assumptions about what testing is for. </li></ul><ul><li>Testing is no longer just about keeping defects from the users; instead, it’s about helping the team to understand the features that the users need and to deliver those features reliably and predictably. </li></ul><ul><li>When followed to its conclusions, TDD radically changes the way we develop software and, in our experience, dramatically improves the quality of the systems we build, in particular their reliability and their flexibility in response to new requirements.” </li></ul><ul><li>“ Growing Object-Oriented Software, Guided by Tests” – Steve Freeman & Nat Pryce </li></ul><ul><li>Del texto anterior se puede “deducir” algo más: </li></ul><ul><li>TDD – como mucha gente piensa – es “un mal nombre”, ya que se trata de una práctica de programación y no de una técnica de testing </li></ul><ul><li>(Peter Provost, Carlos Blé, …) </li></ul>
    41. 41. T x 5 – XP TDD II <ul><li>“ Of all the Agile methods, XP is the only method that provides deep and profound disciplines for the way developers do their daily work. </li></ul><ul><li>Of those disciplines, Test Driven Development is the most revolutionary and impactful. ” </li></ul><ul><li>http://objectmentor.com/omSolutions/agile_xp_differences.html – Robert C. Martin </li></ul><ul><li>“ TDD es la respuesta a las grandes preguntas de: </li></ul><ul><li> ¿Cómo lo hago? </li></ul><ul><li> ¿Por dónde empiezo? </li></ul><ul><li> ¿Cómo sé qué es lo que hay que implementar y lo que no? </li></ul><ul><li> ¿Cómo escribir un código que se pueda modificar sin romper funcionalidad existente? ” </li></ul><ul><li>“ Diseño ágil con TDD” – Carlos Blé Jurado </li></ul><ul><li>Una vez “aclarado” esto, y sobre la importancia del propio testing: </li></ul><ul><li>“ If it ain’t tested, it’s broken.” </li></ul><ul><li>(si no está probado, está roto) </li></ul><ul><li>Bruce Eckel (autor de “Thinking in Java”) </li></ul>
    42. 42. T x 5 – XP TDD y III <ul><li>El testing sucede a varios niveles: </li></ul><ul><ul><li>“ Acceptance Tests”, para determinar si un sistema cumple con los requerimientos del cliente (ATDD) </li></ul></ul><ul><ul><li>“ Unit Tests”, para determinar si los componentes individuales del software cumplen los requerimientos funcionales </li></ul></ul><ul><ul><li>“ Integration Tests”, para determinar si el software encaja en el entorno y la infraestructura y si dos componentes o más trabajan bien juntos </li></ul></ul>
    43. 43. T x 5 – XP Críticas a XP I <ul><li>“ PP no puede funcionar: muchos programadores tienen gran sentimiento de posesión del código, piensan son los mejores conocedores de las herramientas y lenguajes que usan y que si alguien no lo entiende es que no sabe suficiente.” </li></ul><ul><ul><li>“ While pair programming may sound tremendously inefficient, Alistair Cockburn and Laurie Williams (2001) have studied it and found that not to be the case. They found that for a 15% increase in total programming time, pair programming leads to: </li></ul></ul><ul><ul><li>- lower defect counts, </li></ul></ul><ul><ul><li>- less code is written to solve the same problem, </li></ul></ul><ul><ul><li>- problems being solved more quickly, </li></ul></ul><ul><ul><li>- more people understand each piece of code and </li></ul></ul><ul><ul><li>- an increase in developer job satisfaction” </li></ul></ul><ul><ul><li>“ User Stories Applied” – Mike Cohn </li></ul></ul>
    44. 44. T x 5 – XP Críticas a XP y II <ul><li>“ El mito de las 40 horas semanales es un lujo para las exigencias del mercado” </li></ul><ul><li>“ XP sólo puede funcionar con programadores muy buenos, como Kent Beck, capaces de hacer un buen diseño, sencillo y fácilmente extensible” </li></ul><ul><li>“ XP es mas una filosofía de trabajo que una metodología” </li></ul><ul><li>“ Ninguna de las practicas defendidas por XP son invención de este método; XP lo que único hace es ponerlas todas juntas” </li></ul><ul><li>“ XP esta pensado para grupos de pequeños programadores, más de 10 ya seria muy complicado, y mas aún si no están en el mismo centro de trabajo” </li></ul><ul><li>“ XP / Agile = Cowboy Programming” </li></ul>
    45. 45. T x 5 – XP Bajando el telón I <ul><li>Otros recursos: </li></ul><ul><ul><li>“ Test Driven Development Primer with Peter Provost” (inglés subtitulado) http://www.youtube.com/watch?v=JMEO6T6gkAA </li></ul></ul><ul><ul><li>“ Antipatrones en TDD” http://www.carlosble.com /?p=225 </li></ul></ul><ul><ul><li>“ Bowling” (¡muy, muy recomendable!) http://www.objectmentor.com/resources/articles/xpepisode.htm </li></ul></ul>
    46. 46. T x 5 – XP Bajando el telón II <ul><li>Recomendaciones: </li></ul><ul><ul><li>TDD sí y ahora; XP “no” aún – no de forma completa e inmediata (p. ej. no Integration Continuous o Pair Programming) </li></ul></ul><ul><ul><li>“ Cry in the Dojo, laugh on the battlefield” (“Llora en el dojo, ríe en el campo de batalla”) </li></ul></ul><ul><ul><ul><li>Es un proverbio japonés adoptado en el Aikido </li></ul></ul></ul><ul><ul><ul><li>Guarda relación con la disciplina que requiere dicha arte marcial </li></ul></ul></ul><ul><ul><ul><li>Aquí, se refiere a “llorar” en las sesiones de Tx5 para poder “reír” en los proyectos </li></ul></ul></ul>
    47. 47. T x 5 – XP Sumario I <ul><li>Metodologías ágiles: </li></ul><ul><ul><li>Procesos iterativos e incrementales: se entrega periódicamente (iteración) un producto al cliente </li></ul></ul><ul><ul><li>(producto= subjconjunto con calidad de producción del sistema final; no prototipo ) </li></ul></ul><ul><ul><li>Enfocados a mitigar el riesgo </li></ul></ul>
    48. 48. T x 5 – XP Sumario y II <ul><li>XP: </li></ul><ul><ul><li>Metodología de desarrollo ágil </li></ul></ul><ul><ul><li>Busca un punto medio entre ningún proceso y demasiado proceso </li></ul></ul><ul><ul><li>Características: </li></ul></ul><ul><ul><ul><li>El cambio es bienvenido </li></ul></ul></ul><ul><ul><ul><li>Orientado a la gente y no al proceso </li></ul></ul></ul><ul><ul><ul><li>Menos orientado al documento </li></ul></ul></ul><ul><ul><ul><li>(exige una cantidad más pequeña de documentación para una tarea dada; la parte importante de la documentación es el propio código fuente más los tests) </li></ul></ul></ul><ul><ul><ul><li>Realizar las grandes decisiones lo antes posible en el tiempo para diferir su coste (cuánto más tarde se realice un cambio, mayor coste tendrá su implementación) </li></ul></ul></ul>Coste del cambio en los modelos basados en el ciclo de vida en cascada Fuente : http://osl.iu.edu/~lums/swc/www/swc.html (la gráfica equivalente en XP es menos pronunciada, casi lineal)
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×