SEPG LA 2005 Presentation "Practicas Agiles En Mejora De Procesos"

944 views

Published on

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

No Downloads
Views
Total views
944
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
46
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

SEPG LA 2005 Presentation "Practicas Agiles En Mejora De Procesos"

  1. 1. Prácticas Ágiles en Mejora de Procesos Walter Ariel Risi Pragma Consultores [email_address] Miroslav Pavlovic Practia Consulting [email_address] John Gómez Practia Consulting [email_address]
  2. 2. Objetivos del Tutorial <ul><li>Mostrar como una correcta interpretación y buen uso de los principios y prácticas de las metodologías ágiles pueden potenciar las iniciativas de mejora de procesos . </li></ul><ul><li>Introducir los conceptos básicos sobre lo ágil y desmitificar las posiciones radicales asumidas por promotores y detractores. </li></ul><ul><li>A través de escenarios de uso reales, mostrar como los modelos rigurosos y los ágiles son complementarios . </li></ul>
  3. 3. Agenda <ul><li>Módulo 1: Introducción </li></ul><ul><ul><li>Explica los conceptos básicos detrás de las metodologías ágiles. </li></ul></ul><ul><li>Módulo 2: Escenarios de Aplicación </li></ul><ul><ul><li>Explica como las metodologías ágiles contribuyen a la mejora de los procesos de la organización, a través de escenarios provenientes de la experiencia de los autores. </li></ul></ul><ul><li>Módulo 3: ¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil? </li></ul><ul><ul><li>Explica cómo realizar un proyecto de mejora basado en metodologías ágiles. </li></ul></ul><ul><li>Módulo 4: Conclusiones y Recomendaciones </li></ul><ul><ul><li>Esboza algunas conclusiones sobre lo visto en el curso, y brinda una serie de recomendaciones para el buen uso de las metodologías ágiles. </li></ul></ul>
  4. 4. Prácticas Ágiles en Mejora de Procesos Introducción Escenarios de Aplicación ¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil? Conclusiones y Recomendaciones
  5. 5. Índice del Módulo <ul><li>Introducción y Conceptos Básicos </li></ul><ul><li>La Alianza Ágil </li></ul><ul><li>El Manifiesto Ágil </li></ul><ul><li>Orígenes y Precursores </li></ul><ul><li>Metodologías más Conocidas </li></ul><ul><li>Mitos y Realidades </li></ul><ul><li>Algunas Conclusiones </li></ul>
  6. 6. El Dilema del Software <ul><li>Hoy en día, el software es una parte crítica de todo negocio </li></ul><ul><li>Sin embargo, el desarrollo de software aún sufre de problemas como... </li></ul><ul><ul><li>Calidad insuficiente o muy variable </li></ul></ul><ul><ul><li>Proyectos que exceden sus tiempos y costos </li></ul></ul>
  7. 7. El Proceso al Rescate <ul><li>No es novedad que una forma de resolver los problemas de calidad (y otros) de un producto es mejorando la forma de construir tales productos. </li></ul><ul><li>… o sea, mejorando los procesos . </li></ul><ul><li>En una actividad humana como es el desarrollo software, esto es casi equivalente a mejorar la metodología que se sigue para construir los productos </li></ul>
  8. 8. Procesos y Metodologías <ul><li>Con los fines mencionados han surgido gran cantidad de enfoques metodológicos a lo largo de los años: </li></ul><ul><ul><li>(Cascada, cascada desfasada, espiral, prototipos incrementales, desarrollo por etapas, etc.) </li></ul></ul>¿Qué tienen en común los anteriores enfoques? Están inspirados en la producción industrial ¿Y hay algo de malo en ello? ¡No! sólo que requieren una cierta predecibilidad ¡Lamentablemente, muchas veces el contexto de un proyecto es menos predecible o estable que lo deseado!
  9. 9. El Surgimiento de la “Agilidad” <ul><li>Durante el trascurso de los años 90 , varias personas se dieron cuenta de que las cosas estaban cambiando. </li></ul>El ambiente cambiante y turbulento era cada vez más la regla que la excepción. <ul><li>Estas personas observaron la necesidad de desarrollar metodologías livianas y maniobrables , que pudieran operar en ese ambiente turbulento. </li></ul><ul><li>A pesar de que los detalles de estas metodologías varían, todas comparten algunos principios comunes . </li></ul>Estas metodologías son conocidas colectivamente hoy en día como “metodologías ágiles”.
  10. 10. ¿Qué es una Metodología Ágil? <ul><li>Las metodologías ágiles se entienden como un conjunto de metodologías para desarrollo de software surgidas en la década de los 90. </li></ul><ul><li>Lo ágil se define (por los mismos “agilistas”) como la habilidad de responder de forma versátil al cambio para maximizar los beneficios </li></ul><ul><li>Las metodologías ágiles varían en su forma de “responder al cambio”, pero en general comparten características como las siguientes </li></ul><ul><ul><li>Usar procesos de construcción iterativos </li></ul></ul><ul><ul><li>Entregar software funcional lo más pronto posible </li></ul></ul><ul><ul><li>Privilegiar el valor de la gente sobre el valor del proceso </li></ul></ul><ul><ul><li>Fortalecer la comunicación y la colaboración </li></ul></ul><ul><li>Los valores y principios compartidos por toda metodología ágil fueron enunciados en el “manifiesto ágil”, por la “alianza ágil”. </li></ul>
  11. 11. La Alianza Ágil <ul><li>17 promotores de los &quot;procesos livianos&quot; se reunieron en Utah (EEUU), a principios del 2001, a discutir que tenían en común. </li></ul><ul><ul><li>En primer lugar, acordaron que todos apuntaban sus esfuerzos a responder&quot; al cambio . </li></ul></ul><ul><ul><ul><li>Acordaron que la palabra &quot;ágil&quot; ilustraba esto mejor que el término &quot;liviano“. </li></ul></ul></ul><ul><ul><li>En segundo lugar, estuvieron de acuerdo en 4 valores fundamentales. </li></ul></ul><ul><ul><li>Finalmente, estuvieron de acuerdo en 12 principios . </li></ul></ul>Esos 4 valores y 12 principios formaron el “Manifiesto Ágil” Esas 17 personas Formaron la “ Alianza Ágil”
  12. 12. El Manifiesto Ágil (I) <ul><li>“ Estamos descubriendo mejores formas de desarrollar software al hacerlo y al ayudar a otros a hacerlo. A través de este trabajo hemos llegado a valorar: </li></ul><ul><ul><li>individuos y sus interacciones sobre procesos y herramientas </li></ul></ul><ul><ul><li>software funcional sobre documentación exhaustiva </li></ul></ul><ul><ul><li>colaboración con el cliente sobre negociación de contratos </li></ul></ul><ul><ul><li>responder al cambio sobre seguimiento de un plan </li></ul></ul><ul><li>Esto significa, que mientras hay valor en los ítems de la derecha, damos más valor a los de la izquierda.” </li></ul>
  13. 13. El Manifiesto Ágil (II) <ul><li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. </li></ul><ul><li>Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. </li></ul><ul><li>Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. </li></ul><ul><li>Business people and developers must work together daily throughout the project. </li></ul><ul><li>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. </li></ul><ul><li>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. </li></ul>
  14. 14. El Manifiesto Ágil (III) <ul><li>Working software is the primary measure of progress. </li></ul><ul><li>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. </li></ul><ul><li>Continuous attention to technical excellence and good design enhances agility. </li></ul><ul><li>Simplicity--the art of maximizing the amount of work not done--is essential. </li></ul><ul><li>The best architectures, requirements, and designs emerge from self-organizing teams. </li></ul><ul><li>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>
  15. 15. En Resumen <ul><li>Las metodologías ágiles proponen tener el proceso “suficiente” (ni más ni menos) para cumplir con los objetivos </li></ul><ul><li>Usar procesos de construcción iterativos </li></ul><ul><li>Entregar software funcional lo más pronto posible </li></ul><ul><li>Privilegiar el valor de la gente sobre el valor del proceso </li></ul><ul><li>Fortalecer la comunicación y la colaboración </li></ul><ul><li>Orientar la metodología alrededor de un conjunto de valores y principios </li></ul><ul><li>Lo ágil se define (por los mismos “agilistas”) como la habilidad de responder de forma versátil al cambio para maximizar los beneficios </li></ul>
  16. 16. Orígenes y Precursores (I) Las metodologías ágiles tal como las conocemos surgen en los años 90, pero los conceptos subyacentes no son nuevos &quot;Agile software development is not new. It has been around since the beginning of software development, but did not show a competitive advantage in the 1970s and 1980s (...) However, it did win the development races in the turbulent 1990s&quot; Alistair Cockburn Integración Continua Iteraciones Cortas Programación de a Pares Priorización de Requerimientos Involucramiento del Cliente Time-Boxing
  17. 17. Orígenes y Precursores (II) <ul><li>… y no sólo conceptos de software! </li></ul>Desarrollo de Nuevos Productos (Nonaka y Takeuchi) Auto-Control y Auto-Dirección Just-in-Time Lean Manufacturing Lean Thinking Sistema de Producción Toyota
  18. 18. Metodologías Ágiles más Conocidas <ul><li>XP (Extreme Programming – Kent Beck) </li></ul><ul><li>SCRUM (Jeff Sutherland, Ken Schwaber) </li></ul><ul><li>Crystal (Alistair Cockburn) </li></ul><ul><li>DSDM (DSDM Consortium) </li></ul><ul><li>Feature Driven Development (Jeff de Luca, Peter Coad, Together Soft) </li></ul><ul><li>Adaptive Software Development (Jim Highsmith) </li></ul><ul><li>Lean Development (Mary y Tom Poppendieck, Robert Charette) </li></ul>
  19. 19. SCRUM Básico <ul><li>Más que una metodología de desarrollo es una metodología de gestión de proyectos , no contiene definiciones en áreas de ingeniería </li></ul><ul><li>Con visión de que el trabajo es efectuado por equipos auto-organizados y auto-dirigidos </li></ul><ul><li>Está basada en un proceso constructivo iterativo e incremental donde las iteraciones tienen duración fija </li></ul><ul><li>Contiene definición de roles, prácticas y productos de trabajo , escritas de forma simple </li></ul><ul><li>Está soportada en un conjunto de valores y principios </li></ul>
  20. 20. El Ciclo de SCRUM
  21. 21. Elementos de SCRUM <ul><li>Product Backlog </li></ul><ul><li>Sprint </li></ul><ul><ul><li>Planificación </li></ul></ul><ul><ul><li>Revisión </li></ul></ul><ul><ul><li>Sprint Backlog </li></ul></ul><ul><ul><li>SCRUM </li></ul></ul><ul><ul><li>Retrospectiva (Reflexión) </li></ul></ul><ul><li>Roles </li></ul><ul><ul><li>Product Owner </li></ul></ul><ul><ul><li>Scrum Master </li></ul></ul><ul><ul><li>Team </li></ul></ul><ul><li>Valores </li></ul><ul><ul><li>Compromiso, foco, apertura, coraje y respeto </li></ul></ul>
  22. 22. Backlog de Producto
  23. 23. Backlog de Sprint
  24. 24. Mitos y Realidades <ul><li>Mito </li></ul><ul><ul><li>“ Persona o cosa a las que se atribuyen cualidades o excelencias que no tienen, o bien una realidad de la que carecen” </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>“ Lo que es efectivo o tiene valor práctico, en contraposición con lo fantástico e ilusorio” </li></ul></ul>Existen muchos mitos y realidades en torno a la discusión Metodologías Ágiles (m.a.) vs. Metodologías Tradicionales (m.t.)
  25. 25. ¿“Ágil” Significa “Hacker”? <ul><li>Mitos </li></ul><ul><ul><li>Las m.a. promueven y ensalzan el “hacking”, es decir, la codificación directa sin paso por etapas de análisis y diseño (anti-ágil) </li></ul></ul><ul><ul><li>El único producto de valor dentro del desarrollo es el código (ágil-fanático) </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>Las m.a. dan mucho valor al código como resultado del desarrollo, esto no significa que no haya otros resultados valiosos </li></ul></ul><ul><ul><li>Los equipos deben determinar cuáles son los resultados valiosos para sus clientes y orientar su trabajo en ese sentido (documentos de análisis, diseño, etc.) </li></ul></ul>
  26. 26. Ciclo de Vida <ul><li>Mitos </li></ul><ul><ul><li>Las m.t. implican casi siempre el uso de un ciclo de vida clásico en cascada (ágil-fanático) </li></ul></ul><ul><ul><li>Los proyectos donde no se conocen todos los requerimientos completamente al principio fracasan si usan un modelo en cascada (ágil-fanático) </li></ul></ul><ul><ul><li>Los ciclos de vida iterativos son exclusivos de las m.a. (ágil-fanático) </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>Malas experiencias y malas interpretaciones han conducido a conceptos erróneos sobre el ciclo en cascada </li></ul></ul><ul><ul><li>Los ciclos de vida iterativos existen mucho antes de las m.a. </li></ul></ul><ul><ul><li>Todas las m.a. proponen un ciclo de vida iterativo e incremental </li></ul></ul>
  27. 27. Diseño <ul><li>Mitos </li></ul><ul><ul><li>En las m.a. no hay ninguna actividad de diseño o este no tiene ninguna importancia (anti-ágil) </li></ul></ul><ul><ul><li>En las m.t. se promueve que no debe escribirse una sola línea de código sin antes terminar todo el diseño (ágil-fanático, anti-ágil?) </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>Las m.a. más conocidas proponen etapas de diseño cortas y livianas pero otras prácticas de las mismas m.a. (p. ej., integración continua) implican alta disciplina y calidad técnica del diseño </li></ul></ul>
  28. 28. Pruebas <ul><li>Mitos </li></ul><ul><ul><li>En las m.a. no se realizan pruebas o estas son consideradas de ninguna o poca importancia (anti-ágil) </li></ul></ul><ul><ul><li>En las m.t. no hay actividades de pruebas concurrentes con otras actividades de desarrollo (ágil-fanático) </li></ul></ul><ul><ul><li>En las m.t. las pruebas solo se inician cuando todo el código se ha finalizado (ágil-fanático, anti-ágil?) </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>En las m.a. la disciplina de pruebas es fuerte y se promueve el diseño de pruebas antes de la construcción del código </li></ul></ul><ul><ul><li>En general, la visión de que las actividades de pruebas (planificación, diseño, ejecución) son permanentes es común a todas las metodologías </li></ul></ul>
  29. 29. Planificación (I) <ul><li>Mitos </li></ul><ul><ul><li>Las m.a. promueven no realizar ningún tipo de plan para orientar el desarrollo (anti-ágil) </li></ul></ul><ul><ul><li>No hay que planificar (o no es posible) en un ambiente muy turbulento donde las cosas cambian todos los días (ágil-fanático) </li></ul></ul><ul><ul><li>Las m.t. con la tendencia a planificar todos los aspectos del proyecto buscan predecir sus resultados y esto no es viable porque la incertidumbre no se puede eliminar (ágil-fanático) </li></ul></ul><ul><ul><li>Dado que en las m.a. no se puede planificar todo el proyecto entonces no son viables en contratos de plazo y precio fijo (anti-ágil) </li></ul></ul><ul><ul><li>En las m.a. no hay ningún manejo del riesgo (anti-ágil) </li></ul></ul>
  30. 30. Planificación (II) <ul><li>Realidades </li></ul><ul><ul><li>Todas las m.a. incluyen algún método de planificación, promoviendo que se incluyan los elementos mínimos necesarios para poder ejecutar el proyecto </li></ul></ul><ul><ul><li>Si bien hay pocas evidencias de manejo explícito del riesgo en las m.a. los procesos constructivos, el manejo de los requerimientos, la incertidumbre y el cambio contribuyen al manejo del riesgo </li></ul></ul><ul><ul><li>Muchas compañías que usan m.a. lo hacen dentro de esquemas de contratos a plazo y precio fijos </li></ul></ul><ul><ul><li>Los planes deben ser herramientas que guíen la ejecución del proyecto y deben siempre reflejar la realidad del mismo, este concepto es común a todas las metodologías </li></ul></ul>
  31. 31. Documentación <ul><li>Mitos </li></ul><ul><ul><li>En las m.a. no se documenta o esta actividad se considera de ninguna o mínima importancia (anti-ágil) </li></ul></ul><ul><ul><li>En las m.t. es más importante la documentación que el software (ágil-fanático) </li></ul></ul><ul><ul><li>En los proyectos hechos con m.t. se pasa más tiempo documentando que construyendo el producto (ágil-fanático, anti-ágil?) </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>En las m.a. se concede más valor al producto desarrollado que a la documentación </li></ul></ul><ul><ul><li>Determinar la documentación suficiente para cumplir con los objetivos y desarrollar actividades para construirla y mantenerla es un concepto común a todas las metodologías </li></ul></ul><ul><ul><li>El método más efectivo de comunicación es la conversación cara a cara </li></ul></ul>
  32. 32. Gente <ul><li>Mitos </li></ul><ul><ul><li>En las m.t. las personas son consideradas de poca o mínima importancia o como recursos intercambiables (ágil-fanático, anti-ágil?) </li></ul></ul><ul><ul><li>En las m.t. no se promueven técnicas efectivas de comunicación, colaboración y trabajo en equipo (ágil-fanático, anti-ágil?) </li></ul></ul><ul><ul><li>En las m.a. se crea una alta dependencia de las personas (anti-ágil) </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>Las m.a. consideran a la gente como más importante que los procesos </li></ul></ul><ul><ul><li>Las m.a. promueven explícitamente prácticas de colaboración y comunicación </li></ul></ul><ul><ul><li>Las m.t. consideran a la gente como más importante que los procesos (si, este es igual a la primera viñeta) </li></ul></ul><ul><ul><li>Pocas m.t. contienen dentro de sus definiciones prácticas específicas de comunicación </li></ul></ul>
  33. 33. Disciplina <ul><li>Mitos </li></ul><ul><ul><li>En las m.a. no hay disciplina ni exigencias fuertes al equipo de trabajo y por eso son más fáciles de usar (todos) </li></ul></ul><ul><ul><li>Rigidez es lo mismo que disciplina (todos) </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>La rigidez entendida como el conjunto de reglas de la metodología y el formalismo implícito en su definición no tiene nada que ver con la disciplina </li></ul></ul><ul><ul><li>Las m.a. requieren la misma y en ocasiones incluso más disciplina que las m.t. en su implementación </li></ul></ul>
  34. 34. Clientes <ul><li>Mitos </li></ul><ul><ul><li>Las m.t. no promueven el mantener foco en el cliente y sus necesidades (ágil fanático) </li></ul></ul><ul><ul><li>En las m.a. se requiere que el cliente trabaje en el mismo espacio y con la misma dedicación que el equipo (anti-ágil) </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>El mantener el foco en las necesidades del cliente, en agregar valor al producto desarrollado y orientarse al cumplimiento de objetivos del proyecto es un concepto común a todas las metodologías </li></ul></ul><ul><ul><li>En las m.a. no es obligatorio que el cliente trabaje junto con el equipo todo el tiempo. El concepto real es el de usuario con conocimiento de los objetivos disponible </li></ul></ul>
  35. 35. CMMI vs. Metodologías Ágiles <ul><li>Mitos </li></ul><ul><ul><li>CMMI y las m.a. no son compatibles (todos) </li></ul></ul><ul><ul><li>Si no se aplica una metodología ágil de libro entonces no se es ágil (ágil fanático) </li></ul></ul><ul><li>Realidad </li></ul><ul><ul><li>Es posible implementar CMMI tomando como base una metodología ágil, complementando las insuficiencias (tal como se hace con cualquier otra) </li></ul></ul><ul><ul><li>Crear el balance adecuado de prácticas ágiles con los requerimientos del modelo puede permitir su uso en cualquier organización </li></ul></ul>
  36. 36. Algunas Conclusiones (I) <ul><li>Las metodologías ágiles surgen en los años 90 , como respuesta a un contexto de desarrollo de software turbulento y cambiante . </li></ul><ul><li>En general, una metodología ágil es aquella que adhiere a los valores y principios del manifiesto . </li></ul><ul><li>Los conceptos subyacentes a las mismas no son necesariamente nuevos , aunque toman nueva importancia a partir del momento en que se usan combinados . </li></ul>
  37. 37. Algunas Conclusiones (II) <ul><li>Hay una serie de malas interpretaciones en uno y otro sentido (ágiles y tradicionales). </li></ul><ul><li>Las metodologías ágiles no son “balas de plata” pero tampoco son “la peor desgracia” sucedida a la ingeniería de software </li></ul><ul><li>Ningún planteamiento es completo por si mismo , dado que ninguna metodología es apropiada para todos los proyectos, todos los equipos y todas las compañías </li></ul><ul><li>Es posible y recomendable encontrar el balance que permite agregar el mayor valor a mi proceso , mi equipo, mi proyecto </li></ul>
  38. 38. ¿Preguntas?
  39. 39. Prácticas Ágiles en Mejora de Procesos Introducción Escenarios de Aplicación ¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil? Conclusiones y Recomendaciones
  40. 40. Índice del Módulo <ul><li>Escenario 1: Usando Prácticas Ágiles para Sobrevivir a Cambios Drásticos en el Cronograma </li></ul><ul><li>Escenario 2: Implementando una Metodología Ágil completa </li></ul><ul><li>Escenario 3: CMMI Complementando lo Ágil </li></ul><ul><li>Escenario 4: Prácticas Ágiles Complementando CMMI para salvar un Proyecto en Problemas </li></ul>
  41. 41. Sobreviviendo a Cambios Drásticos … <ul><li>La Historia de un Sistema </li></ul><ul><li>La Historia de un Proyecto. </li></ul><ul><li>¡Un Cambio Inesperado! </li></ul><ul><li>¿Qué Hicimos? </li></ul><ul><li>¿Cómo nos Ayudó el Usar un Enfoque Ágil? </li></ul>
  42. 42. La Historia de un Sistema <ul><li>Sistema financiero para mesa de dinero de importante banco. </li></ul><ul><li>La mesa de dinero es parte del “core business”. </li></ul>Sistema BANK Mesa de Dinero Soporte a Mesa ¡Por lo tanto, hablamos de un sistema crítico!
  43. 43. La Historia de un Proyecto <ul><li>Una nueva versión sistema en cuestión reemplazaría a otra aplicación. </li></ul><ul><li>La “otra aplicación” tenía costos muy elevados. </li></ul><ul><li>Al momento de esta historia, faltaba un mes para comenzar el “paralelo” de la versión mencionada… </li></ul>CONSTRUCCIÓN PARALELO 1 Mes
  44. 44. ¡Un Cambio Inesperado! ¡Necesitamos la nueva versión del sistema para bajar costos! ¡Necesitamos el sistema para la semana próxima! ¿Para cuándo dijo que lo quiere? Mesa de Dinero Soporte a Mesa Sistemas
  45. 45. La Situación Resultante Fue… CONSTRUCCIÓN PARALELO 1 Mes CONSTRUCCIÓN PARALELO 1 Semana
  46. 46. ¿Qué Podíamos Hacer? <ul><li>El sistema pasó a tener modo “time box”. </li></ul>… para que aquí se tenga la funcionalidad requerida? ¿Qué hacemos aquí en el tiempo disponible… <ul><li>Un proyecto de estas características debe llegar o llegar, pero... </li></ul>¿Qué Significa Llegar? CONSTRUCCIÓN PARALELO Time Box
  47. 47. Podando Requerimientos… <ul><li>La primera actividad que procedimos a hacer es ver que requerimientos eran necesarios para la nueva fecha límite, cuáles podían post-ponerse y cuáles eliminarse. </li></ul><ul><li>La “poda de requerimientos” (requirements scrubbing) es una buena práctica implícita en modelos ágiles (se hace lo que el cliente desea realmente, no más). </li></ul>
  48. 48. ¿Cómo Podamos Requerimientos? <ul><li>Armamos una lista exhaustiva de los requerimientos. </li></ul><ul><li>Identificamos un representante “con capacidad de decisión”. </li></ul><ul><li>Priorizamos los requerimientos en base a su importancia para la fecha de entrega. </li></ul><ul><li>Acordamos cuáles eran los N requerimientos prioritarios para la fecha. </li></ul>1 2 3 Requerimiento… Requerimiento… Requerimiento… Requerimiento… Requerimiento…
  49. 49. Organizando el Trabajo Pendiente <ul><li>Con los requerimientos priorizados y “podados”, armamos un “backlog” . </li></ul><ul><li>Un “backlog” es una forma liviana de organizar el trabajo pendiente (actividades y requerimientos). </li></ul><ul><li>El backlog es la forma que utiliza Scrum para registrar el trabajo pendiente para el producto y para una iteración de trabajo. </li></ul><ul><li>Definimos un backlog del producto, y un backlog para cada iteración. </li></ul><ul><li>Usamos esta forma de backlog para organizar nuestras actividades en iteraciones de un día cada una. </li></ul>
  50. 50. ¿Cómo Armamos el Backlog? <ul><li>Asignamos los requerimientos a “iteraciones” dependiendo de su prioridad. </li></ul>… 3 3 REQ01 … 2 3 REQ30 … 1 3 REQ18 … 2 2 REQ33 … 1 2 REQ02 … 3 1 REQ06 … 2 1 REQ23 … 1 1 REQ10 Descripción Orden Iteración ID Primera Iteración Tercera Iteración Segunda Iteración
  51. 51. ¡Avanzando a Paso Firme! <ul><li>Con un backlog armado y time-boxes definidos, lo importante era entonces asegurarnos de avanzar “siempre para adelante”. </li></ul><ul><li>Si implementamos un requerimiento, veamos que cuando lo integremos, el producto siga andando. </li></ul><ul><li>Si no llegamos a terminar con todos los requerimientos, aún así tendremos un producto funcionando que podamos mostrar. </li></ul>
  52. 52. Builds Continuos y Pruebas Básicas <ul><li>La estrategia que utilizamos consiste en builds continuos y “smoke test” (prueba básica de la funcionalidad del sistema). </li></ul>DESARROLLO BUILD Pasa a integración lo más pronto posible (diario, al menos). SMOKE TEST Se prueba que no se “rompa” el build. Se Itera por Estas Fases… El programador libera código.
  53. 53. Armando una Estrategia de Builds Continuos… <ul><li>¿Cómo lo hicimos? </li></ul><ul><ul><li>El desarrollador (1 o 2) desarrollaba según el back-log, y al finalizar, notificaba por mail al “integrador”. </li></ul></ul><ul><ul><li>El integrador tomaba el código y lo integraba con el resto del producto. </li></ul></ul><ul><ul><li>Compilaba. </li></ul></ul><ul><ul><li>Probaba “por arriba” el producto, para verificar que no “se había roto”. </li></ul></ul><ul><ul><li>Si había problemas, se devolvía al desarrollador. </li></ul></ul>
  54. 54. También nos resultó conveniente… <ul><li>En nuestro caso, el integrador también subía el código a un repositorio. </li></ul><ul><ul><li>Es una buena práctica subir el código a un repositorio (CVS, PVCS) cada vez que se logra un build exitoso. </li></ul></ul><ul><ul><li>Se pueden generar mini líneas base por cada build. </li></ul></ul><ul><ul><li>Conviene notificar entonces al equipo de que hay una nueva versión “estable” del código para usar como base. </li></ul></ul>¿Exitoso? BUILD DESARROLLO REPOSITORIO Notificar Equipo Sí
  55. 55. Optimizando el Desarrollo <ul><li>Un principio de XP dice “haz lo más simple que pueda funcionar”. </li></ul><ul><li>Solíamos tener la costumbre de hacer modelos complejos y soluciones genéricas… </li></ul>¿Por qué no hacer las cosas “bien”, pero a la vez en forma simple y directa?
  56. 56. ¿Cómo Evitamos la Complejidad Excesiva? Evitamos atacar una solución genérica o compleja si no era absolutamente necesario <ul><ul><li>Evitamos “gold plating” </li></ul></ul><ul><ul><li>(introducir complejidad </li></ul></ul><ul><ul><li>Adicional sólo porque es </li></ul></ul><ul><ul><li>Interesante o desafiante) </li></ul></ul>¡Atacamos Directamente el Requerimiento!
  57. 57. Poniendo Todo Eso Junto… TIME BOX TIME BOX TIME BOX TIME BOX + Simplicidad en el Desarrollo (¡Pero No Negligencia!) Desarrollo Build S. Test Req. Originales Backlog Req. Podados
  58. 58. … el Resultado Fue… <ul><li>Al llegar a la fecha límite, teníamos “casi” todos los requerimientos exigidos para el time-box. Los más prioritarios estaban implementados, y el producto estaba funcionando. </li></ul><ul><li>El usuario encontró el producto suficiente para comenzar, y acordó que era válido seguir “puliendo” el producto durante las próximas semanas. </li></ul>Independiente de que quedara “backlog” pendiente, el producto resultante cumplía con lo que se necesitaba para la fecha… “ EL PROYECTO LLEGÓ”
  59. 59. ¿Cómo Ayudó el Usar un Enfoque Ágil? <ul><li>Podar los requerimientos nos permitió convertir un objetivo irrealizable en uno “difícil” pero realista. </li></ul><ul><li>Usando iteraciones / time-boxes y un backlog pudimos hacer seguimiento del proyecto es una forma ultra-liviana, que consumía muy pocos recursos. </li></ul><ul><li>Mediante la estrategia de build continuo y smoke test , pudimos tener un producto desde la primera iteración y “mantenerlo andando”. </li></ul><ul><ul><li>Al llegar a la fecha límite, teníamos un producto funcionando desde hace tiempo. </li></ul></ul><ul><li>Adoptando simplicidad en el desarrollo evitamos perder de vista el objetivo. </li></ul>
  60. 60. Índice del Módulo <ul><li>Escenario 1: Usando Prácticas Ágiles para Sobrevivir a Cambios Drásticos en el Cronograma </li></ul><ul><li>Escenario 2: Implementando una Metodología Ágil completa </li></ul><ul><li>Escenario 3: CMMI Complementando lo Ágil </li></ul><ul><li>Escenario 4: Prácticas Ágiles Complementando CMMI para salvar un Proyecto en Problemas </li></ul>
  61. 61. Un poco de historia para empezar <ul><li>Esta es una experiencia en un proyecto de mejora de una empresa pequeña dedicada al desarrollo de videojuegos para PC </li></ul><ul><li>El proyecto empezó con la orientación de formalizar y hacer más rigurosos muchos de los procesos de la empresa </li></ul><ul><li>Durante el camino se detectaron debilidades importantes de gestión en un proyecto crítico y había que solucionarlas a la brevedad </li></ul><ul><li>En ese momento se optó por implementar SCRUM en este proyecto para resolver los problemas de gestión y volverlo a curso </li></ul>
  62. 62. El contexto de esta aplicación <ul><li>Un segmento “especial” de la industria: hacer juegos no es un juego!!! </li></ul><ul><li>La gente que hace juegos: solo 40% del equipo son ingenieros, los demás son diseñadores y artistas </li></ul><ul><li>Este proyecto nuevo no es igual: </li></ul><ul><ul><li>Nuevo cliente (y estratégico) </li></ul></ul><ul><ul><li>Equipo más grande (antes +5 ahora +15) </li></ul></ul><ul><ul><li>Mucho más complejo y grande que los anteriores </li></ul></ul><ul><ul><li>Tenemos 7 meses para Alpha pero empezamos en el mes 3 y la fecha final no cambió!!! </li></ul></ul><ul><ul><li>Después de 1 mes de proyecto no se ven avances, los requerimientos cambian con frecuencia, no se sabe el estado del proyecto y la moral es baja </li></ul></ul>
  63. 63. ¿Qué hacemos ahora? <ul><li>Organicemos el equipo: en vez de 1 de 15 que sean 3 de 5, todos autosuficientes (multidisciplinarios) </li></ul><ul><li>Asignemos a cada equipo responsabilidades claras de módulos del producto en cada entrega, la administración no va a intervenir en este proceso </li></ul><ul><li>Para la próxima entrega en un mes más fijemos una meta y dejemos que cada equipo planifique sus tareas, la administración se compromete a no cambiar la meta </li></ul><ul><li>Llevemos un registro de estas tareas y revisemos su estado diariamente </li></ul><ul><li>Diariamente revisemos los problemas y riesgos que tenemos para tomar acciones correctivas y preventivas lo más pronto posible </li></ul><ul><li>Hagamos pública toda la información sobre las actividades, problemas y riesgos del proyecto e involucremos a todo el equipo </li></ul>
  64. 64. Un nuevo enfoque <ul><li>Esto parece SCRUM pero no le cuenten a nadie!!! </li></ul><ul><li>Cada equipo nombra un líder que actúa como responsable de cumplir la meta y resuelve los problemas (“Scrum Master”) </li></ul><ul><li>Se realiza una reunión diaria de seguimiento </li></ul><ul><ul><li>Duración fija </li></ul></ul><ul><ul><li>Foco en actividades efectuadas, a efectuar y detección de problemas </li></ul></ul><ul><li>Las tareas se publican en tarjetas (en un tablero de corcho) y se reestiman diariamente </li></ul><ul><li>El progreso se visualiza en gráficos de “burn-down” </li></ul><ul><li>Los líderes de cada equipo también se reúnen diariamente para analizar balance de carga y ver temas de integración </li></ul>
  65. 65. Las herramientas
  66. 66. Las herramientas (2)
  67. 67. Las herramientas (3)
  68. 68. Las herramientas (4)
  69. 69. Resultados del proyecto <ul><li>El proyecto logró cumplir con sus plazos manteniendo buenos niveles de calidad </li></ul><ul><li>Los problemas de visibilidad se redujeron, los compromisos se reafirmaron </li></ul><ul><li>El equipo recuperó la confianza y aprendió a autogestionarse y apoyarse en la administración para resolver los problemas ASAP </li></ul><ul><li>Al delegar responsabilidades de gestión más otros miembros del equipo quedaron con la capacidad de liderar equipos y la administración pudo dedicarse a temas más estratégicos </li></ul>
  70. 70. Para tener en cuenta <ul><li>SCRUM se usó para resolver los problemas de gestión del proyecto, fue apropiado porque: </li></ul><ul><ul><li>Aumentó la comunicación, la visibilidad, el trabajo en equipo y el compromiso </li></ul></ul><ul><ul><li>Hizo a los equipos más aptos para responder flexiblemente al ambiente con alta tasa de cambios </li></ul></ul><ul><li>SCRUM no aportó prácticas de ingeniería o diseño, estas se conservaron y varias fueron determinantes para los resultados (p.ej. La integración continua el código) </li></ul><ul><li>Las prácticas más livianas (pero no menos disciplinadas) fueron más fáciles de implementar y de comprender para el equipo, especialmente los “no-ingenieros” </li></ul>
  71. 71. No todo es color de rosa <ul><li>En las primeras iteraciones (Sprints) fue muy difícil llegar a estimaciones precisas para el trabajo de todo el mes (se revisaba por nuevas tareas semanalmente) </li></ul><ul><li>Al principio el equipo recibió el método como “otra de esas ideas” de la gerencia y no asumió el compromiso </li></ul><ul><li>Varios miembros del equipo fueron renuentes a escribir todas sus tareas en el backlog y más aún a reestimarlas diariamente </li></ul>
  72. 72. ¿Y qué pasó después? <ul><li>Ante los buenos resultados se decidió continuar usando SCRUM para gestionar los proyectos (ya se han iniciado 3 más), el equipo participó completamente en esa decisión </li></ul><ul><li>Se profundizó y “formalizó” la implementación de la metodología con las herramientas y prácticas restantes </li></ul><ul><li>El proyecto de mejora se reorganizó: ahora se busca fortalecer otros procesos usando CMMI como referencia pero manteniendo la agilidad </li></ul>
  73. 73. Índice del Módulo <ul><li>Escenario 1: Usando Prácticas Ágiles para Sobrevivir a Cambios Drásticos en el Cronograma </li></ul><ul><li>Escenario 2: Implementando una Metodología Ágil completa </li></ul><ul><li>Escenario 3: CMMI Complementando lo Ágil </li></ul><ul><li>Escenario 4: Prácticas Ágiles Complementando CMMI para salvar un Proyecto en Problemas </li></ul>
  74. 74. Una historia diferente <ul><li>Esta experiencia es de una empresa pequeña de desarrollo ya usaba una metodología ágil y tiene la necesidad de “certificar” CMMI, al menos nivel 2 </li></ul><ul><li>El equipo de trabajo y la administración están muy satisfechos con los resultados que les ha traído usar esta metodología ágil y no quieren perder eso </li></ul><ul><li>Qué dilema!!! Necesitamos ser CMMI pero queremos ser ágiles, qué se puede hacer? </li></ul>
  75. 75. El contexto <ul><li>Una empresa de desarrollo de software bancario con algo más de 50 personas </li></ul><ul><li>El área a evaluar tiene solo 6 personas!!! </li></ul><ul><li>Usan Crystal Clear, una de las metodologías ágiles más livianas </li></ul><ul><li>Hay que desarrollar 6 áreas de proceso (no SAM) para nivel 2 y que no se pierda la esencia de lo ágil </li></ul>
  76. 76. Las fortalezas presentes <ul><li>Un ciclo de vida definido: iterativo-incremental </li></ul><ul><li>Se lleva un backlog de tareas y se realiza seguimiento y registro diario de su estado con gráficos de “burn-down” </li></ul><ul><li>Además del backlog de cada iteración existe un cronograma de iteraciones </li></ul><ul><li>Se lleva un backlog de riesgos y problemas </li></ul><ul><li>Hay integración continua del código y pruebas unitarias automáticas (que se codifican antes de los programas) </li></ul>
  77. 77. Las cosas a mejorar <ul><li>La administración de requerimientos es demasiado informal </li></ul><ul><li>No existe un proceso de estimación </li></ul><ul><li>Varios de los aspectos importantes de planificación no se tienen en cuenta explícitamente </li></ul><ul><li>No hay prácticas de QA </li></ul><ul><li>No hay mediciones (ni análisis por supuesto) </li></ul>
  78. 78. Principales puntos de trabajo <ul><li>Foco muy fuerte en uso de herramientas para automatizar procesos (administración de requerimientos p.ej.) </li></ul><ul><li>Definir artefactos de trabajo más livianos que cumplieran los requisitos del modelo CMMI </li></ul><ul><li>Definir los procesos inexistentes con la filosofía de trabajo ágil (estimación, QA, métricas) </li></ul>
  79. 79. Lo que aprendimos y lo que viene <ul><li>Fue más difícil lograr que ciertos artefactos requeridos pudieran ser usados en el ambiente sin limitar su agilidad que usar los artefactos ágiles presentes para cumplir los requisitos del modelo </li></ul><ul><li>La etapa de definiciones finalizó y se inició el pilotaje de los procesos con muy buenos resultados hasta ahora </li></ul><ul><li>Se espera realizar la evaluación en marzo del 2006 </li></ul>
  80. 80. Índice del Módulo <ul><li>Escenario 1: Usando Prácticas Ágiles para Sobrevivir a Cambios Drásticos en el Cronograma </li></ul><ul><li>Escenario 2: Implementando una Metodología Ágil completa </li></ul><ul><li>Escenario 3: CMMI Complementando lo Ágil </li></ul><ul><li>Escenario 4: Prácticas Ágiles Complementando CMMI para salvar un Proyecto en Problemas </li></ul>
  81. 81. No solo en pequeñas empresas <ul><li>Esta es una experiencia de uso de prácticas ágiles en un proyecto en una empresa de servicios de salud y financieros que emplea a más de 2000 personas (+200 en IT, +130 en desarrollo) </li></ul><ul><li>Esta empresa está en camino de evaluación de CMMI nivel 3 a mediados del próximo año y tiene ya varios procesos establecidos y en uso en varias áreas </li></ul><ul><li>La necesidad de las prácticas ágiles surge dentro de un proyecto que es crítico para el negocio, con plazos muy agresivos y que ha tenido dificultades para mostrar resultados tangibles </li></ul>
  82. 82. Un proyecto en crisis <ul><li>Es el proyecto de desarrollo de un nuevo producto para el negocio, esta no es una empresa de desarrollo </li></ul><ul><li>Después de más de 6 meses de proyecto aún no se ha entregado ni una sola característica del producto funcionando </li></ul><ul><li>Un proyecto hermano se canceló y el usuario está muy tenso, en menos de tres meses se debe vender el primer producto y la solución tiene que estar lista </li></ul><ul><li>La fecha de entrega de la versión con las primeras funcionalidades no se cumplió, el usuario otorga un mes más para mostrar algo o… </li></ul>
  83. 83. Nuestras debilidades <ul><li>Los procesos de gestión establecidos no son suficientes para manejar varios aspectos conflictivos del proyecto </li></ul><ul><li>Los miembros del equipo están confundidos sobre sus responsabilidades y varios vienen con muy baja moral (del proyecto cancelado) </li></ul><ul><li>Se necesita visibilidad permanente para tomar medidas a tiempo </li></ul>
  84. 84. SCRUM ataca de nuevo <ul><li>Se reubica el equipo en un solo espacio para que queden colocalizados </li></ul><ul><li>Se transmiten los valores y principios de SCRUM al equipo y se dejan claros los objetivos del primer mes </li></ul><ul><li>Se prepara una sesión para planificar el mes, en esta sesión se asignan responsabilidades, se revisan dedicaciones, se resuelven problemas y se inicia el backlog </li></ul><ul><li>Se inician las reuniones diarias controlando el foco del equipo, el backlog se actualiza diariamente y se publican las tareas y los gráficos de “burn-down” </li></ul>
  85. 85. Resultados iniciales <ul><li>El equipo cumple la primera meta, quedan menos de dos meses para la meta final pero ahora hay más confianza </li></ul><ul><li>El equipo trabaja como equipo, las responsabilidades y compromisos están claros </li></ul><ul><li>Ya existe una versión de producto funcional que el usuario puede probar y que demuestra que el equipo si es capaz de cumplir compromisos y mostrar resultados </li></ul><ul><li>Otros proyectos, jefaturas de área y gerencias se muestran impresionados por la dinámica que se logra del equipo y asisten como oyentes a las reuniones diarias </li></ul>
  86. 86. Burn-down del primer Sprint
  87. 87. Nadie dijo que era fácil <ul><li>La reunión inicial de planificación que SCRUM propone de 8 horas tomo 2 días y medio!!! Se cumplieron los objetivos pero superando muchos momentos difíciles y de frustración </li></ul><ul><li>El equipo tuvo muchas dificultades para trabajar coordinadamente y ajustar y balancear tareas </li></ul><ul><li>También hubo dificultades de estimación (en ambos sentidos) que se hicieron evidentes el primer Sprint </li></ul>
  88. 88. No hay incompatibilidades <ul><li>Los procesos de gestión de SCRUM se integraron bien con los procesos más formales de planificación y seguimiento ya establecidos </li></ul><ul><li>Se mantuvieron los artefactos y prácticas de ingeniería establecidos con las adaptaciones necesarias de uno y otro lado </li></ul><ul><li>De nuevo, se soportó el desarrollo en práctica de integración continua que no estuvo exenta de dificultades debido a los estándares más rigurosos de la organización </li></ul>
  89. 89. Lo que viene <ul><li>El equipo continua con sus siguientes iteraciones (2 más) para cumplir la meta final, se espera un aumento significativo de la productividad </li></ul><ul><li>Se analizará la conveniencia de involucrar SCRUM como parte de los procesos estándar para uso en algunos proyectos específicos </li></ul>
  90. 90. ¿Preguntas?
  91. 91. Prácticas Ágiles en Mejora de Procesos Introducción Escenarios de Aplicación ¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil? Conclusiones y Recomendaciones
  92. 92. Índice del Módulo <ul><li>Recapitulando </li></ul><ul><li>Factores a analizar para el uso de prácticas ágiles </li></ul><ul><li>Factores de éxito </li></ul><ul><li>Beneficios conocidos </li></ul><ul><li>Riesgos </li></ul>
  93. 93. Recapitulando <ul><li>Es claro que lo “ágil” es una alternativa real para los proyectos de mejora </li></ul><ul><li>Decimos que es real porque no puede negarse que tiene una fuerza importante y una presencia cada vez mayor en muchos y diferentes ambientes y no solo en desarrollo de software </li></ul><ul><li>Además hemos visto varios escenarios en el que a partir de experiencias en terreno se han probado sus beneficios y aprendido de sus limitaciones </li></ul><ul><li>Estos escenarios muestran que para la mejora no hay que escoger disyuntivamente entre modelos formales y modelos ágiles </li></ul>
  94. 94. La necesidad del balance <ul><li>Hoy es reconocido que no existe una metodología única para todos los tipos de proyecto </li></ul><ul><li>Proyectos diferentes, contextos diferentes, equipos diferentes necesitan metodologías diferentes para lograr sus objetivos </li></ul><ul><li>Por eso no se puede suponer que existe un modelo completo (recordemos “No Silver Bullet” de Brooks) </li></ul><ul><li>Por otro lado los modelos formales y ágiles han logrado éxitos en sus propios “nichos” </li></ul><ul><li>El problema es que en los negocios y actividades de hoy más complejas y vertiginosas las condiciones de esos “nichos” se entremezclan continuamente y necesitamos escoger lo mejor de ambos mundos </li></ul>
  95. 95. Analizando los factores de balance Tomado de Boehm and Turner, Balancing Agility and Discipline, 2000
  96. 96. Factores de éxito en el balance <ul><li>Mantener el foco en agregar valor a las actividades (evitar la “procesitis”) </li></ul><ul><li>No asumir posiciones radicales para ningún lado </li></ul><ul><li>No perder de vista las restricciones </li></ul><ul><li>No asumir que porque ha funcionado para otros va a funcionar para mi, hay que mantener control y visibilidad constantes </li></ul><ul><li>No asumir que porque funcionó una vez va a funcionar siempre, (idem al anterior) </li></ul><ul><li>Se aplica lo que se predica, se usa al implementar la misma disciplina que se exige </li></ul>
  97. 97. Al usar prácticas ágiles tener en cuenta <ul><li>Pequeños incrementos que funcionen orientados por el valor que agregan </li></ul><ul><li>Se privilegia la gente, hay que estar atentos a sus necesidades y motivaciones y también a sus capacidades </li></ul><ul><li>Hacer foco continuo en la transmisión de valores y principios </li></ul><ul><li>Fomentar intensamente el trabajo de equipo y la comunicación directa </li></ul><ul><li>Promover un ambiente de excelencia </li></ul><ul><li>En esencia: ser ágiles también para implementar!!! </li></ul>
  98. 98. Un ejemplo de balance:
  99. 99. IDEAL + SCRUM: Guiando el proyecto de mejora <ul><li>IDEAL sienta el marco general y las etapas e hitos clave </li></ul><ul><li>Con SCRUM se definen actividades concretas en iteraciones para cada unidad de mejora </li></ul><ul><li>Al inicio de cada iteración se planifica el SCRUM, este se convierte en el plan táctico de cada unidad de mejora </li></ul><ul><li>El equipo de mejora se mantiene informado y se registran los problemas y el progreso diariamente </li></ul><ul><li>Al final de cada iteración se revisan los avances y se analizan los resultados para proponer mejoras </li></ul>
  100. 100. Beneficios esperables del balance <ul><li>Procesos más efectivos </li></ul><ul><li>Menos burocracia, mayor valor agregado </li></ul><ul><li>Personas y equipos más comprometidos, más motivados </li></ul><ul><li>Mejor comunicación y visibilidad de resultados </li></ul><ul><li>Resultados tangibles más pronto </li></ul>
  101. 101. Riesgos conocidos <ul><li>El número uno: malas interpretaciones y posiciones radicales, propias y del equipo </li></ul><ul><li>No planificar las mejoras ni realizar seguimiento y control constantes (no porque sea ágil se implementa solo) </li></ul><ul><li>Abandonar las buenas prácticas que ya existían por “la nueva onda” </li></ul><ul><li>Perder el impulso inicial (con lo ágil también puede pasar) </li></ul>
  102. 102. ¿Preguntas?
  103. 103. Prácticas Ágiles en Mejora de Procesos Introducción Escenarios de Aplicación ¿Cómo Llevar a Cabo un Proyecto de Mejora Ágil? Conclusiones y Recomendaciones
  104. 104. Resumiendo … <ul><li>Las metodologías ágiles surgen en los años 90 , como respuesta a un contexto de desarrollo de software turbulento y cambiante . </li></ul><ul><li>Lo ágil se define (por los mismos “agilistas”) como la habilidad de responder de forma versátil al cambio para maximizar los beneficios </li></ul><ul><li>Hacia el año 2001, los principales promotores de este tipo de metodologías crean la “alianza ágil”. </li></ul><ul><li>La alianza ágil enuncia los principios de lo “ágil” en el llamado “manifiesto ágil”. </li></ul><ul><li>En general, una metodología ágil es aquella que adhiere a los valores y principios del manifiesto . </li></ul><ul><ul><li>Usar procesos de construcción iterativos </li></ul></ul><ul><ul><li>Entregar software funcional lo más pronto posible </li></ul></ul><ul><ul><li>Privilegiar el valor de la gente sobre el valor del proceso </li></ul></ul><ul><ul><li>Fortalecer la comunicación y la colaboración </li></ul></ul>
  105. 105. ¿Los Conceptos son Nuevos? <ul><li>Los conceptos subyacentes a las mismas no son necesariamente nuevos , aunque toman nueva importancia a partir del momento en que se usan combinados . </li></ul><ul><ul><li>Prácticas como iteraciones cortas para reducir el riesgo, programación de a pares, etc, ya existían mucho antes de que el mismo concepto de ágil existiera. </li></ul></ul><ul><ul><li>Incluso en otras industrias, el concepto de “reducir el peso del proceso” existe ya desde hace mucho tiempo (p. ej. Lean, Auto-Dirección). </li></ul></ul><ul><li>Una lectura de este hecho es que nadie debería “alarmarse” por las prácticas ágiles. Son buenas prácticas que ya existían, “empaquetadas” de una manera nueva, para atender necesidades del contexto actual. </li></ul>
  106. 106. ¡Ni Héroes ni Villanos! <ul><li>Hay una serie de malas interpretaciones en uno y otro sentido (ágiles y tradicionales). </li></ul><ul><ul><li>Mitos y realidades sobre Ágil vs. Hacker, Diseño, Pruebas, Planificación, Ágil vs. CMMI, etc. </li></ul></ul><ul><li>Las metodologías ágiles no son “balas de plata” pero tampoco son “la peor desgracia” sucedida a la ingeniería de software. </li></ul>
  107. 107. Recomendaciones para Mejora Ágil <ul><li>Es claro que lo “ágil” es una alternativa real para los proyectos de mejora </li></ul><ul><li>Hemos visto varios escenarios en el que a partir de experiencias en terreno se han probado sus beneficios y aprendido de sus limitaciones </li></ul><ul><li>No necesariamente hay que implementar una metodología ágil completa . Se pueden combinar con CMMI, se pueden implementar ciertas prácticas clave … </li></ul><ul><li>Cómo en la mayoría de las iniciativas de mejora de procesos, la clave parece estar en una sana mezcla de las prácticas que mejor se ajustan a la organización . </li></ul>¡¡Recordemos que en todos los casos, la metodología debe adaptarse a la organización, y no a la inversa!
  108. 108. Conclusiones Finales <ul><li>Ningún planteamiento es completo por si mismo , dado que ninguna metodología es apropiada para todos los proyectos, equipos y compañías </li></ul><ul><li>¡Ser ágil no necesariamente significa lo mismo en todo contexto! </li></ul><ul><ul><li>¿Es lo mismo ser ágil para una compañía de aviones que para una pequeña compañía de IS? </li></ul></ul><ul><li>Es posible y recomendable encontrar el balance que permite agregar el mayor valor a mi proceso , mi equipo, mi proyecto </li></ul>“ LA CLAVE ES EL BALANCE” Cantidad de Personas 1-6 20 40 100 500 … Pérdida de Confort Pérdida Monetaria Discreta Pérdida Monetaria Esencial Pérdida de Vidas Criticidad Peso
  109. 109. ¿Preguntas?
  110. 110. Autores Walter Ariel Risi Pragma Consultores [email_address] Miroslav Pavlovic Practia Consulting [email_address] John Gómez Practia Consulting [email_address] ¡¡¡Muchas Gracias!!!
  111. 111. Para mayor información Argentina San Martín 575 4to (C1004AAK) Buenos Aires Tel (+5411) 4327-1999 [email_address] España Sta. Engracia, 169 (28003) Madrid Tel (+ 3491) 295-1547 [email_address] Visite nuestros WEB SITES: www.pragmaconsultores.com - Información Detallada de Servicios - Nuestra Experiencia: Clientes y Proyectos - Nuestro Compromiso y Nuestra Metodología de Trabajo www.qafactory.com - Fábrica de Aseguramiento de la Calidad - Beneficios y Detalle del Servicio Contáctenos: Chile Luis T. Ojeda 0191 Of. 701, Providencia, Santiago Tel (+562) 334-3361 [email_address]

×