Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

HABLEMOS DE AGILIDAD, SCRUM - RAZONES, FALLAS Y TIPS

Razones para adoptar ágil, fallas y tips para hacerlo de forma correcta.

- Hasta la diapositiva 51, introducción a la agilidas
- de la 52 a la 80 por que los equipos ágiles son más "rápidos" y efectivos
- de la 81 a la 94 errores en la adopcion agile
- de la 95 en adelante mitos y tips en la adopción ágil

  • Soyez le premier à commenter

HABLEMOS DE AGILIDAD, SCRUM - RAZONES, FALLAS Y TIPS

  1. 1. 1 HABLEMOS DE AGILIDAD RAZONES, FALLAS Y TIPS JORGE HERNÁN ABAD LONDOÑO @jorge_abad Blog http://www.lecciones-aprendidas.info/ Agile Coach, Project Leader, Scrum Master and Always a Learner
  2. 2. 2 Miembro de Ágiles Colombia
  3. 3. 3 Miembro PMI Capítulo Antioquia  pmiantioquia.org  @pmiantioquia  facebook.com/PMIAntioquia  meetup.com/es-ES/Proximo-Capitulo-PMI-Antioquia/
  4. 4. 4 Agenda  ¿Por qué adoptar metodologías ágiles?  ¿Por qué los equipos ágiles son más rápidos y efectivos que los tradicionales?  Fallas Comunes en la Adopción Ágil  Tips  Preguntas
  5. 5. 5 Agenda  ¿Por qué adoptar metodologías ágiles?  ¿Por qué los equipos ágiles son más rápidos y efectivos que los tradicionales?  Fallas Comunes en la Adopción Ágil  Tips  Preguntas
  6. 6. 6 ¿Quiénes…?
  7. 7. 7 Contestemos sinceramente
  8. 8. 8 UNAS PREGUNTAS ¿Quiénes han o les han fallado en una estimación el cuádruple… El triple…. El doble….?
  9. 9. 9 UNAS PREGUNTAS ¿Quiénes han trabajado seguido 6 meses o más… (sábados, domingos y festivos)?
  10. 10. 10 UNAS PREGUNTAS ¿Quiénes han trabajado más de 36 horas seguidas…? ¿24 horas…?
  11. 11. 11 UNAS PREGUNTAS ¿quiénes han tenido ultimatum familiar?
  12. 12. 12 Unas preguntas ¿Se les dañó un paseo o viaje planeado debido a un proyecto?
  13. 13. 13 UNAS PREGUNTAS ¿a quiénes se les ha dañado una entrega lista?
  14. 14. 14 UNAS PREGUNTAS les han dicho o han dicho: ¿es lo especificado pero no es lo que necesito?
  15. 15. 15 UNAS PREGUNTAS les han dicho o han dicho: ¿es lo especificado pero ya cambió el negocio?
  16. 16. 16 UNAS PREGUNTAS les han dicho o han dicho: ¿Cómo van a pagar ese tiempo?
  17. 17. 17 UNAS PREGUNTAS  Han dicho o han pedido ¿Una estimación EXACTA?
  18. 18. 18 UNAS PREGUNTAS Has dicho o has escuchado: ¿a eso vamos a tener que darle manejo?
  19. 19. 19 UNAS PREGUNTAS ¿los controles de cambio costaron más que el proyecto original?
  20. 20. 20 UNAS PREGUNTAS ¿consideran que el 100% del software construido es usado….?
  21. 21. 21 UNAS PREGUNTAS ¿el 90% del software? ¿el 80%? ¿el 70%? ¿el 60%? ¿el 50%?
  22. 22. 22 Chaos Manifesto 2013 http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf De las funcionalidades en el sw: • 20% usado frecuentemente • 30% usado algunas veces • 50% poco o nunca usadas Pareto también se cumple en software
  23. 23. 23 UNAS PREGUNTAS  Va el 92% de avance  Dos semanas después  Va el 92.4% de avance  Tres semanas después  Va el 92.7% de avance  Etc  Etc  Etc Han dicho o les han dicho
  24. 24. 24 UNAS PREGUNTAS ¿se han demorado cerrando el 10% del proyecto otro 90%? (o sea, más o menos el 180% del tiempo para todo el proyecto)
  25. 25. 25 UNAS PREGUNTAS  ¿Las salidas a producción son hiper-preparadas, le llenan de temor y terror y requieren de sus mejores “hombres”?
  26. 26. 26 UNAS PREGUNTAS ¿Quiénes han estado en un proyecto que se ha cumplido alcance, tiempo, costo, calidad y felicidad?
  27. 27. 27 ¿Dónde estamos?
  28. 28. 28 Creemos que hacer software es…
  29. 29. 29
  30. 30. 30
  31. 31. 31 Navegar en los ríos de la predictibilidad
  32. 32. 32 Ensamblar componentes y dar clic derecho: configurar y desplegar
  33. 33. 33 Para acabar más rápido pongo más UMPALUMPAS
  34. 34. 34 Hacemos software empleando el enfoque WATERFALL
  35. 35. 35
  36. 36. 36 Pero hacer software es…
  37. 37. 37
  38. 38. 38
  39. 39. 39  «Estudio de la Universidad de Missouri: la vida media del valor de los requisitos ha ido disminuyendo Exponencialmente. En 1980 esta fue de alrededor de 10 a 12 años, en el 2000 había caído a 2 a 3 años, y actualmente está funcionando a alrededor del 6 meses». "Software Development: How the Traditional Contract Model Increases the Risk of Failure" de Susan Atkinson y Gabrielle Benefield Radioactividad de los Requisitos
  40. 40. 40
  41. 41. 41 Hacer software es…  Saber trabajar REALMENTE en equipo  Que los riesgos saltan y se materializen por doquier  Convivir con la incertidumbre, y saber como reaccionar a ella.  Saber que no vamos a tenerlo TODO definido,  Aprender de las fallas y corregir el camino (Inspección y Adaptación)
  42. 42. 42
  43. 43. 43 Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series)
  44. 44. 44 ¿hemos tratado de resolver el problema del software con la herramienta equivocada?
  45. 45. 45 www.agilemanifesto.org
  46. 46. 46 Principios del Manifiesto Ágil  Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.  Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.  Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.  Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.  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.
  47. 47. 47 Principios del Manifiesto Ágil  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.  El software funcionando es la medida principal de progreso.  Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.  La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.  La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  48. 48. 48 Principios del Manifiesto Ágil  Las mejores arquitecturas, requisitos y diseños emergen de equipos auto- organizados.  A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
  49. 49. 49
  50. 50. 50 “Nuestro trabajo no es hacer (toneladas de) software, nuestro trabajo es hacer la MENOR cantidad de SOFTWARE que maximice el VALOR del negocio de nuestros clientes” Ángel Medinilla @angel_m
  51. 51. 51 Valor y riesgos en enfoque tradicional y ágil
  52. 52. 52 Agenda  ¿Por qué adoptar metodologías ágiles?  ¿Por qué los equipos ágiles son más rápidos que los tradicionales?  Fallas Comunes en la Adopción Ágil  Tips  Preguntas
  53. 53. 53 Repasemos un poco de Scrum
  54. 54. 54 Scrum Cancel Gift wrap Return Sprint 2-4 semanas Objetivo del Sprint Sprint Backlog Incremento del producto potencialmente entregable Product Backlog 24 horas
  55. 55. 55 Reuniones de Scrum
  56. 56. 56 • Sprint Execution • Review • Retrospectiva • Sprint Planning • (kaizen =mejora) Actuar Planear HacerVerificar SCRUM es un ciclo de mejora continua
  57. 57. 57 Hagamos recorderis  Recuerdan el Infome del caos donde la principales causas de fracaso son: – Falta de involucramiento del usuario* – Requisitos incompletos y cambiantes* – Expectativas irreales * – Falta de planificación *  Y las de éxito – Involucramiento del usuario* – Requisitos claros* – Hitos acotados* – Expectativas realista* – Buena planificación* – Proceso ágil** * The CHAOS Report (1994), Standish Group - http://www.standishgroup.com/sample_research/chaos_1994_1.php **The CHAOS Report (2013), Standish Group - http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf
  58. 58. 58 ¿En dónde radica la agilidad si los equipos ágiles hacen lo mismo o más que los tradicionales?
  59. 59. 59  Los roles adecuados para construir el producto – Product Owner – Scrum Master – Team Members No sobra, ni falta nadie No hay silos
  60. 60. 60 Un Product Owner  interesado en LIBERAR A PRODUCCIÓN EL PRODUCTO LO ANTES POSIBLE Y LO QUE MÁS VALOR GENERE  Que resuelve dudas durante el sprint, que tiene toda la autoridad sobre el producto • El involucramiento del usuario tan buscado • Se elimina la burocracia • Hay respuesta rápida a inquietudes del equipo
  61. 61. 61 El Scrum Master  cuida al proceso  está preocupado por mejorar cada vez el desempeño del equipo  Remueve impedimentos Un líder al servicio del equipo
  62. 62. 62 Un equipo:  Que tiene un objetivo claro  Que jala trabajo en un ciclo corto (pull) en vez de que se le asigne (push). Un equipo autoorganizado y multidisciplinario
  63. 63. 63 Enfoque en el valor y no en el alcance Se posterga lo incierto, se construye lo que genera valor
  64. 64. 64  Un Sprint Backlog congelado durante el sprint
  65. 65. 65  Un Planning que compromete a los directos responsables. El compromiso es asumido no asignado
  66. 66. 66 El Scrum Diario o Daily que sincroniza al equipo Evita el trabajo de islas y repúblicas independientes Ayuda a evidenciar problemas y resolverlos más rápido
  67. 67. 67  Un Review que permite validar el producto y compromete más al equipo Inspección y adaptación sobre el producto
  68. 68. 68  La retrospectiva que busca la mejora continua Inspección y adaptación sobre el equipo y proceso
  69. 69. 69  Ciclos cortos de desarrollo (Sprints) que –mitigan riesgos y que estos se propaguen por largos periodos –Evidenciar el avance
  70. 70. 70  Requerimientos (Historias de usuario, Casos de uso, etc) en Ready para el sprint backlog  No se trabaja en algo que no está claro
  71. 71. 71  La Definition of Done / DoD/ Definición de Terminado / Realizado que es el criterio de calidad y de entrega claro para todo el equipo
  72. 72. 72 TRANSPARENCIA  Transparencia (Visual Management) que permite a todos saber el estado del proyecto y del producto No hay posibilidad de darle “manejo”
  73. 73. 73 Existe una construcción orgánica y completa del producto, orientadas incialmente al MVP (Mínimo Producto Viable)
  74. 74. 74
  75. 75. 75 http://idrawgirls.com/tutorials/2011/12/12/painting-chinese- woman-portrait/
  76. 76. 76 Porciones completas de producto (software) Se entregan al final del ciclo porciones producto que se pueden poner en producción OJO: NO se entregan capas que NO le entregan valor al cliente
  77. 77. 77 Razones para la adopción ágil  La razón radica en que las prácticas de Scrum mitigan bastantes problemas del desarrollo tradicional y aligeran el desarrollo – eliminando reprocesos – mitigando riesgos más rápido – suprimiendo el desperdicio – acabando burocracia – Maximizando la comunicación – Enfocados en entregar software de valor lo antes posible
  78. 78. 78 Estos elementos estan enmarcados por Lean Software Development  Eliminar los desperdicios  Ampliar el aprendizaje  Decidir lo más tarde posible  Reaccionar tan rápido como sea posible  Potenciar el equipo  Crear la integridad  Véase todo el conjunto
  79. 79. 79 State of agile development survey. 9th -2015 Version One Logros de este enfoque
  80. 80. 80 Pero no debemos perder el foco Entender el problema LEAN AGILE ENFÓQUESE EN SOLUCIONES, NO EN SOFTWARE CONSTRUYA EL PRODUCTO CORRECTO CONSTRUYA DE LA FORMA CORRECTA
  81. 81. 81 Agenda  ¿Por qué adoptar metodologías ágiles?  ¿Por qué los equipos ágiles son más rápidos y efectivos que los tradicionales?  Fallas Comunes en la Adopción Ágil  Tips  Preguntas
  82. 82. 82 Fallas Comunes en la Adopción Ágil
  83. 83. 83  ¿Cual creen ustedes que es el punto de falla más critico de Scrum?
  84. 84. 84 Puntos de falla en el Product Owner  Sin visión  Sin un roadmap del producto o plan de releases  Sin poder sobre el backlog  No disponible para aclarar dudas  Un Product backlog no priorizado por valor de negocio
  85. 85. 85 Puntos de falla en el Scrum Master  Sin dedicación al equipo  Creer que su trabajo es mínimo  Que no remueve impedimentos  Que no «huele» impedimentos  Sin capacidad comunicativa  Que no escucha
  86. 86. 86 Puntos de falla en el Planning  El backlog no esta en ready  El equipo hace malas estimaciones  Existe sobre-estimación  Falta transparencia
  87. 87. 87 Puntos de falla en el Equipo  Pobre conocimiento técnico  Part –time  Multi-tasking individual  Prueban tarde  No es multidisciplinario y no puede lograr el DONE  No mejora técnicamente en prácticas de ingeniería  Mal uso de la libertad
  88. 88. 88 Puntos de falla en el Daily  Equipo superior a 9 personas  Las personas no hablan  Las personas no entienden para que sirve  Dura más de 15 minutos
  89. 89. 89 Puntos de falla en el Review  No muestra codigo trabajando y testeado (El incremento no esta en DONE)  No genere feedback sobre el producto  No se inviten interesados
  90. 90. 90 Puntos de falla en la Retrospectiva  No hay mejora sprint tras sprint  No genera impacto y compromiso en el equipo  Se desecha del framework  No se inspecciona y mejora el proceso y/o el equipo
  91. 91. 91 Puntos de falla en General  No hay mejora  No se eliminan los desperdicios  No hay enfoque en el valor  No se remueven impedimentos  Se hace microgestión  El equipo no es retado y se queda en zona de confort
  92. 92. 92 UN SPRINT DE ANÁLISIS UN SPRINT DE DESARROLLO UN SPRINT DE PRUEBAS Scrum un grupo de cascadas
  93. 93. 93 Si se evitan las malas prácticas
  94. 94. 94  Ken Schwaber: “En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”
  95. 95. 95 Creer que Scrum y las metodologías ágiles son una bala de plata Mitos, Monstruos y Leyendas Urbanas Ágil también falla
  96. 96. 96  En metodologías ágiles no se documenta Se documenta lo que agrega valor Mitos, Monstruos y Leyendas Urbanas
  97. 97. 97  En metodologías agiles no se realiza planeación User Story Map Mitos, Monstruos y Leyendas Urbanas
  98. 98. 98  Ágil no necesita diseño previo Hay un diseño que se realiza y se vá refinando Sprint tras Sprint Mitos, Monstruos y Leyendas Urbanas
  99. 99. 99  Ágil siempre usa “Historias de Usuario“ El Product Backlog no tiene prescrito que sean historias de usuario solo ítemes priorizados los cuales pueden ser requerimientos, en prosa, casos de uso, etc. Pero es de aclarar que las metodologiías ágiles funcionan mejor con historas de usuario. Mitos, Monstruos y Leyendas Urbanas
  100. 100. 100  Ágil no se usan herramientas Mitos, Monstruos y Leyendas Urbanas Las hay pero no son el foco, primero las personas y sus interacciones , luego las herramientas.
  101. 101. 101 Mitos, Monstruos  Ser ágil es solo proceso y no es necesario lo técnico Principio 9 del Manifiesto La atención continua a la excelencia técnica y al buen diseño mejora la agilidad
  102. 102. 102 Mitos, Monstruos  Ágil es solo para superdotados Principio 5 del Manifiesto 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.
  103. 103. 103 No hay • Ni compromisos • Ni planes • Ni métricas Es desarrollo hippie
  104. 104. 104  Scrum Master igual a Gerente de Proyecto  Podemos hacer Scrum sin un Dueño de Producto  Scrum no funciona con CMMI u otros modelos de procesos  Ágil significa más rápido Mitos, Monstruos y Leyendas Urbanas – Otros
  105. 105. 105 Tips para la adopción ágil
  106. 106. 106 Tips  Busque acompañamiento y otros que lo hayan logrado  El Scrum Master es esencial  No tenga equipos UNI-DISCIPLINARIOS  Garantice el DONE  Fortalezca el equipo técnicamente y tenga prácticas como TDD, Integración continua, ATDD, refactoring, automatización de pruebas, etc  Empiece con pocas métricas – Para medir la realidad de los proyectos – No a las personas
  107. 107. 107 Tips  Reclute al Cliente  Proporcione un Product Owner que tenga voz y voto sobre el producto y esté disponible para el equipo  Evalúe los contratos, permita la colaboración y el riesgo compartido  Haga una semilla y vaya creciendo poco a poco (Scrum orgánico)  Use scrum para implantar scrum – ciclos cortos, con planeación, revisión y retrospectiva
  108. 108. 108 Tips centrales de scrum  No combinar roles  No alargar, ni acortar los sprints  No suprimir reuniones  Retrospectivas, retrospectivas, restrospectivas, restrospectivas
  109. 109. 109 UNAS FRASES Y UNOS NÚMEROS PARA TERMINAR
  110. 110. 110  “Consistencia y predictibilidad aun son deseables, pero nunca han sido las cosas más importantes. En los últimos 40 años, por ejemplo, nos hemos torturado con nuestra incapacidad de terminar proyectos de software a tiempo y en el presupuesto. Pero esta nunca ha sido la meta suprema. La meta más importante es transformación, creando software que cambie el mundo o que transforme una compañía o cómo esta hace negocios.” Tom DeMarco 2009 - “Software Engineering: An Idea Whose Time Has Come and Gone?”
  111. 111. 111
  112. 112. 112 Olvídese de la frase, Mi Organización es un caso especial, «la verdad, todas lo son» Agile se puede implantar, ya no es una moda se esta convirtiendo en la forma de trabajo de la industria
  113. 113. 113
  114. 114. 114 PREGUNTAS
  115. 115. 115 ¡GRACIAS! Jorge H. Abad L. jorge.abad@gmail.com @jorge_abad Blog http://www.lecciones-aprendidas.info/
  116. 116. 116
  117. 117. 117Conferencia auspiciada por el PMI Antioquia Colombia Potential Chapter – La propiedad intelectual de esta pertenece al facilitador Anexos
  118. 118. 118 Estas presentación contiene algunas diapositivas de  LeanSight – Agustín Villena  Proyectalis - Ángel Medinilla  Henrik Kniberg  Lucho Salazar – Agil es algo que eres  Nota: Traté de dar crédito a todos, pero consideras que faltaste por que no te referencié o debo modificar algo de tu propiedad por favor no dudes en hacérmelo saber, contactándome al email: jorge.abad@gmail.com
  119. 119. 119 Aviso de Copyright  Usted es libre de: – Compartir- copiar, distribuir y trasmitir el trabajo – Modificar- adaptar el trabajo  Bajo las siguientes condiciones – Atribución. Ud. debe atribuir el trabajo en la manera especificada por el autor o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo).  Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor.  Para más información ver http://creativecommons.org/licenses/by/3.0/
  120. 120. 120 Información de contacto  Jorge Hernán Abad Londoño –jorge.abad@gmail.com –@jorge_abad

×