Your SlideShare is downloading. ×
Introducción Ágil a eXtreme Programming
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Introducción Ágil a eXtreme Programming

6,373
views

Published on

Introducción resumida a Extreme Programming, actualizada a Agosto de 2008

Introducción resumida a Extreme Programming, actualizada a Agosto de 2008

Published in: Technology

2 Comments
22 Likes
Statistics
Notes
  • buena
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Mae lo que ocupaba
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
6,373
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
0
Comments
2
Likes
22
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. www.chileagil.cl Agustín Villena M. agustin.villena@chileagil.cl 16-04-2009
  • 2. Esta obra está publicada bajo una Atribución-No Comercial-  Licenciar Igual 2.0 Chile de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-sa/2.0/cl/ agustin.villena@gmail.com
  • 3. Logros de Proyectos de Software  ◦ Pequeño avance Fuente: “CHAOS Report”, EE.UU. The Standish Group 16-04-2009 agustin.villena@chileagil.cl
  • 4. Pero con poca productividad  Fuente: “CHAOS Report”, EE.UU. The Standish Group 16-04-2009 agustin.villena@chileagil.cl
  • 5. Como lo describió el Como lo programó el Como lo explicó el Como lo entendió el Como lo diseñó el área comercial Desarrollador cliente Jefe de Proyecto Analista Como se documentó el Qué fue instalado en Qué se le cobró al Cómo fue soportado Qué necesitaba el proyecto el cliente cliente cliente en realidad 16-04-2009 agustin.villena@chileagil.cl
  • 6. Y en Chile, ¿será mejor?  ◦ ... 16-04-2009 agustin.villena@chileagil.cl
  • 7. Plano de Negocio Problema Valor (Necesidad) Lenguaje de Negocio Ámbito de la Lenguaje Funcionalidades Común Base gestión (Soluciones) Lenguaje Técnico TAREAS Calidad Plano Técnico agustin.villena@chileagil.cl
  • 8. Avance de Proyecto: - ¿Cuánto hemos avanzado realmente (en generar real valor)? - ¿Cuáles y cuántas funcionalidades queda por hacer? - ¿Cuánto tiempo se requerirá para dichas funcionalidades? - ¿Qué defectos puede tener el producto? Método de Trabajo - ¿Qué prácticas y estándares se debe seguir? - ¿Qué errores no se debe repetir? - ¿Qué debemos mejorar? ? ? Tecnología: Desarrollador - ¿Cuál tecnología usar? Cliente ¿Concuerdan? - ¿Qué sabemos hacer con Problema en resolución: ¿Concuerdan? la tecnología utilizada? - ¿Cuáles son la necesidades - ¿Cuáles es posible hacer actuales? (limites) con la - ¿Cuáles son prioritarias? tecnología? Trabajo en Equipo: ? - ¿Cómo mantener la motivación? - ¿Cómo comunicarse efectivamente? - ¿Hay áreas del proyecto que sólo puedan ser mantenidas por uno? agustin.villena@chileagil.cl Equipo de Desarrollo
  • 9. agustin.villena@chileagil.cl
  • 10. Lidiar con el Riesgo ¿Causa del Riesgo?  La incertidumbre agustin.villena@gmail.com
  • 11. Concepto: “Desarrollo de  nuevo producto” (NPD) ◦ Alta incertidumbre, tecnológica y de requerimientos ◦ Alta probabilidad de cambio el proyecto ◦ Se estima mejor mientras más se resuelve el problema ¡Un desarrollo de software es  un NPD! agustin.villena@gmail.com
  • 12. agustin.villena@gmail.com
  • 13. Tradicionalmente, para atacar la incertidumbre,  ◦ se trata de definir todo desde un principio ◦ generando un diseño y plan detallado, que luego el desarrollador debe ejecutar  Conformado por requerimientos abstractos y detallados ◦ En este modelo, el cliente delega su responsabilidad en el desarrollador  Y si este no cumple lo definido es castigado por multas en el contrato agustin.villena@gmail.com
  • 14. Esto da origen al Modelo de Cascada de desarrollo  Análisis y especificación de requerimientos Diseño Codificación y Test de Módulos Integración y Test del Sistema Instalación y Mantenimiento agustin.villena@gmail.com
  • 15. NO hay retroalimentación entre el problema de  negocio y el producto desarrollado ◦ Es fácil caer en el sesgo tecnológico (cool features) ◦ Se pierde sincronía con las necesidades reales del negocio  Hasta que es demasiado tarde agustin.villena@gmail.com
  • 16. Mientras más se trate de definir a priori un problema  de software que posee incertidumbre, más probabilidad hay de error Y se agrega inflexibilidad ante los (muy) posibles  cambios Problema típico del ciclo de vida “cascada” agustin.villena@gmail.com agustin.villena@gmail.com
  • 17. Cree que a medida que avanza  un proyecto, los cambios son más caros ◦ Se tiende a desarrollar cosas que se cree que alguna vez se necesitarán ◦ Tiende a priorizar según sus propia visión, no la del negocio  Primero diseñamos toda la BD y sus mantenedores, y entonces implementamos las aplicaciones cliente agustin.villena@gmail.com
  • 18. Única zona donde hay Valor para el cliente agustin.villena@gmail.com
  • 19. agustin.villena@chileagil.cl 16-04-2009
  • 20. Cliente Problema de Negocio Proyecto de Software Ingeniero de Software Producto de Software Equipo de Desarrollo Tecnología
  • 21. Antecedente 1 Software fails to deliver… and fails to deliver value! Kent Beck, “Extreme Programming Explained”, 1999 En 2001, Kent Beck y otros autores de enfoques similares  proponen los Principios Ágiles: Individuos e interacciones Procesos y herramientas. Software funcional Documentación exhaustiva por sobre Colaboración con el cliente Negociación de contratos Responder al cambio Seguir un plan agustin.villena@chileagil.cl
  • 22. • Ken Beck, 1999, “Extreme Programming Explained” Extreme Programming • Enfoque empírico e integral de un proyecto de software (XP) • Equipos pequeños que incluyen al cliente • Basado en el enfoque de gestión de la innovación de productos de Hirotaka Takeuchi and Ikujiro Nonaka, 1986 • Sutherland and Schwaber , lo presentan en OOPSLA (1995) Scrum • Define un conjunto de herramientas de gestión y visualización de avance • Metáfora: se requiere abarcar todas las disciplinas requeridas, tal como la formación de scrum del rugby • Mary y Tom Poppendieck, “Lean Software Development” Lean Software • Define las bases teóricas de las metodologías ágiles, a partir del Toyota Development Production System 16-04-2009 agustin.villena@chileagil.cl
  • 23. Es la metodología ágil más famosa en la  actualidad Enunciada por Kent Beck, Ward Cunningham,  and Ron Jeffries. Concebida en el proyecto C3 (Chrysler  Comprehensive Compensation) Documentada en el WikiWiki original  ◦ http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap Plasmada en 1999 en el libro  “Extreme Programming Explained” ◦ Acaba de salir la segunda edición en el 2005 agustin.villena@chileagil.cl
  • 24. Ciclo de Gestión del Proyecto Orientada al Valor Cliente Problema de Negocio Ciclo de Gestión del Desarrollo en Equipo Proyecto de Software Ingeniero de Software Ciclo de Programación Producto de de calidad Software Equipo de Desarrollo Tecnología XP lo organiza en ciclos de Entorno de un retroalimentación y aprendizaje acelerado proyecto de software agustin.villena@chileagil.cl
  • 25. El desarrollo de software es una actividad humana  ◦ Es afectada por la motivación, creencias y los instintos de las personas Valores Comunes: son los que permiten que las personas trabajen por el  beneficio común antes que el propio Comunicación Respeto Simplicidad Coraje Retroalimentación agustin.villena@gmail.com
  • 26. Reglas que orientan la toma de decisiones  • Comunicación abierta y honesta • Enseñar a aprender • Trabajar con los instintos de las personas • Siempre asumir simplicidad • Viajar con equipaje: poco, simple y valioso • Cambios paso a paso • Adaptar de XP a la realidad local • Jugar a ganar • Responsabilidad aceptada (antes que asignada) • Trabajo de Calidad • Atacar los problemas urgentes, dejando la mayor cantidad de opciones abiertas • Retroalimentación Rápida (favorece el aprendizaje) • Medir honestamente • Experimentos concretos agustin.villena@gmail.com
  • 27. Embrace change • • Aceptar con naturalidad y entusiasmo el cambio YAGNI: You Arent’ Gonna Need It. • Avoid PrematureGeneralization • ¡No lo vas a necesitar! (No hagas sobrediseño) Once and Only Once • DRY: Don’t repeat yourself RefactorMercilessly Una funcionalidad en una y solo una parte del sistema Fail fast • • Si va a fallar, que lo haga pronto, para asi escoger otro camino Do The Simplest Thing That Could Possibly Work • • Haz lo más “simple” que podría funcionar agustin.villena@gmail.com
  • 28. Kent Beck:  ◦ “Llevar buenas prácticas de Ingeniería de Software al extremo” Buen Práctica Práctica Extrema Software funcionando Entregas Incrementales e Integración Continua Revisiones de código Programación de a pares Sistema de Pruebas Estructurado Desarrollo Guiado por Pruebas Tener alineado al cliente Cliente in situ agustin.villena@gmail.com
  • 29. Entregas pequeñas Planning Game Gestión del Proyecto orientada al valor Cliente en terreno (Un sólo equipo) Tests de Aceptación Definición Validación del Cliente Desarrollo Planning Game de la Iteración Gestión del Desarrollo en Equipo Liderazgo Motivador Diseño (Coaching) Simple Programación de a Programación Incremental Programación en Equipo Retroalimentación de Avance pares (Tracking) (+ Mantener el equipo rotando) de Calidad Desarrollo Integración Guiado por continua Tests Stand Up Meeting Estándares de Código Espacio de Trabajo Informativo Refactorización Propiedad Colectiva de Código Ritmo Sostenido ( No a las horas extra) Retrospectivas
  • 30. funcionalidades funcionalidades tiempo tiempo Valor entregado de un proyecto tradicional Valor ideal que debiera entregar un proyecto Tradicionalmente ¿No debiera ser así? agustin.villena@gmail.com
  • 31. El desarrollo se debe dividir  en iteraciones cortas de tiempo fijo Al fin de cada iteración del  desarrollo, debe tenerse un producto funcional y útil Alto valor promedio para el cliente agustin.villena@chileagil.cl
  • 32. Visión tradicional ¿Y si fuera así?   agustin.villena@chileagil.cl agustin.villena@gmail.com
  • 33. Tiempo disponible para el proyecto  Costo (Recursos) que se dispondrán  Alcance, es decir conjunto de funcionalidades que se  desarrollarán Y la que se suele olvidar  ◦ Calidad (eficacia, resistencia a fallas, eficiencia, etc.) agustin.villena@chileagil.cl
  • 34. Por lo regular se fijan las 3 primeras variables:  ◦ “Hazme un administrador de estas tablas de la base de datos, en una semana, con dos programadores” ¿Qué sucede al haber cambio?:  ◦ Tiempo y Costo no son en realidad muy flexibles ◦ El Alcance está fijo por el diseño y el plan definido ◦ Variable que sufre: la Calidad, lo que afecta el valor generado para el cliente ◦ Esto genera conflicto  El cliente siempre querrá el mayor valor por sus recursos invertidos  Y el desarrollador la mayor calidad ¿Qué persona sana desea hacer un trabajo mediocre? agustin.villena@chileagil.cl
  • 35. Definamos contratos en que la duración de cada  iteración esté prefijada, inamoviblemente ◦ ¡No existen “atrasos”! Y lo que se ajusta es el alcance (cantidad y cualidad de  las funcionalidades) del proyecto para la iteración agustin.villena@chileagil.cl
  • 36. El objetivo es que todos adquieran la confianza de que las metas del proyecto (de negocio y técnicas) son  alcanzables Aquí el cliente comparte su responsabilidad sobre el proyecto con el desarrollador, en una relación de  sinergia ◦ (inspirado en el modelo Toyota de gestión) Cliente Desarrollador Desea Valor recibido por cada Calidad del trabajo maximizar semana de desarrollo realizado Qué será implementado, y Cuánto se estima que en qué prioridad, según las demorará una tarea Puede necesidades de su (idealmente) definir negocio Funcionalidades Sus estimaciones en base a Puede solicitadas por otras no nuevos descubrimientos cambiar implementadas de costo equivalente (canjear) agustin.villena@chileagil.cl
  • 37. C = Cliente El flujo del Planning Game D = Desarrollador C Fase de Exploración Escribir Historias para toda la iteración D Estimar Historias C Dividir Historias NO El Planning Game  ¿Estimable? Experimentos Concretos D ◦ Juego colaborativo que SI sigue las los roles y Fase de Compromiso C Ordenar por Valor reglas de la gestión ágil D Ordenar por Riesgo ◦ Se usan historias de D Definir Velocidad usuario escritas en C Decidir Alcance tarjetas Recuperación D Fase de Maniobra C Nueva Historia Iteración Velocidad Cliente requiere C sobreestimada nueva historia Planning Game de la Iteración D Desarrollo XP Plan no es adecuado D Ejecutar Re-Estimar D Test no ¿OK? C Funcionales Validar si agustin.villena@gmail.com
  • 38. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad Gestión del Desarrollo en Equipo Stand Up Meeting Liderazgo Motivador (Coaching) Espacio de Trabajo Planning Game de la Iteración Retroalimentación de Avance Informativo (Tracking) Retrospectivas Ritmo Sostenido ( No a las horas extra) Ciclo de Desarrollo agustin.villena@gmail.com
  • 39. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad Planning Game de la Iteración  ◦ Plan orientado al trabajo técnico (descomponer historias de usuario en tareas) StandUpMeeting  ◦ Mini-reunión al comenzar la jornada, en que todos, de pie, definen lo que harán  Asi se va directo al grano agustin.villena@gmail.com
  • 40. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad Productividad Sostenida  (No al sobretiempo) ◦ Los equipos XP trabajan duro, y a un ritmo que puede sostenerse indefinidamente. Esto significa:  Se trabaja sobretiempo sólo cuando es efectivo, pero se entiende como algo extra-ordinario  Un proceso ordenado saca el mejor provecho del tiempo ya asignado  Un desarrollador cansado no produce más que uno descansado  También llamado “40 horas a la semana” (aplicado a jornada completa) ◦ Otra aplicación del timeboxing agustin.villena@gmail.com
  • 41. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad ¿Cómo alcanzar el justo medio entre…?   Gestión centralizada  Caos Se definen dos roles  ◦ Coach (Entrenador) ◦ Tracker (Medidor de avance) … pueden ser cumplidos por la misma persona agustin.villena@gmail.com
  • 42. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación Ayudar al resto a hacer un trabajo aún mejor de calidad  Que todos tomen buenas decisiones  Estar disponible para ser socio de desarrollo (en especial de los novicios)  Vislumbrar objetivos de refactorización de gran escala, y promover las  refactorizaciones pequeñas que ayuden Ayudar a los programadores con destrezas individuales  ◦ Testing, ◦ Formateo y estandarización de código ◦ refactorización Explicar el proceso a gerentes de mayor nivel  Proveer de juguetes y comida   agustin.villena@gmail.com
  • 43. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad Usar métricas para medir el avance del proyecto (solo las  indispensables) ◦ Por ejemplo: Tiempo de desarrollo / Tiempo calendario ◦ Actualizarlas mínimo 2 veces por semana Ayudar al Entrenador a  ◦ Motivar al cambio de una manera gentil y no coercitiva Mostrar la información en una Carta Grande y Visible para  todo el equipo en el Espacio Informativo agustin.villena@gmail.com
  • 44. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad Burn Down Chart: Estado de Avance (Kanban)   Horas de trabajo que quedan agustin.villena@gmail.com
  • 45. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad En vez de pasar a   ◦ diseñar-programar-probar- ◦ Diseñar continuamente, Probar continuamente, Armar depurar-armar-entregar, continuamente , Revisar continuamente y Entregar temprana y frecuentemente Diseño Simple Programación de a Programación Incremental Programación en Equipo pares (+ Mantener el equipo rotando) de Calidad Desarrollo Integración Guiado por continua Tests Estándares de Código Refactorización Propiedad Colectiva de Código
  • 46. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad Programación de a pares  ◦ Un computador, un teclado, un mouse, y dos programadores ◦ Empírico  código un 20% más simple  15% adicional de productividad sobre el trabajo separado agustin.villena@gmail.com
  • 47. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad Propiedad Colectiva de Código:  todos son propietarios (y responsables) de todo el código ◦ NO existen módulos intocables Estilo común de codificación:  Usar convenciones que permitan que cualquier desarrollador pueda entender, usar y modificar el código desarrollado por el equipo agustin.villena@gmail.com
  • 48. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad Propiedad Colectiva de Código:  todos son propietarios (y responsables) de todo el código ◦ NO existen módulos intocables Estilo común de codificación:  Usar convenciones que permitan que cualquier desarrollador pueda entender, usar y modificar el código desarrollado por el equipo agustin.villena@gmail.com
  • 49. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad Diseñar para lo que realmente se necesita  ◦ Ojo: si nadie conoce el problema, es imposible saber qué se necesita ◦ => hay que pensar continuamente el problema También llamado “Diseño Simple”  ◦ Simple = Elegante, Limpio, Directo ◦ Simple != Fácil agustin.villena@gmail.com
  • 50. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad ¿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 agustin.villena@gmail.com
  • 51. Tests son programados antes de programar la implementación. Luego de  programar, se verifica la correctitud automáticamente Aumenta la confianza del desarrollador en su código  Facilita el mejorar el código sin provocar errores en cascada  Herramientas:  ◦JUnit : Java ◦NUnit : .NET ◦PyUnit : Python ◦CPPUnit : C++ ◦etc. agustin.villena@gmail.com
  • 52. 16-04-2009 agustin.villena@chileagil.cl
  • 53. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad ◦ Cuando dos segmentos de código hagan los mismo, se refactoriza para combinarlos y simplificar el código resultante… SIEMPRE ◦ Permite la implementación del llamado “Diseño Emergente”, en contraste con “Diseño detallado” agustin.villena@gmail.com
  • 54. Ciclo de Gestión del Proyecto Orientada al Valor Ciclo de Gestión del Desarrollo Ciclo de Programación de calidad ◦ Generar ejecutables funcionales periódicamente (a lo más diaramente) ◦ Se valida además la integridad del código corriendo las suites de tests de aceptación y de unidad  Depende de tener un sistema de pruebas ◦ Ojalá sea automático Cruisecontrol , de Martin Fowler agustin.villena@gmail.com
  • 55. Extreme programming  ◦ www.extremeprogramming.org WikiWiki entry point for XP  ◦ http://c2.com/cgi/wiki?ExtremeProgr ammingRoadmap Scrum Development Process  ◦ www.controlchaos.org Gestión Ágil de Software  www.chileagil.cl ◦ www.agilemanagement.net Lean Software Development Artículos y Enlaces sobre Metodologías   Ágiles y su adopción e impacto en la ◦ www.poppendieck.com industria local Agile Alliance  ◦ www.agilealliance.org agustin.villena@chileagil.cl