Curso Introducción a Agile
•Descargar como PPTX, PDF•
25 recomendaciones•6,807 vistas
Este documento presenta una introducción a la metodología ágil Scrum. Explica los roles de Product Owner, Equipo y ScrumMaster, el ciclo iterativo de planificación, desarrollo y revisión, y cómo se utilizan historias de usuario para priorizar el trabajo. También cubre técnicas como planning poker y daily meetings para estimar el trabajo y mejorar la comunicación del equipo.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Curso Introducción a Agile
Similar a Curso Introducción a Agile (20)
Último
Último (20)
Curso Introducción a Agile
- 1. Agile Curso de Introducción @agilebcn #agilebcn
- 2. Gracias!!
- 4. Agile: State of the art
- 5. agile?
- 6. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software que aporta valor.
- 7. Los cambios son bienvenidos, aún en fases tardias del desarrollo. Los procesos Agile consideran el cambio una ventaja competitiva para sus clientes.
- 8. Entregamos software funcionando frecuentemente, desde unas pocas semanas a unos pocos meses, con preferencia por la escala mas corta.
- 9. Las personas de negocio y los desarrolladores trabajan juntos diariamente durante el proyecto.
- 10. Construimos los proyectos alrededor de personas motivadas. Les proveemos del entorno y el soporte que necesitan, y confiamos en que harán el trabajo.
- 11. El método mas eficiente y efectivo de compartir información con y dentro del equipo de desarrollo es la conversación cara a cara.
- 12. El software funcionando es la principal medida de progreso.
- 13. Promovemos el desarrollo sostenible. Sponsors, desarrolladores y usuarios deben ser capaces de mantener un ritmo sostenible indefinidamente.
- 14. La atención continua a la excelencia tecnica y el buen diseño mejora la agilidad del proceso.
- 15. Simplicidad – el arte de maximizar el trabajo no realizado – es esencial.
- 16. Las mejores arquitecturas, requerimientos y diseños emergen de equipos auto- organizados.
- 17. A intervalos regulares, el equipo reflexiona sobre como ser mas efectivo, optimizando y ajustando el entorno de acuerdo a ello.
- 18. Dos procesos
- 20. Proceso predictivo VALOR TIEMPO
- 21. Proceso predictivo VALOR TIEMPO
- 22. Proceso predictivo pero el ROI va menguando a medida que avanzamos VALOR Alto ROI en las primeras etapas del proyecto TIEMPO
- 23. Proceso predictivo La ejecución se basa en planificaciones realizadas anteriormente. No existe proceso de aprendizaje. VALOR TIEMPO
- 24. Proceso Empírico “El acto de realizar acciones basandose en la situación real actual, no en una planificación anterior”
- 25. Proceso Empírico VALOR Ciclos cortos de planificación y ejecución basados en la situación actual del proyecto TIEMPO
- 26. Proceso Empírico VALOR El ROI es maximizado mediate planificaciones a corto plazo. TIEMPO
- 27. Proceso Empírico y el ROI final al proyecto es ampliamente mayor al anterior VALOR TIEMPO
- 28. Resultado: software funcionando VALOR El equipo produce software funcionando periodicamente… TIEMPO
- 29. Resultado: software funcionando VALOR Este software funcionando puede ser liberado a los clientes/usuarios. Se obtiene valor de los clientes y aprendizaje útil para el equipo TIEMPO
- 30. 2 procesos Proceso predictivo Proceso empírico
- 31. Siempre?
- 32. No, no siempre Desarrollo Tradicional Agile Sabemos lo que hay que hacer Descubrimos lo que hay que Sabemos como hacerlo hacer Descubrimos como hacerlo
- 33. No, no siempre
- 34. Modelos, Frame works y Metodologias
- 36. SCRUM Priorización Planificación Ejecución Valor
- 37. KANBAN
- 38. SCRUMBAN
- 39. DSDM Atern
- 41. Gracias!! (otra vez, nunca esta de mas)
- 42. Happiness door
- 43. http://agile-barcelona.org @agilebcn https://groups.google.com/group/agile- spain-barcelona
- 44. Agile SCRUM I @agilebcn #agilebcn
- 45. Gracias!!
- 46. Scrum?
- 47. Scrum: Fundamentos 1.Gestión Empírica 2.Ciclo de vida iterativo e incremental 3.Transparencia 4.Inspección y adaptación
- 48. Scrum: Objetivos 1.Flexibilidad a cambios 2.Gestionar la incertidumbre 3.Complejidad 4.Maximizar el ROI 5.Anticipar TTM 6.Comunicación y cooperación 7.Maximizar calidad y productividad
- 49. Scrum: Roles Equipo “ Desarrolla el producto previsto por el propietario del producto. “ ScrumMaster Product Owner “Provee de todo lo necesario para que el Equipo tenga éxito, como la eliminación de “Toma las entradas de lo que el los obstáculos de organización, la facilitación producto debe ser y los traduce en una de reuniones, actuando como un guardián visión de producto con la que el equipo para que nadie interrumpa innecesariamente pueda trabajar “ el trabajo del equipo. “
- 50. Scrum: Product Owner “Toma las entradas de lo que el producto debe ser y los traduce en una visión de producto con la que el equipo pueda trabajar “
- 51. Scrum: Equipo “ Desarrolla el producto previsto por el propietario del producto. “
- 52. Scrum: ScrumMaster “Provee de todo lo necesario para que el Equipo tenga éxito, como la eliminación de los obstáculos de organización, la facilitación de reuniones, actuando como un guardián para que nadie interrumpa innecesariamente el trabajo del equipo. “
- 53. Scrum: Ciclo de Vida
- 54. Planificación
- 55. Product Backlog Historias de usuario Visión global Incompleta Diferente nivel de detalle Priorizado Cambia a lo largo del proyecto
- 56. Historias de Usuario Descripción de funcionalidad desde el punto del usuario y que expresa el valor que le aporta El usuario recibir una notificación cada vez que un “amigo” se conecta al sistema El usuario puede buscar canciones por nombre o artista
- 57. Las 3 C’s (al menos en inglés) TARJETA (CARD): Tarjeta física con la descripción de la funcionalidad CONVERSACIÓN: Sobre los detalles de la implementación para asegurar el entendimiento CONFIRMACIÓN: Tests de aceptación que permiten fijar el alcance y verificar si la historia cumple o no los requisitos
- 58. Historias de Usuario “ Una historia de usuario es una invitación a conversar “
- 59. Historias de Usuario: Forma Como <rol> quiero <funcionalidad> para <beneficio> Como <usuario registrado> quiero <recibir una notificación cada vez que un “amigo” se conecta al sistema> para <poder hablar con el en ese momento>
- 60. Historias de Usuario: INVEST I – Independent N – Negotiable V – Valuable E – Estimable S – Small T – Testable
- 61. Historias de Usuario: Beneficios Entendimiento compartido de la solución Enfatizan la comunicación verbal Aplazar los detalles Desarrollo emergente Buen tamaño para planificar Favorecen el desarrollo iterativo
- 62. A currar!
- 63. Visión “Queremos disponer de una aplicación de climatología para dispositivos móviles, que obtenga la información de un proveedor externo de meteorología y la muestre al usuario, incluyendo temperatura así como datos sobre lluvia o nieve”
- 64. Priorización Technology risk Business value based MoSCoW
- 65. Gracias!! (otra vez, nunca esta de mas)
- 66. Retrospectiva
- 67. http://agile-barcelona.org @agilebcn https://groups.google.com/group/agile- spain-barcelona
- 68. Agile SCRUM II @agilebcn #agilebcn
- 69. Gracias!!
- 70. Estimación
- 71. Estimación ágil “El propósito inicial de la estimación no es predecir cuando un proyecto va a estar listo;es determinar si los objetivos de un proyecto son lo suficientemente realistas como para poder alcanzarlos” Steve McConnell, Software Estimation: Demystifying the Black Art
- 72. Estimación ágil
- 73. Estimación ágil
- 74. Estimación ágil
- 75. Puntos de Historia Puntos de Historia 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 Representa niveles de magnitud Nos ayuda a expresar incertidumbre Facil y rápido La estimación no decae con el tiempo
- 76. Planning Poker
- 78. Velocidad ¿Cuantos puntos somos capaces de entregar por iteración? =100 PH 3 Sprints!
- 79. Liturgias
- 80. Daily Meeting ¿Qué hiciste ayer? ¿Qué piensas hacer hoy? ¿Qué problemas has encontrado?
- 81. Sprint Demo
- 82. Retrospectiva
- 84. Burndown
- 85. Gracias!! (otra vez, nunca esta de mas)
- 86. Retrospectiva Escoger 5 dimensiones que puedan ser valoradas sobre la formación
- 87. Retrospectiva
- 88. http://agile-barcelona.org @agilebcn https://groups.google.com/group/agile- spain-barcelona
- 89. Agile LEAN, KANBAN, SCRUMBAN @agilebcn #agilebcn
- 90. Gracias!!
- 91. Lean Thinking: Principios 1. Eliminar el desperdicio Brindar un liderazgo técnico y de mercado Crear solamente cosas de valor 2. Crear conocimiento Crear equipos multidisciplinares Mantener una cultura de mejora continua 3. Embeber a la calidad Sincronizar Automatizar 4. Postergar el compromiso Romper con las dependencias Mantener opciones 5. Optimizar el total Enfocarse en el flujo completo de valor Entregar un producto completo 6. Entregar rápido Trabajar en bloques pequeños Limitar el trabajo a la capacidad 7. Respetar a las personas Capacitar a los líderes de equipo Mover la responsabilidad y la toma de decisiones al nivel más bajo posible Fomentar orgullo por el trabajo
- 92. Lean Thinking: Practicas y Herramientas • Value / Value Stream Mapping • Kanban / flow / pull • Kaizen / Kaikaku / 7 wastes • Takt time / ritmo • 5 whys / Gemba / Genchi • Level load (heijunka) gembutsu • Build quality in / stop the line • Teamwork / multi-skill / leaders as coaches • Standard work • Visual Management / andon • 5 S’s (sort, stabilize, shine, standardize, sustain) • Flow / small batches / one piece flow / supermarket • A3 thinking, PDCA
- 93. Lean Thinking: 7 wastes 7 waste de l Sistema de Producción 7 waste de l Desarrollo de Software Toyota (Shigeo Shingo) (Mary Poppendieck) Inventario Trabajo parcialmente realizado Extra Procesamiento Procesos Innecesarios Sobreproducción Funcionalidades innecesarias Transporte Cambios Frecuentes de actividad Espera Espera Movimiento Movimiento Defectos Defectos
- 94. Lean Thinking: El 8 Waste Talento!!
- 95. Lean Thinking: Flow / Pull
- 96. Kanban
- 97. Kanban “Kanban is an approach to change management. It isn’t a software development or project management lifecycle or process” David Anderson
- 98. Kanban: 3 Principios Empieza donde estas Kanban no preescribe un conjunto de reglas o roles especificos, ni procesos a seguir. Cambio evolutivo, incremental Cambios pequeños y graduales, mejora continua (Kaizen) Respeto por el proceso actual, roles, responsabilidades Reduce el miedo / resistencia al cambio y experimenta los beneficios como equipo
- 99. Kanban: 5 Propiedades Visualiza el flujo de trabajo Kanban significa literalmente “tablero”. Limita el trabajo en curso (WIP) Utiliza un sistema “pull” – establece y respeta tu capacidad ideal Gestiona el flujo Monitoriza, mide e haz visible el flujo de trabajo en cada estado Haz las reglas explicitas ¿Qué significa terminado?, limites de WIP, estandar de código, bloqueos, etc... Mejora el flujo colaborativamente Involucra a todo el mundo
- 100. Kanban
- 101. Kanban: ¿Por qué? A veces el time-boxing no funciona Integración sencilla con otros procesos Restricciones de la organización Mínima resistencia al cambio
- 102. Kanban: El tablero mas básico
- 103. Kanban: Limites
- 104. Kanban: Backlog
- 105. Kanban: Tu ciclo de vida
- 106. Kanban: Transiciones
- 107. Kanban: Dia 0
- 108. Kanban: El Backlog
- 109. Kanban: Dia N
- 111. Kanban: Bloqueos
- 112. Kanban: Bloqueos
- 116. Kanban: Despliegue
- 117. Kanban: Despliegue
- 118. Scrumban
- 119. ¿Kanban + Scrum o Scrum + Kanban?
- 120. Gracias!! (otra vez, nunca esta de mas)
- 121. Retrospectiva
- 122. Retrospectiva
- 123. http://agile-barcelona.org @agilebcn https://groups.google.com/group/agile- spain-barcelona
- 124. Agile OPEN SPACE @agilebcn #agilebcn
- 125. Gracias!!
- 126. ¿Qué es un Open Space?
- 127. Open Space: cuatro principios
- 128. Open Space : cuatro principios
- 129. Open Space : cuatro principios
- 130. Open Space : cuatro principios
- 131. Open Space : cuatro principios
- 132. Open Space : y una ley
- 133. Lean Thinking: Flow / Pull
- 134. Gracias!! (otra vez, nunca esta de mas)
- 135. Retrospectiva
- 136. http://agile-barcelona.org @agilebcn https://groups.google.com/group/agile- spain-barcelona
Notas del editor
- El curso de Introducción a Agile ha sido desarrollado colaborativamente por los que formamos la comunidad agile-barcelona. A lo largo de las siguientes presentaciones, incluimos en las observaciones notas que consideramos de interés para la comprensión de la diapositiva. Nota: Siempre que encuentres una nota como esta, se trata de un comentario que hemos añadido los profesores para explicar la motivación de explicar un determinado punto o para aportar información sobre la dinámica realizada en ese punto del curso.
- No, no nos hemos equivocado en el orden de la presentación ni se ha acabado esta. Queremos agradecer a todos los asistentes su interés en las metodologías agiles y sus ganas de aprender y compartir lo aprendido con el resto de asistentes con los mismos intereses. Sabemos el esfuerzo que representa sacrificar tiempo de descanso personal para dedicarlo a practicar y mejorar. Cada día hay mas gente dispuesta a realizar dicho esfuerzo y a compartirlo con el resto de miembros de la comunidad. Por eso, a todos los asistentes al curso de Introducción a Agile, a todos los que queríais asistir pero desgraciadamente no fue posible debido al aforo limitado y a todos los que en general compartís vuestra experiencia y conocimiento con otras personas con el único interés de enseñar y aprender: Gracias!
- Sabemos que seguramente para muchos de vosotros este no será el primer contacto con Agile, al menos no la primera vez que leéis sobre ello. Por eso, nos gustaría saber que dudas son las que os han traído aquí. Durante el curso, miraremos de ir resolviéndolas todas.Nota: durante 5 min, los alumnos disponen de tiempo para escribir sus dudas en post-its. Pasado el tiempo, se levantan uno a uno pegando su pregunta sobre un panel en blanco, diciéndola en voz alta para sus compañeros antes de engancharla. Muchas preguntas suelen ser parecidas, por lo que cuando detectamos alguna que ya ha aparecido las agrupamos juntas.
- Como no puede ser de otra forma, todo curso de introducción a Agile empieza con el manifiesto ágil. Escrito en febrero de 2001, el manifiesto refleja los valores y principios sobre los que nos basamos a la hora de construir software de forma ágil. Como se comenta al pie del manifiesto, que podéis encontrar y firmar en http://www.agilemanifesto.org/ “aunque hay valor en los elementos de la derecha, nosotros valoramos mas los elementos en la izquierda”.
- En la diapositiva anterior, hemos podido ver los valores reflejados en el manifiesto. Vamos ahora con los principios. Nota: En este momento, pedimos a los alumnos que se pusieran de pie. A la vez que enumerábamos los principios, si alguien creía que en su trabajo actual no se cumplía, le pedimos que se sentase. Con ello, pretendíamos conseguir que los alumnos reflexionaran sobre el principio en cuestión (imprescindible para determinar si lo estas aplicando) y a la vez provocar cierta “insatisfacción” al detectar puntos de mejora en tu contexto actual al llegar a un principio que no aplicas (con el objetivo de motivarte a buscar las razones por las que no se cumple y cambiarlo). Siempre que hemos realizado este ejercicio, rara vez a permanecido un alumno de pie al final de los principios.
- El desarrollo de software ágil se realiza de forma empírica, es decir, siguiendo un proceso basado en la situación actual del proyecto, no en planificaciones estimadas anteriormente. Durante las siguientes diapositivas, explicaremos la diferencia entre un proceso predictivo y un proceso empírico.
- Para explicar un proceso predictivo, utilizamos una alegoría con AngryBirds. ¿Es un disparo en AngryBirds un proceso predictivo o empírico? Debido a que se rige por reglas estáticas, un disparo de AngryBirds puede ser considerado predictivo. El mismo disparo, realizado con la misma fuerza, inclinación, etc… producirá los mismos resultados. Mediante una correcta planificación, seria capaz de determinar exactamente si voy a acertar en mi objetivo o no Nota: queremos agradecerle este ejemplo a Xavi Quesada, http://www.xqa.com.ar/, quien nos enseño esta alegoría. A diferencia que en AngryBirds, en la realización de proyectos de software no es fácil determinar nuestro disparo exactamente al inicio dado que, en la mayor parte de los casos, el cerdo se mueve!
- Examinemos ahora como liberamos valor dentro de un proyecto realizado de forma predictiva mediante su representación en una curva en relación con la dimensión de tiempo.
- La mayor parte del valor es entregado en fases tempranas, pero el retorno disminuye progresivamente en planificaciones a largo plazo. ¿Por qué se produce esto?
- Habitualmente, la depresión de la curva de valor viene dada porque la ejecución se realiza en función de la planificación original. En proyectos en que tenemos un contexto cambiante, cuanto mas alejada en el tiempo se haya la ejecución de una tarea con respecto a cuando se planifico, mayor es el gap entre el contexto actual en el que se tiene que ejecutar la tarea y el contexto previsto por la planificación. Es decir, las premisas en las que se basa la tarea a ejecutar (los requerimientos) y su encaje dentro de la solución global se hayan mas lejanos del punto inicial de consenso / certeza, aumentando la complejidad de la tarea, lo que repercute directamente en las dimensiones de tiempo y coste de su ejecución.
- En contraposición con los procesos predictivos, los empíricos no se basan en una planificación predeterminada anteriormente si no en el conocimiento que tenemos del contexto actual.
- Durante la ejecución del proyecto, no realizamos secuencialmente una planificación detallada y su posterior ejecución, si no que realizamos ciclos cortos de planificación + ejecución, basandonos en nuestro conocimiento de la situación actual del proyecto.
- No únicamente desarrollamos el producto mediante ciclos cortos, si no que al final de cada ciclo producimos “software funcionando”, que nos permite obtener feedback real de la situación actual del proyecto.
- ¿Es el uso de las metodologías agiles siempre el mas adecuado?
- La respuesta a la pregunta anterior dependerá del contexto en que nos encontremos. En entornos en que conocemos perfectamente las especificaciones/requisitos a realizar, y en el que el equipo sabe perfectamente como hacerlo, la ejecución de forma predictiva puede ser una opción. Como se ha comentado anteriormente, con el uso de metodologías agiles es obtener feedback continuamente que nos permita evaluar donde estamos y planificar y ejecutar de acuerdo a dicha situación. Las tareas a realizar cada ciclo son planificadas al inicio del mismo, basándose en el contexto actual del proyecto y el aprendizaje obtenido de las iteraciones anteriores, reduciendo al máximo el gap comprendido entre planificación y ejecución y los efectos del mismo comentados anteriormente.
- Cuanto mas tiempo pasa entre planificación y ejecución, nos alejamos del punto inicial de consenso/certeza, incrementando la complejidad. Pero en aquellos en que nos mantenemos cerca de él, dado que los requisitos no son cambiantes, y nuestro conocimiento de la tecnología al inicio del proyecto es suficiente para su ejecución, es decir, en aquellos proyectos no-complejos, el uso de metodologías predictivas puede ser adecuado.
- Nota:durante las siguientesdiapositivas, explicamosbrevemente (en no mas de 2’) los frameworks mas conocidos para el desarrollo de proyectos de forma ágil. No incluimosinformación sobre ellos aquí, ya que se profundizandurante el curso, excepto en el caso de eXtremeProgramming y DSDM Atern, en los que la duración del curso no nos permite entrar.
- Nota:como final de la primera sesión, realizamos un agile game, en concreto el Ball Point game, con el objetivo de que los alumnos experimentasen la realización de una misma actividad de forma iterativa, introduciendo feedback (retrospectivas) entre ellos, y como ello ayuda a mejorar el proceso. Se puede encontrar información sobre el Ball Point Game en el blog de Boris Gloger, creador del juego: http://borisgloger.com/2008/03/15/the-scrum-ball-point-game/
- Agradecer una vez mas (nunca será bastante) a todos los que vinieron a la sesión, a los que quisieron venir pero finalmente no pudo ser, a todos los que han contribuido dando feedback sobre el curso y aportando geniales sugerencias de mejora, y a ti, que estas leyendo este documento.
- Nota:Como parte del curso, nos propusimos acabar la clase obteniendo feedback de los alumnos cada día de una forma distinta. En este primer día, la opción escogida fue la HapinessDoor, en la que simplemente enganchan un post-it en la puerta indicando el nivel de satisfacción de 1 a 5, donde 5 es el mayor nivel de satisfacción. La diapositiva original incluía una hapinessdoor de ejemplo, pero para publicar este documento la hemos modificado usando el feedback real de los alumnos tras el primer día. No se puede expresar nuestra sensación al ver esta hapinessdoor, en la que incluso algunos decidieron salirse de la escala Lo único que podemos reiterar es: Gracias, Gracias, Gracias!!
- Ya por último, animaros a todos a seguir contribuyendo y compartiendo en la comunidad agile-barcelona, a través de cualquiera de sus canales: http://agile-barcelona.org : el blog de la comunidadhttp://twitter.com/@agilebcn : la cuenta de twitterhttps://groups.google.com/group/agile-spain-barcelona: el corazón de agile-barcelona, la lista en la que se realizan las discusiones, se proponen ideas, actividades, se organizan y en general, se comparte entre todos los miembros el deseo de seguir impulsando el uso de metodologías agiles.
- El curso de Introducción a Agile ha sido desarrollado colaborativamente por los que formamos la comunidad agile-barcelona. Durante las sesiones 2 y 3, abordamos el uso de Scrum para el desarrollo de proyectos de software.
- No, no nos hemos equivocado en el orden de la presentación ni se ha acabado esta. Queremos daros las gracias por volver!
- Scrum se enmarcado dentro de las metodologías ágiles y es la más conocida y utilizada. Tiene sus inicios en un trabajo del año 1986 (es anterior a que se populalizase el termino “Agile” en 2001), aunque no es hasta principio de los años 90 cuando Ken Schwaber o Jeff Sutherland empienzan a llamarle Scrum y trabajan en su consolidación.Scrum es un marco de trabajo para la definición de procesos que se caracteriza por ser ligero y fácil de entender. Scrum no define un proceso concreto sino que proporciona las herramientas para que cada equipo personalice el marco de trabajo y encuentre el proceso más adecuado a sus circunstancias.Esta característica hace que Scrum sea adecuado para situaciones complejas (donde es difícil predecir qué pasará en el futuro) y donde, por tanto, será necesaria una gran capacidad de adaptación.Fundamentos de Scrum1.Gestión empíricaScrum es un método empírico y, por tanto, se basa en gestionar el proceso de desarrollo a través de la experiencia (observación) y no en base a predicciones. La principal consecuencia de ello es que las decisiones se toman en base a hechos conocidos y no en base a hecho hipotéticos.2.Ciclo de vida iterativo e incrementalPara poder adaptar el proceso a la realidad, Scrum utiliza el ciclo de vida iterativo e incremental. Es decir, organizamos el proyecto en iteraciones cortas (entre 2 y 4 semanas preferentemente) para tener un ritmo estable para la revisión del proceso y la identificación de oportunidades de mejora.Por otra parte, el producto se construye de manera incremental consiguiendo así, un doble objetivo: En todo momento tenemos implementadas las funcionalidades más importantes del proyecto y, al mismo tiempo, las distintas iteraciones son comparables entre sí.3. TransparenciaTodos los aspectos del proceso deben ser visibles a los responsables de su resultado. La transparencia requiere de la definición de un criterio común a todos los observadores para que todos interpreten lo que ven de la misma manera.4. Inspección y adaptaciónSe da mucha importancia a la inspección frecuente del proceso y de sus resultados así como la adaptación del proceso cuando los resultados se desvían de lo que era de esperar de manera que el resultado obtenido no sea aceptable.En concreto, Scrum nos propone cuatro ocasiones para inspeccionar el proceso y hacer propuestas de adaptación:• Cuando se planifica la iteración (cada 2 o 4 semanas)• En la reunión diaria (donde se plantean los problemas que se van encontrando)• Cuando se revisa y se muestra el trabajo realizado al final de cada iteración• En la retrospectiva que se hace al final de cada iteración (de hecho, la finalidad de la retrospectiva es, precisamente, reflexionar sobre cómo ha ido la iteración y hacer propuestas de mejora)
- Scrum pretende dar respuesta o aportar una serie de aspectos respecto a las metodologías tradicionales:Flexibilidad a cambios: cambios en los requisitos, en el contexto, en la situación del mercado, …Gestionar la incertidumbre: Las metodologías predictivas intentan eliminar riesgo asumiendo que pueden predecir el desarrollo total del proyecto antes de empezar el proyecto. Las metodología empiricas como Scrum utilizan una aproximación diferente, asumiendo la existencia de incertidumbre y proveyendo de diferentes mecanismos para reducirla durante la ejecución del proyectoComplejidad: Enlazado con el punto anterior, en entornos complejos el conocimiento sobre como ejecutar el proyecto se adquiere durante la propia ejecución del mismoMaximizar ROI: Scrum intenta maximizar el ROI, utilizando para ello la priorización de las funcionalidades por el valor de negocioAnticipar Time ToMarket: En un contexto de cambio, minimizar el TTM entendido como el tiempo transcurrido entre que un producto es concebido y puede ser empleado es esencial, por lo que Scrum utiliza entregas frecuentes de productoComunicación y cooperación: Scrum refuerza el trabajo en equipo y la colaboración con el cliente como herramientas indispensables en la ejecución de proyectos.Maximizar la calidad y productividad: Mediante ciclos de feedback cortos y continuos, Scrum busca la mejora continua.
- En Scrum existen tres roles principales: El ProductOwner, propietario del productoEl EquipoEl ScrumMaster
- ProductOwnerEl propietario del producto es responsable de maximizar el retorno sobre la inversión (ROI) mediante la identificación de las características del producto, la traducción de estos en una lista de características de prioridades, decidir qué debe estar en la parte superior de la lista para el siguiente Sprint, y continuamente re-priorizar y refinar la lista.El propietario del producto tiene la responsabilidad de pérdidas y ganancias para el producto, suponiendo que es un producto comercial. En el caso de una aplicación interna, el propietario del producto no es responsable de retorno de la inversión en el sentido de un producto comercial (que generará ingresos), pero siguen siendo responsable de maximizar el retorno de la inversión en el sentido de elegir - cada Sprint - los elementos de mayor valor de negocio y de más bajo coste.El propietario del producto no es un gerente de producto- Representa a todos los stakeholders implicados en el proyecto- Es dueño de la visión:Conoce los objetivos del proyecto y tiene que guiarlo hacia la visión- Define funcionalidades: Crea y actualiza la lista de funcionalidades del proyecto/producto- Prioriza las funcionalidades en función del valor aportado y de su coste intentando maximizar el ROI- Colabora con el equipo ayudándoles a entender todos los detalles de las funcionalidades a implementar, respondiendo sus dudas y planificando con ellos las funcionalidades a entregar en cada iteración. Además está disponible para resolver dudas o preguntas durante la iteración - Acepta o rechaza la entrega de funcionalidades al final del Sprint revisando que se cumplan las condiciones de aceptación de las mismas
- El EquipoEl equipo construye el producto de lo que el cliente va a hacer uso. El equipo en Scrum es multi-funcional e incluye todos los conocimientos necesarios para entregar el producto potencialmente entregable cada Sprint. También es auto-organizado (el equipo se autogestiona), con un alto grado de autonomía.Por lo tanto, no hay jefe de equipo o jefe de proyecto en Scrum. En cambio, los miembros del equipo deciden a que se comprometen a, y cual es la mejor manera de cumplir con este compromiso. El equipo es - Multifuncional: es capaz de hacer todas las tareas necesarias para llevar a cabo el proyecto. No significa que todo el mundo hace de todo. Hay especialistas, aunque cuando sea necesario para el proyecto la mayoría de personas del equipo son capaces derealizar tareas que no son de su especialidad. -Autoorganizado: no hay nadie que asigna tareas. Las tareas se las van asignando los componentes del equipo a medida que es necesario hacerlas. - Define tareas: desglosa las funcionalidades seleccionadas para el Sprint en tareas más pequeñas (de implementación)- Estima esfuerzo: calcula el coste de realizar cada funcionalidad (y es posible que las tareas)- Desarrolla el producto
- El ScrumMasterEl ScrumMaster ayuda al grupo del producto a aprender y aplicar Scrum para conseguir valor de negocio, está en su poder ayudar al equipo a tener éxito.El Scrum Master no es el manager del equipo o un director de proyecto, sino que sirve al equipo, lo protege de la interferencia externa, y educa y orienta al propietario del producto y el equipo en el uso de Scrum . El ScrumMaster asegura que todos en el equipo (incluyendo el propietario del producto, y los de gestores) entiendan y sigan las prácticas de Scrum. También ayudan a dirigir la organización a través del cambio, una actividad a menudo difícil pero necesaria para conseguir el éxito con el desarrollo ágil.- Cuida del proceso: se asegura que el equipo entienda y siga las reglas de Scrum, ayuda a la colaboración entre el equipo y el cliente, facilita la reuniones, escucha y ayuda al equipo- Elimina impedimentos: obstáculos que el equipo tiene en su dia a dia y que le impiden hacer su trabajo de la forma mas efectiva- Protege de interferencias: durante la iteración, por ejemplo evitar que se introduzcan nuevos requisitos o la utilización de un miembro del equipo para otros proyectos, etc… (esto podría hacer que el equipo no pudiera cumplir con su compromiso para la iteración)
- Elementos de Scrum1. El productbacklogUn proyecto de Scrum es impulsado por una visión de producto elaborada por el propietario del producto, y se expresa en la Pila de Producto. El Productbacklog es una lista priorizada de lo que se requiere, por orden de valor para el cliente o negocio, con los elementos de mayor valor en la parte superior de la lista. El Productbacklog evoluciona durante la vida útil del proyecto, y los elementos se añaden, quitan o son re priorizados continuamente.2. El SprintScrum estructura el desarrollo de productos en ciclos de trabajo llamado sprints, repeticiones de trabajo que son típicamente 1 a 4 semanas de duración. Los sprints son de duración determinada nunca se extienden más allá de la fecha fijada al principio, independientemente de si el trabajo planificada para el sprint se ha completado o no.3. Planificación del SprintAl comienzo de cada Sprint, se lleva a cabo la Reunión de Planificación del Sprint. El propietario del producto y el Equipo Scrum (con la facilitación del Scrum Master) revisan la Pila de Producto, discuten los objetivos y el contexto de las historias de usuario, y el Equipo Scrum selecciona los elementos de la Pila de Producto que se comprometen a realizar para el final del Sprint, partiendo de la parte superior de la Pila de Producto, donde se encuentran los elementos de priorización más alta.Cada elemento seleccionado en la Pila de Producto se descompone después en una serie de tareas individuales. La lista de tareas se registra en un documento llamado el Sprint backlog.4. Reunión diaria de ScrumUna vez que el Sprint ha comenzado, el Equipo Scrum se dedica a otra de las principales prácticas de Scrum: La reunión diaria de Scrum o Daily Stand-Up en su nombre original al inglés. Esta es una breve encuentro (máximo 15 minutos) que pasa cada día de trabajo a una hora determinada. Todos los miembros del equipo asisten. En esta reunión, se presenta la información necesaria para inspeccionar el avance desde el día anterior. Esta información puede resultar en la re planificación y en debates sobre la funcionalidad después del Daily Stand-Up.5. Revisión del Sprint y RetrospectivaUna vez finalizado el Sprint, se produce la reunión de revisión del Sprint, donde el Equipo Scrum y las partes interesadas inspeccionan el que se hizo durante el Sprint y lo discuten. En esta reunión están presentes el propietario del producto, los miembros del equipo, y el ScrumMaster, además de los clientes, gente de negocio, expertos, ejecutivos, y cualquier otra persona interesada.Tras la revisión del Sprint, el equipo se reúne para la retrospectiva de Sprint, que es una oportunidad para que el equipo discuta lo que ha funcionado bien durante el Sprint y lo que no funciona, poniendo de acuerdo en los cambios a intentar durante el siguiente Sprint a fin de lograr ser más productivos
- El productbacklogEl ProductBacklog se compone de una lista de historias de usuario que:- Proporciona una visión global del producto a construir: todas las funcionalidades del producto se encuentran reflejadas dentro del productbacklog- Incompleta: el productbacklog marca el camino para materializar la visión que tenemos actualmente del producto a construir. Pero el productbacklog no es una planificación fijada al inicio que debe seguirse a través de las distintas iteraciones. Esta vivo a lo largo del proyecto, pudiendo ser modificado, añadidas nuevas historias de usuario, eliminadas otras, etc…- Diferente nivel de detalle: aquellas historias de usuario situadas en la parte superior del productbacklog tienen un mayor nivel de detalle, ya que serán las que se ejecutaran en las próximas iteraciones. Sin embargo, a medida que vamos bajando a lo largo del PB, las historias de usuario tienen menor nivel de detalle. Esto viene dado el carácter cambiante del PB: puede que las historias de usuario situadas en la parte inferior no lleguen a ser implementadas nunca, por lo que no dedicamos esfuerzo a definirlas en detalle.- Priorizado: el productbacklog se encuentra priorizado, es decir, en la parte superior se encuentran las historias de usuario de mayor valor y en la parte inferior las de menor valor.- Cambia a lo largo del proyecto: tal como hemos comentado anteriormente, el PB esta vivo a lo largo del proyecto, pudiendo ser modificado, añadidas nuevas historias de usuario, eliminadas otras, etc…
- Las historias de usuario describen la funcionalidad desde el punto de vista del usuario y suelen expresar deseos o peticiones de funcionalidades. Deben contener como mínimo: - Ladescripción: sirve cómo recordatorio de cual es el objetivo de la historia- Lascondiciones aceptación: Tests o documentación que nos sirven para validar que la historia se ha implementado correctamente
- Habitualmente, se describen los elementos que conforman una historia de usuario como “Las 3 Cs” de sus términos en inglésCardConversationConfirmation
- Las historias de usuario describen la funcionalidad desde el punto de vista del usuario y suelen expresar deseos o peticiones de funcionalidades. Deben contener como mínimo: - Ladescripción: sirve cómo recordatorio de cual es el objetivo de la historia- Lascondiciones aceptación: Tests o documentación que nos sirven para validar que la historia se ha implementado correctamente
- La forma tradicional de escribir una historia de usuario busca incluir en ella mediante una frase simple:- El rol del usuario que usará la funcionalidad- La funcionalidad- El beneficio (valor que aporta) de la funcionalidadSirve para ver que la funcionalidad que estamos intentando definir tiene un valor real para el usuario y le aporta algo. Durante la redacción de una historia de usuario, es posible que nos demos cuenta de que hay funcionalidades que no aportan valor
- Elacronimo INVEST fue acuñado por Bill Wake como recordatorio de las caracteristicas que debe cumplir una buena historia de usuario.Independent: una de las características de Scrum es la capacidad de mover las historias de acuerdo a su prioridad relativa sin demasiado esfuerzo. Si tienes varias historias que son dependientes entre ellas, una buena idea seria unirlas entre ellas.Negotiable: la única cosa inamovible en Scrum es el Sprint Backlog. Mientras las historias se encuentran en el productbacklog, deben poder ser rescritas o eliminadas dependiendo de los requisitos de negocio, técnicos o de cualquier otro tipo por los miembros del equipo.Valuable: el foco de la historia de usuario es dar valor para el usuario. Estimable: Si una historia de usuario no puede ser estimada, no puede ser planificada, dividida en tareas e incluida en un sprint.Sizeappropiatelyor Small: Siempre intentares mantener nuestras historias de usuario lo mas pequeñas posibles, de forma que puedan ser adecuadamente estimadas. Un historia de usuario demasiado grande es denominada una “épica” y debe ser fraccionada en múltiples historias.Testeable: para poder asegurar que una historia de usuario esta DONE, debe ser posible establecer que criterios de aceptación nos permiten determinarlo.
- Nota: En este punto, pedimos a los alumnos que realicen la construcción de un backlog partiendo de una descripción de requisitos muy sencilla, expuesta en la diapositiva posterior. Formando equipos de 5 personas, los alumnos realizan sus backlogs durante 15’. Durante la realización de la practica, enfatizamos en que lo que debemos construir es un Backlog, es decir, una lista priorizada que refleje la visión completa del producto, etc… dado que es habitual que se centren en determinar las características que deberá tener el producto pero se olviden de priorizarlas.
- Una vez tenemos un ProductBacklog priorizado, en el que las historias de usuario se encuentran bien detalladas, comentamos distintas técnicas de priorización para establecer el valor de las diferentes historias de usuario en base a un contexto. - MoSCoW: las historias de usuario se agrupan entre aquellas que son un * Must: imprescindibles para el producto* Should: deberían estar incluidas dado que aportan alto valor pese a no ser imprescindibles* Could: pueden estar incluidas dentro del producto* Won’t: en este momento no las queremos incluirHabitualmente, la técnica MoSCoW se emplea para definir el objetivo de cada Release, de forma que ayuda al equipo a clarificar que es lo de mas valor, como por ejemplo en metodologías como DSDM Attern en las que el producto se realiza por iteraciones previamente planificadas. De esta forma, una funcionalidad que para la Release 1 era un Could, podría ser un Must en Release 3.- Business ValueBased: las historias de usuario se priorizan por su valor de retorno económico, es decir, cuanto dinero nos genera incluir una determinada funcionalidad en el producto. Un ejemplo donde puede ser usada podría ser una startup de reciente constitución con capital limitado que necesita empezar a monetizar rápidamente su producto para continuar evolucionándolo.- TechnologyRiskBased: se priorizan aquellas historias de usuario que tienen una incertidumbre técnologica mayor. Si nuestro producto es realizar la primera Tablet con pantalla flexible para que pueda ser doblada y guardada en el bolsillo, realizaremos primero las historias de usuario que nos permitan determinar que es tecnológicamente viable para no encontrarnos en un punto mas adelantado del desarrollo con la imposibilidad de continuar.- WalkingSkeleton: se pretende en la siguiente iteración construir un producto que no contenga todas aquellas historias de usuario de mayor valor que puedan ser realizadas, si no que aporte una visión minima del producto albergando todas las distintas áreas funcionales del mismo. Para ello, se dividen las historias de usuario en columnas por funcionalidad, y se realiza un corte horizontal, de forma que se incluye al menos una historia de usuario por cada área funcional. - Modelo de Kano: el modelo de kano nos ayuda a establecer las historias de usuario entre aquellas que son básicas para nuestro producto, aquellas que son habituales en los productos de la misma categoría y aquellas que provocan excitación en el usuario, aportando valor extra y diferenciándonos de otros productos.- ValidatedLearning: proviene del ciclo de Lean Startup, en el que buscamos aprender y obtener feedback sobre nuestro producto para tomar las decisiones posteriores, por lo que priorizaremos aquellas historias de usuario que nos permitan un mayor aprendizaje pese a que aporten menor valor al producto final.
- Agradecer una vez mas (nunca será bastante) a todos los que vinieron a la sesión, a los que quisieron venir pero finalmente no pudo ser, a todos los que han contribuido dando feedback sobre la dinámica y aportando geniales sugerencias de mejora, y a ti, que estas leyendo este documento.
- Siguiendo con la dinámica de realizar una retrospectiva de la sesión diferente cada día, en esta ocasión invitamos a los alumnos a realizar una de las mas sencillas, indicando simplemente pluses y deltas, que ha ido bien durante la sesión y que creen que se podría mejorar.Nota: en esta ocasión no podemos mostrar el resultado de la retrospectiva, dado que no conservamos imagen de la misma
- Y ya por último, animaros a todos a seguir contribuyendo y compartiendo en la comunidad agile-barcelona, a través de cualquiera de sus canales: http://agile-barcelona.org : el blog de la comunidadhttp://twitter.com/@agilebcn : la cuenta de twitterhttps://groups.google.com/group/agile-spain-barcelona: el corazón de agile-barcelona, la lista en la que se realizan las discusiones, se proponen ideas, actividades, se organizan y en general, se comparte entre todos los miembros el deseo de seguir impulsando el uso de metodologías agiles.
- El curso de Introducción a Agile ha sido desarrollado colaborativamente por los que formamos la comunidad agile-barcelona. Durante las sesiones 2 y 3, abordamos el uso de Scrum para el desarrollo de proyectos de software.
- No, no nos hemos equivocado en el orden de la presentación ni se ha acabado esta. Queremos daros las gracias por volver!
- Durante las siguientesdiapositivas, explicaremos como realizar las estimaciones de un proyecto de software realizado de forma ágil.
- El cono de incertidumbre es la herramienta que utilizamos, consciente o inconscientemente, para realizar una estimación de costes y tiempo de ejecución de un proyecto. En función del nivel de definición de las fases del proyecto, tendremos una repercusión en la estimación de costes y del plazo de ejecución. De este modo podemos tener unos costes estimativos desde 0,25x hasta 4x, siendo “x” el coste real final. Este es el motivo por el que en agile planificamos siempre lo mas tarde posible, dado que cuanto mas cerca estamos de realizar la ejecución de lo planificado, menor es la incertidumbre y por lo tanto la posibilidad de que las estimaciones no sean correctas.
- Nota:Como ejemplo ilustrativo, solicitamos a los alumnos que nos estimasen por equipos cuanto tardarían en consumir 1000 fresas. Una vez estimado, les pedimos que lo volviesen a hacer para 10.000, momento en que todos estuvieron de acuerdo en que no se podía simplemente escalar linealmente multiplicando por 10 la estimación inicial.
- Nota: una vez consensuaron la estimación sobre el consumo de fresas, les propusimos varias frutas de distinto tamaño, pidiéndoles que nos las estimasen de forma relativa de acuerdo a las fresas. Suponiendo que para las fresas tardásemos x, sea lo que sea x, los alumnos estimaron cuanto les costaba ingerir una naranja, una piña, un melón, unas cerezas, etc… De hecho, tras la introducción de varias frutas, eliminamos las fresas que habían servido de punto inicial y añadimos mas frutas. El propósito del ejercicio era ilustrar la estimación relativa que realizamos habitualmente en los proyectos agile, que sigue siendo valida incluso cuando eliminas el punto inicial del que partiste para estimar.
- Nota: Basandonos en la estimación relativa explicada anteriormente, asignamos puntos a los diferentes niveles de magnitud a los productbacklogs construidos.
- Nota: A continuación, mostramos la tecnica de Planning Poker usadamuyhabitualmentepor los equipos de Scrum pararealizarlasestimaciones. Basada en el consenso, se sueleusarparaestimar el backlog (o nuevasfuncionalidadesqueentran en el backlog) y parateneruna idea general del tamaño de un proyecto.
- Nota: Con el fin de ilustrar que podemosemplearcualquiermedida que se preste a la estimación relativa, utilizamosigualmente las tallas de camiseta para estimar las historias de usuario.
- Nota:A continuación introducimos el concepto de Velocidad. A medida que el equipo realiza sprints, se obtiene la velocidad como medida de referencia de cuantos puntos de historia suelen entregarse por Sprints. Esto nos permite realizar estimaciones a largo, dado que pese a no conocer el detalle en concreto, podemos hacer predicciones como la indicada en la diapositiva: si tengo un backlog de 100 puntos de historia y la velocidad del equipo es de 40, puedo estimar que tardaré tres sprints en realizarlo.
- Durante el Sprint, el Equipo Scrum se dedica a otra de las principales prácticas de Scrum: La reunión diaria de Scrum o Daily Stand-Up en su nombre original al inglés. Esta es una breve encuentro (máximo 15 minutos) que pasa cada día de trabajo a una hora determinada. Todos los miembros del equipo asisten. En esta reunión, se presenta la información necesaria para inspeccionar el avance desde el día anterior. Esta información puede resultar en la re planificación y en debates sobre la funcionalidad después del Daily Stand-Up.
- Una vez finalizado el Sprint, se produce la reunión de revisión del Sprint, donde el Equipo Scrum y las partes interesadas inspeccionan el que se hizo durante el Sprint y lo discuten. Al contrario de la creencia tradicional, en que a menudo las entregas se convierten en una prueba a superar, las demos del sprint deben ser celebraciones, en que el equipo enseña su trabajo, como ha avanzado el desarrollo del producto en el último Sprint y es reconocido por ello. En esta reunión están presentes el propietario del producto, los miembros del equipo, y el ScrumMaster, además de los clientes, gente de negocio, expertos, ejecutivos, y cualquier otra persona interesada.
- Tras la revisión del Sprint, el equipo se reúne para la retrospectiva de Sprint, que es una oportunidad para que el equipo discuta lo que ha funcionado bien durante el Sprint y lo que no funciona, poniendo de acuerdo en los cambios a intentar durante el siguiente Sprint a fin de lograr ser más productivos.
- Todas las liturgias comentadas, tienen entre sus objetivos dar feedback sobre la situación actual, cada uno enfocado a diferentes aspectos: las reuniones diarias del equipo proveen feedback para el equipo sobre el estado actual de la ejecución del ciclo de desarrollo. La demo del final de ciclo provee feedback tanto al cliente, que ve el resultado del último ciclo, como para el equipo, que obtiene los comentarios / apreciaciones del cliente sobre el mismo. La retrospectiva, la liturgia en el que el equipo se reúne y evalua como ha ido el último ciclo, provee feedback sobre el proceso, etc.
- Un diagrama burndown o diagrama de quemado es una representación gráfica del trabajo por hacer en un proyecto en el tiempo. Usualmente el trabajo remanente (o backlog) se muestra en el eje vertical y el tiempo en el eje horizontal. Esto nos permite visualizar de una forma rápida, en cualquier momento, el estado real en que nos encontramos, de forma que si sufrimos desviaciones como la que se indica en la “Sorpresa 1”, nos permita realizar las medidas correctoras que se requieran para que no haya mas sorpresas al final del Sprint/Proyecto.
- Agradecer una vez mas (nunca será bastante) a todos los que vinieron a la sesión, a los que quisieron venir pero finalmente no pudo ser, a todos los que han contribuido dando feedback sobre la dinámica y aportando geniales sugerencias de mejora, y a ti, que estas leyendo este documento.
- Nota:En esta ocasión, pedimos a los alumnos que escogieran ellos mismos cinco dimensiones sobre la formación para evaluarlas, con el propósito de realizar un Radar sobre la misma.
- Nota: Las dimensiones escogidas y sus valoraciones fueronTiempo: 5Conocimientos Prácticos: 9Materiales: 9Interacción: 9Didáctica: 10Una vez mas, que decir, Gracias, Gracias, Gracias!!
- Y ya por último, animaros a todos a seguir contribuyendo y compartiendo en la comunidad agile-barcelona, a través de cualquiera de sus canales: http://agile-barcelona.org : el blog de la comunidadhttp://twitter.com/@agilebcn : la cuenta de twitterhttps://groups.google.com/group/agile-spain-barcelona: el corazón de agile-barcelona, la lista en la que se realizan las discusiones, se proponen ideas, actividades, se organizan y en general, se comparte entre todos los miembros el deseo de seguir impulsando el uso de metodologías agiles.
- El curso de Introducción a Agile ha sido desarrollado colaborativamente por los que formamos la comunidad agile-barcelona. Durante la cuarta sesión, realizamos una introducción a los conceptos Lean, Kanban y Scrumban.
- No, no nos hemos equivocado en el orden de la presentación ni se ha acabado esta. Queremos daros las gracias por volver!
- Nota: Sin entrar en excesivo detalle, comentamos durante el curso las prácticas y herramientas lean, haciendo especial incapie en la cadena de valor, la diferencia entre kaizen y kaikaku, el visual management, kanban / flow / pull y stop the line.
- Nota:comparación entre los siete wastes identificados por ShigeoShingo en contraposición con los indicados por Mary Poppendieck en su libro “Lean Software Development”
- Nota: En los últimos años, se ha considerado que la perdida de talento o su no correcto aprovechamiento es otro desperdicio que debemos evitar.
- Nota: Con el fin de ilustrar los conceptos de flujo y pull, realizamos un agile-game con los alumnos del curso. Se crearon dos filas de alumnos, de forma A -> B -> C -> D -> EA’-> B’-> C’-> D’-> E’Ambos grupos tenían la tarea de realizar un avión de papel de la misma forma. Los alumnos en los puestos A/A’, B/B’, C/C’ hacían las tareas iniciales para la construcción del avión, todas ellas basadas en un único movimiento (doblar el papel por la mitad, cortarlo, volver a doblarlo). Los alumnos en la posición D/D’ debían realizar varias tareas, doblando varias veces el papel a fin de conseguir las alas y alerones, lo que les convertía en cuellos de botella. Finalmente, E/E’ simplemente tenían la misión de lanzar el avión. Ambos grupos trabajan de forma secuencial, con la diferencia que el primer grupo trabaja en modo PUSH, es decir, los integrantes A, B y C deben realizar tantas veces como sea posible su tarea e ir empujando hacia adelante el resultado, y el grupo prima trabaja en modo PULL, es decir, A’ no realiza su tarea hasta que B’ se ha quedado sin trabajo y se lo solicita, B’ no realiza su tarea hasta que C’ se lo pide, etc… Tras 2’ realizando la tarea, ambos grupos habían realizado un número similar de aviones. El grupo trabajando en PUSH había generado una gran cantidad de “waste”, o desperdicio, teniendo multitud de aviones a medio hacer, mientras que el nivel de desperdicio generado por el grupo prima era mucho menor. Al preguntar a los grupos cual había sido su sensación, expresaron además que el grupo trabajando en modo PUSH había estado muy estresado, trabajando a destajo para producir el mayor numero de tareas posibles. Sin embargo, el grupo prima había trabajado de forma muy relajada, al no realizar mas que las tareas cuando eran requeridas.Queremos agradecer a AdrianPerreau que nos enseñase este juego al resto de miembros de Agile-Barcelona.
- Nota: Durante las siguientesdiapositivas,ilustramos como crear un panel kanban a partir de dondeestasahora y como nos ayuda a visualizar el trabajo en curso, suflujo y la detección de cuellos de botella.
- Nota: Unavezconocidos los conceptos de Kanban y Scrumanteriormente, explicamos la utilización de ScrumBan.
- Agradecer una vez mas (nunca será bastante) a todos los que vinieron a la sesión, a los que quisieron venir pero finalmente no pudo ser, a todos los que han contribuido dando feedback sobre la dinámica y aportando geniales sugerencias de mejora, y a ti, que estas leyendo este documento.
- Nota: En esta ocasión, escojimos el modelo estrella como retrospectiva de la sesión...
- ...y estos fueron los resultados.
- Y ya por último, animaros a todos a seguir contribuyendo y compartiendo en la comunidad agile-barcelona, a través de cualquiera de sus canales: http://agile-barcelona.org : el blog de la comunidadhttp://twitter.com/@agilebcn : la cuenta de twitterhttps://groups.google.com/group/agile-spain-barcelona: el corazón de agile-barcelona, la lista en la que se realizan las discusiones, se proponen ideas, actividades, se organizan y en general, se comparte entre todos los miembros el deseo de seguir impulsando el uso de metodologías agiles.
- El curso de Introducción a Agile ha sido desarrollado colaborativamente por los que formamos la comunidad agile-barcelona. Durante la última sesión, decidimos realizar un Open Space, en que los alumnos pudiesen escoger en que temas querían profundizar mas mediante la discusión en grupo.
- No, no nos hemos equivocado en el orden de la presentación ni se ha acabado esta. Queremos daros las gracias por volver!
- Nota: Los dibujos ilustrativos fuerón realizados por Claudio Perreone, a quien queremos agradecerle que los compartiese para su uso. Se pueden encontrar en http://www.agilesensei.com/blog/articles/2011/05/14/open-space-cartoons/
- Nota: Los dibujos ilustrativos fuerón realizados por Claudio Perreone, a quien queremos agradecerle que los compartiese para su uso. Se pueden encontrar en http://www.agilesensei.com/blog/articles/2011/05/14/open-space-cartoons/
- Nota: Los dibujos ilustrativos fuerón realizados por Claudio Perreone, a quien queremos agradecerle que los compartiese para su uso. Se pueden encontrar en http://www.agilesensei.com/blog/articles/2011/05/14/open-space-cartoons/
- Nota: Los dibujos ilustrativos fuerón realizados por Claudio Perreone, a quien queremos agradecerle que los compartiese para su uso. Se pueden encontrar en http://www.agilesensei.com/blog/articles/2011/05/14/open-space-cartoons/
- Nota: Los dibujos ilustrativos fuerón realizados por Claudio Perreone, a quien queremos agradecerle que los compartiese para su uso. Se pueden encontrar en http://www.agilesensei.com/blog/articles/2011/05/14/open-space-cartoons/
- Nota: Los dibujos ilustrativos fuerón realizados por Claudio Perreone, a quien queremos agradecerle que los compartiese para su uso. Se pueden encontrar en http://www.agilesensei.com/blog/articles/2011/05/14/open-space-cartoons/
- Nota: Las sesiones escojidas por los alumnos fueronTrack1: - Vender proyectos agiles a clientes - Agile en equipos distribuidos - Planificar a largoTrack 2: - Dudas técnicas Scrum - Convencer a mi empresa - Equipos agiles trabajando con equipos no agiles
- Agradecer una vez mas (nunca será bastante) a todos los que vinieron a la sesión, a los que quisieron venir pero finalmente no pudo ser, a todos los que han contribuido dando feedback sobre la dinámica y aportando geniales sugerencias de mejora, y a ti, que estas leyendo este documento.
- Nota: Finalmente, realizamos una retrospectiva de que tan felices fueron en los diferentesdias del curso. En la diapositiva, se puede apreciar el resultado. Como siempre, Gracias, Gracias, Gracias!!
- Y ya por último, animaros a todos a seguir contribuyendo y compartiendo en la comunidad agile-barcelona, a través de cualquiera de sus canales: http://agile-barcelona.org : el blog de la comunidadhttp://twitter.com/@agilebcn : la cuenta de twitterhttps://groups.google.com/group/agile-spain-barcelona: el corazón de agile-barcelona, la lista en la que se realizan las discusiones, se proponen ideas, actividades, se organizan y en general, se comparte entre todos los miembros el deseo de seguir impulsando el uso de metodologías agiles.