Gestión basada en Metodologías Ágiles

2,211 views

Published on

Presentación elaborada por Miquel Rodríguez, nuestro director de Formación y Mentoring, para su conferencia en la Xunta de Galicia

Published in: Technology
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total views
2,211
On SlideShare
0
From Embeds
0
Number of Embeds
111
Actions
Shares
0
Downloads
137
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide

Gestión basada en Metodologías Ágiles

  1. 1. F O C U S Q U A L I T Y E X P E R I E N C E
  2. 2. Presentación Miquel Rodríguez Director de Formación y Mentoring en netmind Master in IT Management Executive MBA Certified SAFe Program Consultant Certified Scrum Master Project Management Professional (PMP) PRINCE2 Practitioner miquelra@netmind.es es.linkedin.com/in/miquelrodriguezaranda @miquelrodriguez @netmindIT blog.netmind.es www.netmind.es
  3. 3. En un mundo IDEAL...
  4. 4. Requisitos & Plan de Proyecto En un mundo IDEAL... Análisis Diseño Construcción Validación Entrega El cliente sabe lo que quiere El equipo sabe como hacerlo Se documentan y aprueban los requisitos y el Plan de Proyecto
  5. 5. Requisitos & Plan de Proyecto En un mundo IDEAL... Análisis Diseño Construcción Validación Entrega Diseño funcional Avanzamos… todo va bien….
  6. 6. Requisitos & Plan de Proyecto En un mundo IDEAL... Análisis Diseño Construcción Validación Entrega Y seguimos avanzando… Diseño funcional Diseño técnico
  7. 7. Requisitos & Plan de Proyecto En un mundo IDEAL... Análisis Diseño Construcción Validación Entrega Funciona a la primera…! Diseño funcional Diseño técnico Resultados de las pruebas
  8. 8. Requisitos & Plan de Proyecto En un mundo IDEAL... Análisis Diseño Construcción Validación Entrega El cliente obtiene lo que pidió. (¡A tiempo y sin sobrecostes!)Diseño funcional Diseño técnico Resultados de las pruebas
  9. 9. Una causa habitual de desastre en proyectos de desarrollo de software es que el producto final es precisamente lo que el cliente solicitó. The Economist. Agility counts “ ” http://www.economist.com/node/779429
  10. 10. Andar sobre el agua y construir según requisitos es sencillo. Solo es necesario que estén congelados. Edward V. Berard’s Law Edward V. Berard (1993) Essays on object-oriented software engineering “ ”
  11. 11. Nada es veneno, todo es veneno: la diferencia está en la dosis. Paracelsus Alquimista y Médico Suizo “ ”
  12. 12. Las dosis del enfoque Ágil Personas ProcesosTecnología Comunicación Colaboración Confianza Empowerment Foco en End to End Priorizar por valor Mejora Continua Excelencia técnica Automatización Rapidez
  13. 13. No sé porqué me dan una cabeza cuando lo que necesito son dos brazos. “ ” Henry Ford Padre de las cadenas de producción
  14. 14. “Un gran poder conlleva una gran responsabilidad” Ben Parker (tío de Peter Parker)
  15. 15. Manifiesto por el Desarrollo Ágil de Software Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas http://agilemanifesto.org/iso/es/ © 2001 A través de este trabajo hemos aprendido a valorar:
  16. 16. http://agilemanifesto.org/iso/es/principles.html © 2001 Seguimos estos principios (1 de 2): 1.- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2.- Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3.- Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. 4.- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5.- Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 6.- El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. Principios del Manifiesto Ágil
  17. 17. http://agilemanifesto.org/iso/es/principles.html © 2001 Seguimos estos principios (2 de 2): 7.- El software funcionando es la medida principal de progreso. 8.- Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9.- La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. 10.- La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11.- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto- organizados. 12.- A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. Principios del Manifiesto Ágil
  18. 18. Bueno, rápido y barato. Elija dos. Anónimo (pero con toda la razón) “ ”
  19. 19. Cambiando la orientación del Triangulo de Hierro Constraints Requisitos Coste Tiempo Estimación Coste Tiempo Funcionalidades Predictivo Waterfall Adaptativo Agile Plan-Oriented Value Oriented
  20. 20. Ciclo de vida tradicional vs ágil ANÁLISIS DISEÑO CONSTRUCCIÓN PRUEBAS IMPLANTACIÓN tiempo Supongamos un proyecto con las clásicas fases en cascada
  21. 21. Ciclo de vida tradicional vs ágil ANÁLISIS DISEÑO CONSTRUCCIÓN PRUEBAS IMPLANTACIÓN Rompemos el proyecto en pequeñas piezas que van de inicio a fin de todo el proceso…. tiempo
  22. 22. Ciclo de vida tradicional vs ágil ANÁLISIS DISEÑO CONSTRUCCIÓN PRUEBAS IMPLANTACIÓN tiempo Rompemos el proyecto en pequeñas piezas que van de inicio a fin de todo el proceso…. … y las vamos ejecutando secuencialmente, por iteraciones.
  23. 23. Ciclo de vida tradicional vs ágil ANÁLISIS DISEÑO CONSTRUCCIÓN PRUEBAS IMPLANTACIÓN Si por cualquier motivo nos desviamos un 10% en cada fase y tenemos comprometida la fecha de entrega, normalmente intentamos recuperar el tiempo perdido corriendo más al final, a costa de las pruebas. Como consecuencia, entregamos un producto incompleto, con errores y tarde. +10% +10% +10%+10% tiempo
  24. 24. Ciclo de vida tradicional vs ágil ANÁLISIS DISEÑO CONSTRUCCIÓN tiempo Y si, además, nos desviamos o nos encallamos en las fases iniciales, al llegar la fecha comprometida no tenemos más que documentos funcionales que no aportan ningún valor. +20%Analysis paralysis!!
  25. 25. Ciclo de vida tradicional vs ágil tiempo Si nos retrasamos un 10% en un enfoque incremental… … tenemos el 90% de nuestro producto. Y si hemos priorizado bien, tenemos el 90% que aporta más valor.
  26. 26. Ciclo de vida tradicional vs ágil Y si somos realmente lentos y poco efectivos…. … como mínimo tendremos un producto que aporta un subconjunto del valor por el que fue iniciado. tiempo
  27. 27. Agile Process Movement Iterative Processes Spiral RAD RUP… Agile (Adaptive) Processes Scrum, XP, Lean, Open UP, DSDM Atern, FDD, Crystal… 1970 1980 1990 2000 Predictive Process 2010 Scaling Agility to the Enterprise
  28. 28. Agile = Iterative + Incremental Henrik Kniberg Don’t try to get it all right from the beginning Don’t build it all at once cost value cost value
  29. 29. Not ”horizontal” increments Henrik Kniberg DB Server Client 1 2 3 1 2 3 4 value
  30. 30. ”Vertical” increments! Henrik Kniberg DB Server Client 1 5 2 3 1 432 value
  31. 31. Keep iterations short (2-3 weeks) Henrik Kniberg Short iteration Less likely to get interrupted Less scope creep
  32. 32. Planning is easier with frequent releases Henrik Kniberg
  33. 33. Priorización por valor y alcance + valor - valor nuevos elementos en cualquier momento re-priorización continua Seguro que podremos hacerlo Quizás podremos incluirlo Descartado, fuera del alcance
  34. 34. El primer vuelo de los hermanos Wright no tenía cuarto de baño ni carrito de bebidas. Puedes añadir funcionalidades más adelante. “ ” Paul Mockapetris Inventor del Sistema de Nombres de Dominio DNS valor
  35. 35. Ignoramos el hecho de que muchos clientes no saben lo que quieren. Ignoramos el hecho de que, incluso cuando saben lo que quieren, no saben cómo describirlo. Ignoramos el hecho de que, incluso cuando pueden describirlo, normalmente nos describen una propuesta de solución en lugar de describir sus necesidades reales. Don Reinertsen Autor de “The Principles of Product Development Flow: Second Generation Lean Product Development” “ ” Detección y descripción del valor
  36. 36. Mi maleta pesa demasiado, por tanto necesito una maleta más ligera. En realidad… ¡No me importa el peso! ¡Si tiene ruedas es fácil de transportar! Detección y descripción del valor
  37. 37. No me gustan los estudios de mercado. El cliente no sabe lo que quiere hasta que no lo tiene delante. “ ”Steve Jobs
  38. 38. Priorización 29 de junio de 2007 Lanzamiento del primer iPhone 17 de junio de 2009 Envío de MMS, copiar & pegar Priorizar funcionalidades es un aspecto clave para entregar valor lo antes posible
  39. 39. El valor de una funcionalidad disminuye con el tiempo Entregadevalor Tiempo Valor de mercado de una funcionalidad con el tiempo Margen acumulado Margen acumulado en Waterfall
  40. 40. Features have different value (and value is independent of size) Henrik Kniberg 2 minute standup discussion (pair/trio): • Give a real-life example of a feature that is small and very valuable • Give a real-life example of a feature that is large and not very valuable. Weight: 1 gram Value: 100 000 kr Weight: 2000 grams Value: 5 kr 2:001:591:581:571:561:551:541:531:521:511:501:491:481:471:461:451:441:431:421:411:401:391:381:371:361:351:341:331:321:311:301:291:281:271:261:251:241:231:221:211:201:191:181:171:161:151:141:131:121:111:101:091:081:071:061:051:041:031:021:011:000:590:580:570:560:550:540:530:520:510:500:490:480:470:460:450:440:430:420:410:400:390:380:370:360:350:340:330:320:310:300:290:280:270:260:250:240:230:220:210:200:190:180:170:160:150:140:130:120:110:100:090:080:070:060:050:040:030:020:01Done
  41. 41. Henrik Kniberg Maximize Value, not Output
  42. 42. Velocity to know the future, you need to know the past Henrik Kniberg When will we get there? We are here Our steps so far
  43. 43. Velocity-based release planning Henrik Kniberg Backlog
  44. 44. Velocity-based release planning Henrik Kniberg Done! Jan
  45. 45. Velocity-based release planning Henrik Kniberg Done! Jan Done! Feb
  46. 46. Velocity-based release planning Henrik Kniberg Done! Jan Done! Feb Done! Mar Q2 forecast All of these Some of these None of these
  47. 47. Release burnup chart Henrik Kniberg Delivered features Date
  48. 48. Fixed scope forecast Henrik Kniberg Delivered features Date When will all of this be done? Around week 27-30
  49. 49. Fixed time forecast Henrik Kniberg Date What will be done by Christmas? Some of these All of these Delivered features
  50. 50. Fixed time & scope forecast Henrik Kniberg Date Can we get all of THIS done... Delivered features ....by Christmas? No. That is unrealistic.
  51. 51. Fixed time & scope forecast Henrik Kniberg Date Delivered features We can get THIS much done by Christmas ...and the rest done by February. No. That is unrealistic.
  52. 52. ¿…por qué seguimos utilizando el modelo tradicional? Eh! Un momento…! …mmmm…. …entonces….
  53. 53. Insanity: doing the same thing over and over again and expecting different results. “ ”
  54. 54. La única persona que desea un cambio es un bebé con el pañal mojado. Anónimo (atribuido a Mark Twain) “ ”
  55. 55. http://upload.wikimedia.org/wikipedia/commons/f/f3/Uncle_Sam_(pointing_finger).jpg ¿Qué estás haciendo TÚ para cambiar?
  56. 56. Un 83% de las empresas TIC usan metodologías ágiles para el desarrollo de sus aplicaciones, ya que éstas les permiten adaptarse mejor a los cambios del mercado. Veamos qué están haciendo otros… http://www.tecnologiapyme.com/movilidad/el-83-de-las-empresas-usan-metodologias-agiles-para-el-desarrollo-de-sus-aplicaciones Metodologías ágiles 83% 17%
  57. 57. The United States is going to maintain our military superiority with armed forces that are agile, flexible and ready for the full range of contingencies and threats. Barack Obama “ ”
  58. 58. Kanban ScrumXP Agile & Lean Enfoque Product Management Project Management Team Management Técnicas de desarrollo Ingeniería Service Management Continuous Flow Visual Management El enfoque Agile
  59. 59. Kanban ScrumXP Agile & Lean Enfoque Product Management Project Management Team Management Técnicas de desarrollo Ingeniería Service Management Continuous Flow Visual Management El enfoque Agile
  60. 60. ¿Qué es Agile? Agile es entrega temprana de valor de negocio. “ ”Henrik Kniberg Consultor, Agile & Lean Coach
  61. 61. Lean Thinking Una manera de pensar que permite a las organizaciones especificar el valor, alinear las actividades que añaden valor en la mejor secuencia posible, desarrollar estas actividades sin interrupción cuando alguien las solicita y desempeñarlas más y más eficientemente.
  62. 62. Craft Production Mass Production Toyota Production System Proved the value of continual improvement at General Electric Customization Highly skilled workforce High cost Moving Production Line Production Engineering Low cost, inflexible model Focus on quality Just-in-time production Continual Improvement Taylor Lean In Service Services & Health Professionals Productivity improvement Business process improvement Deming Momentos clave en la historia de Lean 1910 1920 19551887 2000 Scientific management, labour productivity Jack Welch
  63. 63. A consequence of Lean is a paradigm shift Traditional Lean Managers have all the answers Manager should ask the right questions, employees should have the answers as a team Managers do the thinking, workers concentrate on doing Managers facilitate the workers to add value Activities are done, because they are asked to be done Activities are only done if they add value A certain rate of defects is unavoidable Defects can be eliminated Constancy of Purpose Respect for the people Perfection Lean Principles
  64. 64. Contratos en proyectos ágiles Colaboración con el cliente sobre negociación contractual Más importante Importante
  65. 65. ….¿Es esto un contrato ágil? :-)
  66. 66.  Money for Nothing & Changes for Free
  67. 67. Kanban ScrumXP Agile & Lean Enfoque Product Management Project Management Team Management Técnicas de desarrollo Ingeniería Service Management Continuous Flow Visual Management El enfoque Agile
  68. 68. Stop Starting, Start Finishing Pull vs Push
  69. 69. Kanban Kanban es un método para gestionar el trabajo basado en Pull, Just in Time, y limitando el trabajo en curso (WIP) Visualiza el flujo de trabajo Rompe el trabajo en piezas, representa cada una de ellas en una tarjeta y pégalo en la pared. Utiliza columnas con nombres para ilustrar donde está cada elemento dentro del flujo. Limita el trabajo en curso (WIP) Asigna límites explícitos para ver cuantos elementos puede haber en curso para cada estado del flujo. Mide el tiempo de inicio a fin (Lead Time) Optimiza el proceso para conseguir que el tiempo de inicio a fin sea el mínimo possible. Kanban and Scrum. Making the most of both. Henrik Kniberg & Mattias Skarin
  70. 70. Pending Doing Done Kanban Board
  71. 71. Pending Developing Testing Done Problems Kanban Board
  72. 72. Capacidad
  73. 73. Pending Developing Testing Done Problems Kanban Board + WIP WIP limit = 4 Céntrate en finalizar estos antes de añadir otro elemento WIP limit = 3
  74. 74. Kanban kick-start example http://www.crisp.se/file-uploads/kanban-example.pdf
  75. 75. Visual Management http://www.flickr.com/photos/yveshanoulle/
  76. 76. Low-tech, Multipurpose, Easy to Adapt & Understand
  77. 77. ¿Cómo empezamos a aplicar Kanban? Empieza con lo que ya estás haciendo Modifícalo ligeramente para poder aplicar Pull Utiliza un método transparente para visualizer el trabajo y organizer el equipo Limita el WIP y coge el trabajo cuando el equipo tiene suficiente capacidad para hacerlo Evoluciona identificando cuellos de botella, eliminando trabajo no necesario, ajustando el WIP y analizando como esta variabilidad afecta al rendimiento 1 4 3 2 5 Kanban: Successful Evolutionary Change for Your Technology Business: David Anderson
  78. 78. Kanban ScrumXP Agile & Lean Enfoque Product Management Project Management Team Management Técnicas de desarrollo Ingeniería Service Management Continuous Flow Visual Management El enfoque Agile
  79. 79. Scrum http://www.scrumalliance.org/ Roles • Product Owner • Development Team Member • Scrum Master Artefactos • Product Backlog • Sprint Backlog • Product Increment Actividades / Reuniones •Product Backlog Refinement •Sprint Planning •Daily Scrum •Sprint Review •Sprint Retrospective Scrum es un método iterativo e incremental para construir un producto
  80. 80. User Stories User Stories Applied: For Agile Software Development Mike Cohn 2004
  81. 81. User Story Pattern As a <user role> I can <activity> so that <business value>
  82. 82. Card, Conversation, Confirmation Card • Short statement, captured on a physical & small card • Metaphor providing a tangible and kinaesthetic relation between the team and “this thing the user wants to do”. • It also helps keep keeps the story lightweight and malleable Conversation • Conversation between the team, customer/user, the product owner, and other stakeholders. • This is the discussion necessary to determine the more detailed behavior required to implement the intent. • The conversation may spawn additional specificity in the form of attachments to the user story (mockup, spreadsheet, algorithm, timing diagram, etc) Confirmation • The stories acceptance criteria provides the precision necessary to assure that the story is implemented correctly and covers the relevant functional and non- functional requirements. • Agile teams automate acceptance tests wherever possible, oftentimes in a business- readable, domain- specific language, thereby creating the “automatically executable specification and test” of the code C C C
  83. 83. INVEST Independent (of all others, as much as possible) Negotiable (not a specific contract for features) Valuable (to the customer) Estimable (to a good approximation) Small (so it can be done by a few person-days work) Testable (in principle, even if there isn’t a test for it yet)
  84. 84. Estimating and Sizing with Story Points A Story Point is a common name for sizing work Arbitrary measure of relative unit of work used by teams. It depends on the effort, the complexity and the uncertainty related to the User Story Each team has his own “effort-translation” for a Story Point For some teams means “1 day” For some teams means “1 week” For some teams means “1 ideal day” For some teams means 4-hours
  85. 85. Fibonacci Sequence and other sizing methods As we’re interested in row order of magnitude, we can use several approachs: Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34,… Pseudo Fibonacci (most common): 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 T-Shirts: XL, L, M, S, XS http://www.mathsisfun.com/numbers/images/fibonacci-
  86. 86. Planning Poker http://www.mountaingoatsoftware.com/agile/planning-poker
  87. 87. Relative sizing ½, 1, 2, 3, 5, 8, 13, 20, 40, 100
  88. 88. Affinity Estimating
  89. 89. Kanban ScrumXP Agile & Lean Enfoque Product Management Project Management Team Management Técnicas de desarrollo Ingeniería Service Management Continuous Flow Visual Management El enfoque Agile
  90. 90. eXtreme Programming Practices Valores: Simplicidad Comunicación Feedback Coraje http://xprogramming.com
  91. 91. Releasing must be REALLY easy Henrik Kniberg Req Code Test Release! Release = Drama! Release = Routine
  92. 92. ¿Por qué aplicar técnicas ágiles? Porque funcionan… …. y es más divertido!
  93. 93. The Fun Theory
  94. 94. Ops…. x 50? x 500? x 5.000?
  95. 95. Challenges on Scaling Agile Huge teams Development process conflicts Legacy systems Different life cycles Globally distributed teams Functional & technological silos <Please add your challenge here> <Please add your challenge here> <Please add your challenge here>
  96. 96. Cross-functional teams are vertical Henrik Kniberg Client team C C C Test team T T T DB team D D D Server team S S S Feature team 1 C C S D T T C S D T Feature team 2 D S DB Server Client User Communities of interest
  97. 97. Spotify Henrik Kniberg Tribe Tribe Tribe TribeTribe Tribe
  98. 98. PO PO PO Tribe Tribe lead PO PO PO PO Tribe Chapter Chapter Tribe lead PO Chapter Chapter Guild Spotify
  99. 99. Scaled Agile Framework  Acerca de SAFe  Estructura de SAFe  Roles, ceremonias, trenes y escalabilidad  Casos de éxito y siguientes pasos
  100. 100. The Scaled Agile Framework (SAFe®) Sincronización, alineación, colaboración, entrega de valor Consultable en libros y en la web oficial Puede escalarse a un gran número de personas / equipos Core values: 1. Calidad del código 2. Ejecución de Programas 3. Alineación 4. Transparencia http://ScaledAgileFramework.com Scaled Agile Framework es un marco de trabajo para aplicar técnicas Lean y Agile a nivel empresarial
  101. 101. Estructura de SAFe Scaled Agile Framework
  102. 102. Agile Teams  Empowered, self-organizing, self-managing cross-functional teams  Valuable, fully-tested software increments every two weeks  Scrum project management practices and XP-inspired technical practices  Teams operate under program vision, system, architecture and user experience guidance  Value description via User Stories
  103. 103. Code Quality Agile Architecture Continuous Integration Test-First Refactoring Pair Work Collective Ownership Code Quality Provides:  Higher quality products and services, customer satisfaction  Predictability and integrity of software development  Development scalability  Higher development velocity, system performance and business agility  Ability to innovate You can’t scale crappy code
  104. 104. Iteraciones a nivel de equipo con ScrumXP
  105. 105. Equipos ágiles con ScrumXP Los equipos ágiles ScrumXP están basados en equipos Scrum, con algunas variaciones que facilitan su escalabilidad
  106. 106. Scale to the Program Level  Self-organizing, self-managing team-of-agile-teams  Continuous value delivery  Aligned to a common mission via a single backlog  Common sprint lengths and estimating  Face-to-face planning cadence for collaboration, alignment, synchronization, and assessment  Value description via Features and Benefits
  107. 107. Develop on Cadence. Deliver on Demand. Deliver on Demand Major Release Customer Upgrade Customer Preview Major Release New Feature Develop on Cadence PSI PSI PSI PSI PSI Development occurs on a fixed cadence. The business decides when value is released.
  108. 108. Program Execution  Driven by Vision and Roadmap  Lean, economic prioritization  Frequent, quality deliveries  Fast customer feedback  Fixed, reliable cadence  Regular Inspect and Adapt drives continuous improvement Agile Release Trains – self-organizing teams of agile teams – reliably and frequently deliver enterprise value
  109. 109. Scale to the Portfolio  Centralized strategy, decentralized execution  Investment themes provide operating budgets for trains  Kanban systems provide portfolio visibility and WIP limits  Objective metrics support governance and kaizen  Value description via Business and Architectural Epics
  110. 110. Alignment  Clear content authority  Face-to-face planning  Aligned Team, Program and Business Owner objectives  Cross-team and cross- program coordination  Architecture and UX guidance  Match demand to throughput Alignment Business Owners Alignment from Portfolio to Program to Team
  111. 111. Roles, ceremonias, trenes y escalabilidad
  112. 112. Roles por cada nivel Porfolio Level Program Level Team Level Program Portfolio Management Team Epic Owner Enterprise Architect Product Management Release Management Business Owner System Team DevOps Architect UX Release Train Engineer Product Owner Developers & Testers Scrum/Agile Master En cada nivel encontramos un conjunto de roles, que pueden ser compartidos en algunos casos
  113. 113. Agile Release Train Un Agile Release Train es un equipo-de-equipos auto-gestionado que entrega valor en una cadencia específica de forma continua
  114. 114. Agile Release Train Un Agile Release Train es en realidad un fractal de los sprints de los equipos, a nivel de Programa
  115. 115. Agile Release Train Compartir la misma cadencia no es suficiente…..
  116. 116. Agile Release Train … es necesaria una sincronización entre equipos de un mismo programa para garantizar la entrega coordinada
  117. 117. How Big Agile Release Trains can be?
  118. 118. Release Planning Meeting
  119. 119. Agenda para una Release Planning Meeting
  120. 120. Ubicación de la Release Planning Meeting dentro de la candencia - HIP
  121. 121. Entregables del Release Planning Meeting Cada equipo tiene sus objetivos, con el valor aportado al negocio, una temporalización por sprints de las Historias a entregar, y un plan de respuesta a riesgos.
  122. 122. Entregables del Release Planning Meeting Un Program Plan con las fechas previstas de entrega y otros hitos relevantes, con dependencias entre equipos, y una votación del nivel de confianza/compromiso de todo el programa Votación conjunta para poner en común el nivel de confianza del plan y actualizar objetivos
  123. 123. Casos de éxito – Empezando a andar
  124. 124. Experiencias de netmind con SAFe
  125. 125. netmind Agile Training & Mentoring Lean & Agile Development & Practices JST 291 | Lean IT Foundation JJM 188 | PMI Agile Certified Practitioner Exam Prep JJM 120 | Desarrollo Ágil con Scrum JJM 125 | Introducción al Desarrollo Ágil de Software JJM 126 | Gestión Ágil de Proyectos de Software JJM 130 | Estimación y Planificación Ágil de Proyectos de Software JJM 131 | Historias de Usuario para la Gestión Ágil de Requerimientos JJM 132 | Taller Práctico de Kanban. Gestión Visual del Desarrollo JJM 134 | Testing en el desarrollo del Software Scaled Agile Framework JJM 150 | SAFe ScrumXP for Teams JJM 151 | Leading the Lean-Agile Enterprise with Scaled Agile Framework www.netmind.es Coaching Definición Metodológica Herramientas (en proceso)
  126. 126. Y además…. 
  127. 127. Créditos      
  128. 128. F O C U S Q U A L I T Y E X P E R I E N C E 

×