Your SlideShare is downloading. ×
0
Métodos Ágiles en desarrollo de software Carlos Reynoso UNIVERSIDAD DE BUENOS AIRES [email_address] http://www.microsoft.c...
Agenda <ul><li>Contexto de situación </li></ul><ul><li>Manifiesto ágil </li></ul><ul><li>Tabla de Métodos ágiles </li></ul...
Contexto de situación <ul><li>Descrédito de los procesos en cascada </li></ul><ul><ul><li>DOD STD 2167    MIL STD 498 </l...
Contexto de situación <ul><li>Surgimiento de ideas caórdicas </li></ul><ul><ul><li>No linealidad: El mítico hombre-mes (Br...
Manifiesto ágil http://agilemanifesto.org <ul><ul><li>Estamos poniendo al descubierto formas mejores de desarrollo de soft...
Manifiesto ágil http://agilemanifesto.org <ul><ul><li>Kent Beck (XP), Mike Beedle, Arie van Bennekum (DSDM), Alistair Cock...
Métodos ágiles
Híbridos <ul><li>Enterprise XP (DSDM + XP) - Mike Griffiths </li></ul><ul><li>XP@Scrum - Scrum </li></ul><ul><li>Xbreed (X...
Constantes de los MAs <ul><li>Surge en libros con impacto en la industria y en el público, no en  papers </li></ul><ul><li...
Ideas caórdicas en MAs <ul><li>Scrum: conceptos de filo del caos y control de caos </li></ul><ul><li>Scrum: http//www.cont...
 
 
Ideas caórdicas en MAs <ul><li>Fred Brooks: no linealidad [MMM] </li></ul><ul><li>Jeff DeLuca (FDD): afinidad con caos det...
Ideas caórdicas en MAs <ul><li>Kent Beck: “las raíces de XP se encuentran en la teoría de los sistemas complejos” </li></u...
Acrónimos y jerga <ul><li>Scrum , gallinas, cerdos, corridas ( sprints ), pre-juego, juego y pos-juego (Scrum) - Púas ( sp...
eXtreme Programming <ul><li>Método ágil basado en cuatro principios: </li></ul><ul><li>simplicidad, comunicación, retroali...
¿Prácticas independientes?
Programación por pares ( pair programming ) <ul><li>Todo el código es escrito por parejas de programadores </li></ul><ul><...
Pruebas <ul><li>T est  D riven  D evelopment </li></ul><ul><ul><li>Diseño e implementación de las pruebas antes de program...
Semana de 40 horas <ul><li>El desarrollo de software es un ejercicio creativo </li></ul><ul><ul><li>hay que estar fresco y...
Lugar de trabajo <ul><li>Sala amplia (mejor, sin divisiones) </li></ul><ul><ul><li>Centro: pares de programadores </li></u...
Juego de planificación ( planning game ) <ul><li>Determinar rápidamente el alcance de la próxima versión  </li></ul><ul><u...
Story Cards
Cliente en el sitio <ul><li>Interacción continua </li></ul><ul><li>No siempre se consigue </li></ul><ul><ul><li>muy junior...
Propiedad colectiva del código <ul><li>Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del cód...
Diseño simple, entregas pequeñas <ul><li>Se debe mantener el diseño lo mas simple posible (YAGNI): “No vas a necesitarlo” ...
Tarjetas CRC <ul><li>Clase – Responsabilidad – Colaboración  </li></ul>
Refactorización <ul><li>Si el código se está volviendo complicado </li></ul><ul><ul><li>modificar el diseño, volver a uno ...
Metáfora <ul><li>Reemplaza a la arquitectura </li></ul><ul><li>“ Historia compartida sobre cómo funciona todo el sistema” ...
Ciclo de vida
XP - Síntesis Prácticas conjuntas Iteraciones Vocabulario Común – Reemplaza a Metáforas Espacio de trabajo abierto Retrosp...
Scrum <ul><li>Primera referencia: Takeuchi-Nonaka, 1986,  The New Product Development Game </li></ul><ul><li>En software, ...
Principios de Scrum <ul><li>       Equipos auto-dirigidos y auto-organizados. No hay  manager  que decida, ni otros t í t...
Ciclo de Scrum
Artefactos de Scrum <ul><li>Acumulación (backlog) de producto </li></ul><ul><li>Acumulación de carrera (o “corrida”) </li>...
Prácticas de Scrum <ul><li>Al fin de cada iteraci ó n de treinta d í as hay una demostraci ó n a cargo del Scrum Master.  ...
Otros métodos: FDD <ul><li>Feature Driven Development (FDD)  [DeLuca, Coad] </li></ul><ul><ul><li>No FOP, pero sí Desarrol...
Feature Driven Development (FDD) <ul><li>No cubre todo el ciclo de vida, sino diseño y construcción </li></ul><ul><li>Se c...
Feature Driven Development (FDD) <ul><li>Ciclo de vida </li></ul>
Feature Driven Development (FDD)
Feature Driven Development (FDD) <ul><li>FDD es un m é todo de desarrollo de ciclos cortos que se concentra en la fase de ...
DSDM <ul><li>Método estándar en Gran Bretaña </li></ul><ul><ul><li>Prácticas escalables - Reglas MoSCoW  [Must, Should, Co...
Adaptive Software Development <ul><li>James Highsmith III, consultor de Cutter Consortium, desarroll ó  ASD hacia el 2000 ...
Ciclo de ASD
Adaptive Software Development <ul><li>Auto-organizaci ó n, adaptaci ó n al cambio y  orden emergente </li></ul><ul><li>Ana...
Lean Development <ul><li>Lean: magro, enjuto – James Womack, 1990,  La máquina que cambió al mundo </li></ul><ul><li>Patro...
Lean Development <ul><li>Igual que Agile Modeling, que cubr í a aspectos de modelado y documentaci ó n, LD y LSD han sido ...
Evo <ul><li>Competitive Engineering – Tom & Kai Gilb </li></ul><ul><ul><li>Planguage </li></ul></ul><ul><ul><ul><li>Vincul...
Evo
Planguage <ul><ul><ul><li>CUSTOMER.SATISFACTION </li></ul></ul></ul><ul><ul><ul><li>SCALE: evaluación promedio de la satis...
Métodos ágiles en MSF <ul><li>Fuerte tradición de desarrollo ágil en MS </li></ul><ul><ul><li>Steve McConnell,  Code Compl...
Métodos ágiles en MSF <ul><li>Microsoft Solutions Framework </li></ul><ul><ul><li>En evolución desde 1994 </li></ul></ul><...
Métodos ágiles en MSF <ul><li>8 principios: </li></ul><ul><ul><ul><li>Alentar comunicaciones abiertas (Brooks) </li></ul><...
Críticas a Métodos Ágiles <ul><li>Rakitin, 2001 – Argumento  hacker </li></ul><ul><li>Pete McBreen, 2002 – Questioning XP ...
Herramientas para desarrollo ágil <ul><li>Patterns & Practices </li></ul><ul><li>Prueba de Unidad </li></ul><ul><ul><li>CO...
Herramientas para desarrollo ágil <ul><li>Refactorización </li></ul><ul><ul><li>C# Refactoring Tool 1.5.1 </li></ul></ul><...
Creencias insostenibles <ul><li>Es posible diagramar a priori y en detalle la totalidad del ciclo de vida y sus artefactos...
Conclusiones <ul><li>Distintas categorías de métodos ágiles </li></ul><ul><li>Los métodos ágiles son fundamentalmente comb...
Estado de la cuestión <ul><li>Los métodos ágiles llegaron para quedarse, aunque la histeria se está moderando  </li></ul><...
Vínculos y referencias <ul><li>Reynoso/Kicillof en MSDN en Español: </li></ul><ul><ul><li>http://www.microsoft.com/spanish...
Vínculos y referencias <ul><li>Ron Jeffries -  Extreme Programming adventures in C#.  MS Press, 2004 </li></ul><ul><li>Tom...
¿ Preguntas ? Billy Reynoso UNIVERSIDAD DE BUENOS AIRES [email_address]
Upcoming SlideShare
Loading in...5
×

Metodos agiles

3,930

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,930
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
49
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Metodos agiles"

  1. 1. Métodos Ágiles en desarrollo de software Carlos Reynoso UNIVERSIDAD DE BUENOS AIRES [email_address] http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/arquitectura_soft.mspx
  2. 2. Agenda <ul><li>Contexto de situación </li></ul><ul><li>Manifiesto ágil </li></ul><ul><li>Tabla de Métodos ágiles </li></ul><ul><li>eXtreme Programming (XP) </li></ul><ul><li>Otros métodos ágiles </li></ul><ul><li>Métodos ágiles & MSF 3.0 </li></ul><ul><li>Críticas a Métodos Ágiles </li></ul><ul><li>Conclusiones – Estado de la cuestión </li></ul><ul><li>Referencias y recursos </li></ul><ul><li>http://www.microsoft.com/spanish/msdn/arquitectura </li></ul>
  3. 3. Contexto de situación <ul><li>Descrédito de los procesos en cascada </li></ul><ul><ul><li>DOD STD 2167  MIL STD 498 </li></ul></ul><ul><li>Crisis de confianza en los procesos regidos por metodologías prescriptivas con análisis completo de requerimientos y planificación detallada </li></ul><ul><ul><li>CMM, CMMI, Spice, Bootstrap, TickIt, ISO 9000 </li></ul></ul><ul><li>CMM no es una metodología ni un modelo en cascada, pero “coincide con su espíritu” </li></ul><ul><li>Legislación negativa sobre conformidad con estándares de calidad </li></ul>
  4. 4. Contexto de situación <ul><li>Surgimiento de ideas caórdicas </li></ul><ul><ul><li>No linealidad: El mítico hombre-mes (Brooks) </li></ul></ul><ul><ul><li>Orden a partir del caos (Kauffman, Hock) </li></ul></ul><ul><ul><li>Sistemas adaptativos complejos (Holland) </li></ul></ul><ul><ul><ul><li>Dinámica no lineal, sensitividad a las condiciones iniciales (“efecto mariposa”), autómatas celulares, redes booleanas aleatorias (“orden gratis”) </li></ul></ul></ul><ul><ul><li>Auto-organización (B. Boehm) </li></ul></ul><ul><ul><li>Modelo y ciclo de vida en Estrategia del Caos (Raccoon, 1995) </li></ul></ul>
  5. 5. Manifiesto ágil http://agilemanifesto.org <ul><ul><li>Estamos poniendo al descubierto formas mejores de desarrollo de software, haciéndolo y ayudando a otros a que lo hagan. A través de este trabajo hemos llegado a valorar: </li></ul></ul><ul><ul><ul><li>Los individuos y la interacción por encima de los procesos y herramientas . </li></ul></ul></ul><ul><ul><ul><li>El software que funciona por encima de la documentación abarcadora . </li></ul></ul></ul><ul><ul><ul><li>La colaboración con el cliente por encima de la negociación contractual . </li></ul></ul></ul><ul><ul><ul><li>La respuesta al cambio por encima del seguimiento de un plan . </li></ul></ul></ul><ul><ul><li>Aunque hay valor en los elementos a la derecha, valorizamos más los de la izquierda. </li></ul></ul>
  6. 6. Manifiesto ágil http://agilemanifesto.org <ul><ul><li>Kent Beck (XP), Mike Beedle, Arie van Bennekum (DSDM), Alistair Cockburn (Crystal), Ward Cunningham (XP), Martin Fowler (XP), James Grenning (XP), Jim Highsmith (ASD), Andrew Hunt (Pragmatic Programming), Ron Jeffries (XP), Jon Kern (FDD), Brian Marick, Robert C. Martin (XP), Steve Mellor, Ken Schwaber (Scrum), Jeff Sutherland (Scrum) y Dave Thomas (Pragmatic Programming) </li></ul></ul>
  7. 7. Métodos ágiles
  8. 8. Híbridos <ul><li>Enterprise XP (DSDM + XP) - Mike Griffiths </li></ul><ul><li>XP@Scrum - Scrum </li></ul><ul><li>Xbreed (XP+Scrum) - Mike Beedle </li></ul><ul><li>Industrial XP - Industrial Logic </li></ul><ul><li>Dispersed Extreme Programming (DXP) - Michael Kircher, Siemens </li></ul><ul><li>Dispersed Development - Alan Cameron Wills (MS), FastnLoose - Patrones para desarrollo ágil distribuido </li></ul><ul><li>Grizzly (“Large Agile”) - Ron Crocker, Motorola </li></ul><ul><li>Evo+XP, Evo+UP, Evo+Scrum, XP+UP, UP+Scrum </li></ul>
  9. 9. Constantes de los MAs <ul><li>Surge en libros con impacto en la industria y en el público, no en papers </li></ul><ul><li>Metodología simple y fácil de aprender </li></ul><ul><ul><li>Valores, Principios, Prácticas, Roles, Artefactos </li></ul></ul><ul><li>Equipos no jerárquicos y auto-organizados </li></ul><ul><li>Comunicación intensiva </li></ul><ul><li>Minimalismo </li></ul><ul><ul><li>Prescindencia de arquitectura y modelado </li></ul></ul><ul><li>Proceso iterativo e incremental </li></ul><ul><ul><li>Entregas rápidas </li></ul></ul><ul><li>Capacidad adaptativa </li></ul><ul><ul><li>Rápida respuesta al cambio </li></ul></ul>
  10. 10. Ideas caórdicas en MAs <ul><li>Scrum: conceptos de filo del caos y control de caos </li></ul><ul><li>Scrum: http//www.controlchaos.com </li></ul><ul><li>Microsoft implementa estrategias de caos controlado en procesos de desarrollo ( Microsoft secrets ) </li></ul><ul><li>MSF 3.0: referencia a la naturaleza caórdica de los procesos complejos (Dee Hock) </li></ul>
  11. 13. Ideas caórdicas en MAs <ul><li>Fred Brooks: no linealidad [MMM] </li></ul><ul><li>Jeff DeLuca (FDD): afinidad con caos determinista y teoría de la complejidad </li></ul><ul><li>Larman sobre Scrum: referencias a John Holland sobre auto-organización y procesos adaptativos </li></ul><ul><li>Jim Highsmith (Adaptive Software Development): control laxo, equilibrio en el filo del caos </li></ul><ul><li>Lean Development: analogía con sociedades de insectos y modelos de agentes adaptativos </li></ul>
  12. 14. Ideas caórdicas en MAs <ul><li>Kent Beck: “las raíces de XP se encuentran en la teoría de los sistemas complejos” </li></ul><ul><li>Barry Boehm : “la ingeniería de software deberá estudiar los sistemas adaptativos, el orden emergente, los agentes que se auto-organizan…” </li></ul><ul><li>Ideas de complejidad y caos en management y consultoría organizativa </li></ul><ul><li>Idem, en predicción financiera </li></ul>
  13. 15. Acrónimos y jerga <ul><li>Scrum , gallinas, cerdos, corridas ( sprints ), pre-juego, juego y pos-juego (Scrum) - Púas ( spikes ) (Scrum, XP) </li></ul><ul><li>“ El minimalismo es esencial”, “Todo se puede cambiar”, “Mejor 80% hoy que 100% mañana” (LD), “Mirando basura (LSD), “Refactorización implacable” (XP) </li></ul><ul><li>El Cono del Silencio, El Esqueleto Ambulante (CC) </li></ul><ul><li>YAGNI “ You Aren ’ t Gonna Need It ” ; TETCPB, “ Test Everything That Can Possibly Broke ” ; DTSTTCPW, “ Do The Simplest Thing That Can Possibly Work ” ; BUFD, “ Big Upfront Design ” . </li></ul><ul><li>GoF, POSA </li></ul><ul><li>“ Lo lamento por su vaca; no sabía que era sagrada” (Ron Jeffries) </li></ul><ul><li>“ Si funciona bien, arréglelo de todos modos” (Beck) </li></ul>
  14. 16. eXtreme Programming <ul><li>Método ágil basado en cuatro principios: </li></ul><ul><li>simplicidad, comunicación, retroalimentación, valor </li></ul><ul><li>Y varias prácticas: </li></ul><ul><li>juego de planeamiento, entregas pequeñas, metáforas, diseño simple, pruebas continuas, refactorización, programación por pares, propiedad colectiva, integración continua, semana de 40 horas, cliente en el sitio, estándares de codificación </li></ul>
  15. 17. ¿Prácticas independientes?
  16. 18. Programación por pares ( pair programming ) <ul><li>Todo el código es escrito por parejas de programadores </li></ul><ul><ul><li>una sola máquina con un teclado y un mouse </li></ul></ul><ul><li>No es un programador trabajando y el otro mirando </li></ul><ul><li>No es una sesión de aprendizaje para un programador junior </li></ul><ul><li>El que no está escribiendo </li></ul><ul><ul><li>piensa más estratégicamente </li></ul></ul><ul><ul><li>revisa el código en tiempo real </li></ul></ul><ul><li>Los roles se pueden cambiar varias veces durante el día </li></ul><ul><li>Fundamentos: </li></ul><ul><ul><li>dos programadores trabajando juntos son más efectivos que por separado </li></ul></ul><ul><ul><li>el conocimiento grupal crece más rápido </li></ul></ul><ul><ul><li>trabajar es más divertido </li></ul></ul>
  17. 19. Pruebas <ul><li>T est D riven D evelopment </li></ul><ul><ul><li>Diseño e implementación de las pruebas antes de programar la funcionalidad </li></ul></ul><ul><ul><li>El programador crea sus propios tests de unidad </li></ul></ul><ul><li>Integración continua </li></ul><ul><ul><li>Integración diaria </li></ul></ul><ul><ul><li>Disponer de una máquina para integración </li></ul></ul><ul><li>Tests funcionales </li></ul><ul><ul><li>Cliente </li></ul></ul>
  18. 20. Semana de 40 horas <ul><li>El desarrollo de software es un ejercicio creativo </li></ul><ul><ul><li>hay que estar fresco y descansado </li></ul></ul><ul><li>Sin “héroes” </li></ul><ul><li>Se reduce la rotación de personal </li></ul><ul><li>Mejora la calidad del producto </li></ul><ul><li>Se permiten excepciones, con cuidado </li></ul><ul><ul><li>más de una semana de horas extra: problema </li></ul></ul>
  19. 21. Lugar de trabajo <ul><li>Sala amplia (mejor, sin divisiones) </li></ul><ul><ul><li>Centro: pares de programadores </li></ul></ul><ul><ul><li>Periferia: máquinas individuales </li></ul></ul><ul><li>Ventajas del espacio abierto: </li></ul><ul><ul><li>mayor comunicación </li></ul></ul><ul><ul><li>agenda dinámica </li></ul></ul>
  20. 22. Juego de planificación ( planning game ) <ul><li>Determinar rápidamente el alcance de la próxima versión </li></ul><ul><ul><li>prioridades de negocio (cliente) </li></ul></ul><ul><ul><li>estimaciones técnicas (desarrolladores) </li></ul></ul><ul><li>¿Por qué juego? </li></ul><ul><ul><li>Objetivo: maximizar el valor del software producido </li></ul></ul><ul><ul><li>Estrategia: poner en producción las características más importantes lo antes posible </li></ul></ul><ul><ul><li>Piezas: story cards </li></ul></ul><ul><ul><li>Jugadores: desarrolladores y cliente </li></ul></ul><ul><ul><li>Movidas: Exploración, Selección y Actualización </li></ul></ul>
  21. 23. Story Cards
  22. 24. Cliente en el sitio <ul><li>Interacción continua </li></ul><ul><li>No siempre se consigue </li></ul><ul><ul><li>muy junior, no sirve </li></ul></ul><ul><ul><li>muy senior, no quiere </li></ul></ul><ul><li>Actualmente se pide un “analista” </li></ul>
  23. 25. Propiedad colectiva del código <ul><li>Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del código fuente </li></ul><ul><li>Todos son dueños del código </li></ul><ul><li>Siempre se utilizan estándares </li></ul><ul><li>Los tests siempre deben funcionar al 100% </li></ul><ul><li>Se integra con todo el sistema permanentemente </li></ul><ul><li>Manejo de configuración </li></ul>
  24. 26. Diseño simple, entregas pequeñas <ul><li>Se debe mantener el diseño lo mas simple posible (YAGNI): “No vas a necesitarlo” </li></ul><ul><li>Tarjetas CRC </li></ul><ul><li>Design for change vs Design for today </li></ul><ul><ul><li>Características útiles en términos del negocio </li></ul></ul><ul><ul><li>No implementar características que no son necesarias </li></ul></ul><ul><li>Poner en producción lo antes posible </li></ul><ul><li>Unas pocas semanas por entrega </li></ul>
  25. 27. Tarjetas CRC <ul><li>Clase – Responsabilidad – Colaboración </li></ul>
  26. 28. Refactorización <ul><li>Si el código se está volviendo complicado </li></ul><ul><ul><li>modificar el diseño, volver a uno más simple </li></ul></ul><ul><li>Refactoring : modificar la forma del código sin cambiar su funcionamiento </li></ul><ul><ul><li>Ejemplos: extraer método, renombrar (clase, método, variable, etc.), reemplazar </li></ul></ul><ul><li>Hay herramientas </li></ul><ul><ul><li>C#Refactory (Xtreme Simplicity) </li></ul></ul>
  27. 29. Metáfora <ul><li>Reemplaza a la arquitectura </li></ul><ul><li>“ Historia compartida sobre cómo funciona todo el sistema” </li></ul><ul><li>Lenguaje común que todos puedan entender </li></ul><ul><ul><li>cliente </li></ul></ul><ul><ul><li>desarrolladores </li></ul></ul><ul><li>La metáfora puede cambiar permanentemente </li></ul>
  28. 30. Ciclo de vida
  29. 31. XP - Síntesis Prácticas conjuntas Iteraciones Vocabulario Común – Reemplaza a Metáforas Espacio de trabajo abierto Retrospectivas Prácticas de Programador Desarrollo orientado a pruebas Programación en pares Refactorización Propiedad colectiva Integración continua YAGNI (“No habrás de necesitarlo”) – Equivale a Diseño Simple Prácticas de Management Responsabilidad aceptada Cobertura aérea para el equipo Revisión trimestral Espejo – El manager debe comunicar un fiel reflejo del estado de cosas Ritmo sostenible Prácticas de Cliente Narración de historias Planeamiento de entrega Prueba de aceptación Entregas frecuentes
  30. 32. Scrum <ul><li>Primera referencia: Takeuchi-Nonaka, 1986, The New Product Development Game </li></ul><ul><li>En software, Jeff Sutherland, Ken Schwaber, 1995 </li></ul><ul><li>Aplica principios de procesos de control industrial, junto con experiencias metodol ó gicas de Microsoft, Borland y Hewlett-Packard </li></ul><ul><li>No es método independiente, sino complemento de otras metodologías (XP, MSF, RUP) </li></ul><ul><li>Enfatiza valores y prácticas de gestión, no cuestiones técnicas de desarrollo </li></ul>
  31. 33. Principios de Scrum <ul><li>       Equipos auto-dirigidos y auto-organizados. No hay manager que decida, ni otros t í tulos que “ miembros del equipo ” o “ cerdos ” ; la excepci ó n es el Scrum Master que debe ser 50% programador y que resuelve problemas, pero no manda. Los observadores externos se llaman “ gallinas ” ; pueden observar, pero no interferir ni opinar. </li></ul><ul><li>        Una vez elegida una tarea, no se agrega trabajo extra. En caso que se agregue algo, se recomienda quitar alguna otra cosa. </li></ul><ul><li>Encuentros diarios con las tres preguntas … Se realizan siempre en el mismo lugar, en c í rculo. El encuentro diario impide caer en el dilema se ñ alado por Fred Brooks: “¿ C ó mo es que un proyecto puede atrasarse un a ñ o?: Un d í a a la vez ” [Bro95]. </li></ul><ul><li>Iteraciones de treinta d í as; se admite que sean m á s frecuentes. </li></ul><ul><li>Demostraci ó n a participantes externos al fin de cada iteraci ó n. </li></ul><ul><li>Al principio de cada iteraci ó n, planeamiento adaptativo guiado por el cliente. </li></ul>
  32. 34. Ciclo de Scrum
  33. 35. Artefactos de Scrum <ul><li>Acumulación (backlog) de producto </li></ul><ul><li>Acumulación de carrera (o “corrida”) </li></ul>
  34. 36. Prácticas de Scrum <ul><li>Al fin de cada iteraci ó n de treinta d í as hay una demostraci ó n a cargo del Scrum Master. </li></ul><ul><li>Las presentaciones en PowerPoint est á n prohibidas. En los encuentros diarios, las gallinas deben estar fuera del c í rculo. </li></ul><ul><li>Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinar á a obras de caridad. </li></ul><ul><li>Es permitido usar artefactos de los m é todos a los que Scrum acompa ñ e, p. Ej. Listas de Riesgos si se utiliza UP, Planguage si el m é todo es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gesti ó n de Proyectos de MSF. </li></ul><ul><li>No es legal el uso de instrumentos como diagramas PERT , porque parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenar </li></ul><ul><li>El supuesto dominante es que el desarrollo es semi-ca ó tico , cambiante y tiene demasiado ruido como para que se le aplique un proceso definido. </li></ul>
  35. 37. Otros métodos: FDD <ul><li>Feature Driven Development (FDD) [DeLuca, Coad] </li></ul><ul><ul><li>No FOP, pero sí Desarrollo por Rasgo </li></ul></ul><ul><ul><ul><li>El seguimiento del progreso se realiza mediante examen de pequeñas funcionalidades descompuestas y funciones valoradas por el cliente. </li></ul></ul></ul><ul><ul><ul><li>Un rasgo es una función pequeña expresada en la forma <acción> < resultado > <por | para | de | a> <objeto> con los operadores adecuados entre los términos. Por ejemplo, calcular el importe total de una venta ; determinar la última operación de un cajero; validar la contraseña de un usuario . </li></ul></ul></ul>
  36. 38. Feature Driven Development (FDD) <ul><li>No cubre todo el ciclo de vida, sino diseño y construcción </li></ul><ul><li>Se considera apto para proyectos mayores o de misión crítica </li></ul><ul><li>Hay arquitectos en FDD </li></ul><ul><li>Numerosos artefactos para el control del proceso </li></ul>
  37. 39. Feature Driven Development (FDD) <ul><li>Ciclo de vida </li></ul>
  38. 40. Feature Driven Development (FDD)
  39. 41. Feature Driven Development (FDD) <ul><li>FDD es un m é todo de desarrollo de ciclos cortos que se concentra en la fase de dise ñ o y construcci ó n. </li></ul><ul><li>En la primera fase, el modelo global de dominio es elaborado por expertos del dominio y desarrolladores; </li></ul><ul><li>El modelo de dominio consiste en diagramas de clases con clases, relaciones, m é todos y atributos. </li></ul><ul><li>Los m é todos no reflejan conveniencias de programaci ó n sino rasgos funcionales. </li></ul>
  40. 42. DSDM <ul><li>Método estándar en Gran Bretaña </li></ul><ul><ul><li>Prácticas escalables - Reglas MoSCoW [Must, Should, Could, Want] </li></ul></ul>
  41. 43. Adaptive Software Development <ul><li>James Highsmith III, consultor de Cutter Consortium, desarroll ó ASD hacia el 2000 </li></ul><ul><li>Alternativa a la idea, propia de CMM Nivel 5, de que la optimizaci ó n es la ú nica soluci ó n para problemas de complejidad creciente. </li></ul><ul><li>Tercera v í a entre el “ desarrollo monumental de software ” y el “ desarrollo accidental ” , o entre la burocracia y la adhocracia. Deber í amos buscar m á s bien, afirma Highsmith, “ el rigor estrictamente necesario ” </li></ul><ul><li>Para ello hay que situarse en coordenadas apenas un poco fuera del caos y ejercer menos control que el que se cree necesario. </li></ul>
  42. 44. Ciclo de ASD
  43. 45. Adaptive Software Development <ul><li>Auto-organizaci ó n, adaptaci ó n al cambio y orden emergente </li></ul><ul><li>Analog í as con los sistemas adaptativos complejos por excelencia: los organismos vivientes (o sus an á logos digitales: redes neuronales auto-organizativas de Teuvo Kohonen y aut ó matas celulares). </li></ul><ul><li>Los proyectos de software son sistemas adaptativos complejos y la optimizaci ó n no hace m á s que sofocar la emergencia necesaria para afrontar el cambio. </li></ul><ul><li>Highsmith interpreta la organizaci ó n empresarial que emprende un desarrollo como si fuera un ambiente, sus miembros como agentes y el producto como el resultado emergente de relaciones de competencia y cooperaci ó n . </li></ul><ul><li>En los sistemas complejos no es aplicable el an á lisis , porque no puede deducirse el comportamiento del todo a partir de la conducta de las partes , ni sumarse las propiedades individuales para determinar las caracter í sticas del conjunto (ejemplo del agua) </li></ul>
  44. 46. Lean Development <ul><li>Lean: magro, enjuto – James Womack, 1990, La máquina que cambió al mundo </li></ul><ul><li>Patrones organizacionales </li></ul><ul><li>Herramientas de TQM( Edward Deming) </li></ul><ul><li>Software: Bob Charette, 2001 </li></ul><ul><li>No se limita al proceso de desarrollo – Hay que conocer el negocio de punta a punta </li></ul>
  45. 47. Lean Development <ul><li>Igual que Agile Modeling, que cubr í a aspectos de modelado y documentaci ó n, LD y LSD han sido pensados como complemento de otros m é todos, y no como una metodolog í a excluyente. </li></ul><ul><li>LD prefiere concentrarse en las premisas y modelos derivados de Lean Production (canon de la Escuela de Negocios de Harvard). </li></ul><ul><li>Para las t é cnicas concretas de programaci ó n, LD promueve el uso de otros MAs que sean consistentes con su visi ó n, como XP </li></ul>
  46. 48. Evo <ul><li>Competitive Engineering – Tom & Kai Gilb </li></ul><ul><ul><li>Planguage </li></ul></ul><ul><ul><ul><li>Vincula todas las disciplinas de SE </li></ul></ul></ul><ul><ul><ul><li>Expresa objetivos, estrategia, diseño y riesgo </li></ul></ul></ul><ul><ul><ul><li>Basado en Plan-Do-Study-Act (Deming, Juran, Shewhart) </li></ul></ul></ul><ul><ul><li>Lenguaje de especificación Planguage </li></ul></ul><ul><ul><ul><li>Descripción de requerimientos, diseños y planes </li></ul></ul></ul><ul><ul><li>Métodos Planguage </li></ul></ul><ul><ul><ul><li>Especificación de requerimiento, con atributos cuantificados </li></ul></ul></ul><ul><ul><ul><li>Estimación de impacto: implementación vs requerimiento y evaluación de progreso </li></ul></ul></ul><ul><ul><ul><li>Control de calidad de especificación (SQC - Excel) </li></ul></ul></ul><ul><ul><ul><li>Evolutionary Project Management: pasos pequeños (2%) evolutivos de alto valor </li></ul></ul></ul>
  47. 49. Evo
  48. 50. Planguage <ul><ul><ul><li>CUSTOMER.SATISFACTION </li></ul></ul></ul><ul><ul><ul><li>SCALE: evaluación promedio de la satisfacción de un cliente, de 1 a 5, siendo 1 la peor y 5 la mejor </li></ul></ul></ul><ul><li>PAST [2003] 2.5 </li></ul><ul><li>GOAL [2004] 3.5 </li></ul><ul><li>Tom Gilb es el creador de la idea de “métricas de software” </li></ul>
  49. 51. Métodos ágiles en MSF <ul><li>Fuerte tradición de desarrollo ágil en MS </li></ul><ul><ul><li>Steve McConnell, Code Complete (1993) </li></ul></ul><ul><ul><ul><li>Programación en pares </li></ul></ul></ul><ul><ul><li>Steve McConnell, Rapid Development (1996) </li></ul></ul><ul><ul><ul><li>Modelo de ciclo de vida evolutivo, encuentros y talleres de equipo, revisiones frecuentes, diseño para el cambio, entrega evolutiva, reutilización, prototipado evolutivo, comunicación intensa, desarrollo iterativo e incremental </li></ul></ul></ul><ul><ul><ul><li>No ágil : recomendación de establecer metas fijas de antemano, contratar a terceros para realizar parte del código ( outsourcing ), trabajar en oficinas privadas, ofrecerse a permanecer horas extraordinarias - Oposición de McConnell a XP </li></ul></ul></ul><ul><ul><li>Ron Jeffries & Ward Cunningham </li></ul></ul>
  50. 52. Métodos ágiles en MSF <ul><li>Microsoft Solutions Framework </li></ul><ul><ul><li>En evolución desde 1994 </li></ul></ul><ul><ul><li>“ Conjunto de principios, modelos, disciplinas, conceptos, lineamientos y prácticas probadas” </li></ul></ul><ul><ul><li>http://www.microsoft.com/technet/itsolutions/techguide/msf/msfovrvw.mspx </li></ul></ul><ul><ul><li>Explícitamente definido como framework apto para métodos ágiles </li></ul></ul><ul><ul><li>Modelo de Procesos iterativo e incremental, con participación activa del cliente </li></ul></ul><ul><ul><li>Probado en combinación con métodos ágiles </li></ul></ul><ul><ul><ul><li>Agile Modeling (Ambler) </li></ul></ul></ul><ul><ul><ul><li>DSDM - Documento conjunto de coordinación </li></ul></ul></ul><ul><ul><ul><li>RUP </li></ul></ul></ul><ul><ul><ul><li>Evolutionary Project Management - Best practices </li></ul></ul></ul>
  51. 53. Métodos ágiles en MSF <ul><li>8 principios: </li></ul><ul><ul><ul><li>Alentar comunicaciones abiertas (Brooks) </li></ul></ul></ul><ul><ul><ul><li>Trabajar hacia una visión compartida (Highsmith) </li></ul></ul></ul><ul><ul><ul><li>Otorgar poder a los miembros del equipo </li></ul></ul></ul><ul><ul><ul><li>Establecer responsabilidad clara y compartida </li></ul></ul></ul><ul><ul><ul><li>Concentrarse en la entrega de valor de negocios </li></ul></ul></ul><ul><ul><ul><li>Permanecer ágil, esperar el cambio (Highsmith) </li></ul></ul></ul><ul><ul><ul><li>Invertir en calidad </li></ul></ul></ul><ul><ul><ul><li>Aprender de todas las experiencias </li></ul></ul></ul>
  52. 54. Críticas a Métodos Ágiles <ul><li>Rakitin, 2001 – Argumento hacker </li></ul><ul><li>Pete McBreen, 2002 – Questioning XP </li></ul><ul><li>McConnell, 2002 – Hipnosis colectiva, one size fits all , programación sin diseño </li></ul><ul><li>Stephens-Rosenberg, 2003 – XP Refactored </li></ul><ul><li>Ed Berard, 2003 – “Falacias” </li></ul><ul><li>Gerold Keffer, 2003 – XP considered harmful. . (Escalabilidad, casos, programación de garage, TDD caro, reusabilidad, pero no COTS) </li></ul><ul><li>Mellor, Smith – Consignas estridentes, artefactos no reconocidos </li></ul>
  53. 55. Herramientas para desarrollo ágil <ul><li>Patterns & Practices </li></ul><ul><li>Prueba de Unidad </li></ul><ul><ul><li>COMUnit - SourceForge, VB.NET & C# </li></ul></ul><ul><ul><li>Nunit 2.1.4 </li></ul></ul><ul><ul><li>csUnit </li></ul></ul><ul><ul><li>vbUnit 3 - Visual Basic .NET </li></ul></ul><ul><ul><li>.TEST - Parasoft Software - Soporta NUnit </li></ul></ul><ul><ul><li>HarnessIt™ - UnitTesting.com - Prueba de unidad para lenguajes CLR </li></ul></ul><ul><ul><li>Unite.NET - Ascentiv - Prueba de unidad e integración - Independiente de lenguaje </li></ul></ul>
  54. 56. Herramientas para desarrollo ágil <ul><li>Refactorización </li></ul><ul><ul><li>C# Refactoring Tool 1.5.1 </li></ul></ul><ul><ul><li>Opnieuw - SourceForge, C# </li></ul></ul><ul><ul><li>Extreme Simplicity C# Refactory - VB Refactory </li></ul></ul><ul><ul><li>ReSharper - JetBrains! C# Refactoring Tool </li></ul></ul><ul><ul><li>C# 2.0 Whidbey - Refactoring nativo </li></ul></ul><ul><ul><li>GeneXus </li></ul></ul>
  55. 57. Creencias insostenibles <ul><li>Es posible diagramar a priori y en detalle la totalidad del ciclo de vida y sus artefactos </li></ul><ul><li>El seguimiento de un plan garantiza la excelencia de un proceso de desarrollo </li></ul><ul><li>El diseño previo implica corrección arquitectónica y/o mejora las cualidades no-funcionales </li></ul><ul><li>El diseño previo incide sobre la calidad del código </li></ul><ul><li>La semántica de los lenguajes de diseño mapea punto a punto sobre la semántica de los frameworks de programación </li></ul><ul><li>El diseño y el plan documentan el desarrollo real y/o facilitan su mantenimiento o transferencia </li></ul>
  56. 58. Conclusiones <ul><li>Distintas categorías de métodos ágiles </li></ul><ul><li>Los métodos ágiles son fundamentalmente combinables </li></ul><ul><ul><li>MSF marco general, Planguage como lenguaje de especificación de requerimiento, Scrum (con sus patrones organizacionales) como método de management , XP (con patrones de diseño, programación guiada por pruebas y refactorización) como metodología de desarrollo, RUP como abastecedor de artefactos, ASD como cultura empresarial y (si se requiere) CMM como metodología de evaluación de madurez </li></ul></ul><ul><li>Desarrollo de conceptos y técnicas de uso general </li></ul><ul><ul><li>Patrones organizacionales (Scrum, Lean Software Development), refactorización, TDD, Testing Patterns </li></ul></ul><ul><li>Democratización de las metodologías - Ahora los métodos son mainstream </li></ul>
  57. 59. Estado de la cuestión <ul><li>Los métodos ágiles llegaron para quedarse, aunque la histeria se está moderando </li></ul><ul><li>El BUFD también llegó para quedarse </li></ul><ul><li>CMU/SEI está desarrollando ambas estrategias simultáneamente </li></ul><ul><ul><li>El departamento de Ingeniería está más cerca de los métodos tradicionales (CMM, CMMI, etc) </li></ul></ul><ul><ul><li>Pero hay fuertes críticas respecto de la adecuación de UML para ese propósito – Arquitectura de software no es diseño OO </li></ul></ul><ul><li>El debate está lejos de resolverse en el mediano plazo </li></ul><ul><li>No se puede negar el valor de la auto-organización (Internet, 9/11, Toyota) </li></ul><ul><li>… pero nadie sabe cómo se organiza lo que se auto-organiza </li></ul><ul><li>No hay balas de plata </li></ul><ul><li>Los grandes jugadores en la industria de software todavía no están ni a favor ni en contra. Yo tampoco </li></ul>
  58. 60. Vínculos y referencias <ul><li>Reynoso/Kicillof en MSDN en Español: </li></ul><ul><ul><li>http://www.microsoft.com/spanish/msdn/arquitectura </li></ul></ul><ul><li>Martin Fowler, Kent Beck, John Brant, William Opdyke y Don Roberts. Refactoring: Improving the design of existing code . Addison Wesley, 1999 </li></ul><ul><li>Kent Beck. Extreme Programming Explained: Embrace Change . Addison Wesley, 1999 </li></ul>
  59. 61. Vínculos y referencias <ul><li>Ron Jeffries - Extreme Programming adventures in C#. MS Press, 2004 </li></ul><ul><li>Tom Gilb. Competitive Engineering , 2003. </li></ul><ul><li>Will Stott, James Newkirk - “Test-driven C#”. MSDN Magazine , Abril de 2004. </li></ul><ul><li>Andy Hunt, Dave Thomas - Pragmatic Unit Testing in C# with NUnit , 2004. </li></ul>
  60. 62. ¿ Preguntas ? Billy Reynoso UNIVERSIDAD DE BUENOS AIRES [email_address]
  1. A particular slide catching your eye?

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

×