Curso Introducción a Agile

5,569 views
5,434 views

Published on

Presentación realizada durante el Curso de Introducción a Agile impartido por Agile-Barcelona

Published in: Education
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,569
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
187
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide
  • 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. 
  • Curso Introducción a Agile

    1. 1. AgileCurso de Introducción @agilebcn #agilebcn
    2. 2. Gracias!!
    3. 3. GrandesPreguntas
    4. 4. Agile: State of the art
    5. 5. agile?
    6. 6. Nuestra mayor prioridad essatisfacer al cliente mediante laentrega temprana y continua desoftware que aporta valor.
    7. 7. Los cambios son bienvenidos, aúnen fases tardias del desarrollo. Losprocesos Agile consideran elcambio una ventaja competitivapara sus clientes.
    8. 8. Entregamos software funcionandofrecuentemente, desde unas pocassemanas a unos pocos meses, conpreferencia por la escala mas corta.
    9. 9. Las personas de negocio y losdesarrolladores trabajan juntosdiariamente durante el proyecto.
    10. 10. Construimos los proyectosalrededor de personas motivadas.Les proveemos del entorno y elsoporte que necesitan, y confiamosen que harán el trabajo.
    11. 11. El método mas eficiente y efectivode compartir información con ydentro del equipo de desarrollo esla conversación cara a cara.
    12. 12. El software funcionando es laprincipal medida de progreso.
    13. 13. Promovemos el desarrollosostenible.Sponsors, desarrolladores yusuarios deben ser capaces demantener un ritmo sostenibleindefinidamente.
    14. 14. La atención continua a laexcelencia tecnica y el buen diseñomejora la agilidad del proceso.
    15. 15. Simplicidad – el arte de maximizarel trabajo no realizado – esesencial.
    16. 16. Las mejoresarquitecturas, requerimientos ydiseños emergen de equipos auto-organizados.
    17. 17. A intervalos regulares, el equiporeflexiona sobre como ser masefectivo, optimizando y ajustando elentorno de acuerdo a ello.
    18. 18. Dos procesos
    19. 19. Proceso predictivo
    20. 20. Proceso predictivo VALOR TIEMPO
    21. 21. Proceso predictivo VALOR TIEMPO
    22. 22. Proceso predictivo pero el ROI va menguando a medida que avanzamos VALORAlto ROI en lasprimeras etapas delproyecto TIEMPO
    23. 23. Proceso predictivo La ejecución se basa en planificaciones realizadas anteriormente. No existe proceso de aprendizaje. VALOR TIEMPO
    24. 24. Proceso Empírico “El acto de realizar acciones basandose en la situación real actual, no en una planificación anterior”
    25. 25. Proceso Empírico VALOR Ciclos cortos de planificación y ejecución basados en la situación actual del proyecto TIEMPO
    26. 26. Proceso Empírico VALOR El ROI es maximizado mediate planificaciones a corto plazo. TIEMPO
    27. 27. Proceso Empírico y el ROI final al proyecto es ampliamente mayor al anterior VALOR TIEMPO
    28. 28. Resultado: softwarefuncionando VALOR El equipo produce software funcionando periodicamente… TIEMPO
    29. 29. Resultado: softwarefuncionando 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. 30. 2 procesosProceso predictivo Proceso empírico
    31. 31. Siempre?
    32. 32. No, no siempreDesarrollo Tradicional Agile Sabemos lo que hay que hacer Descubrimos lo que hay que Sabemos como hacerlo hacer Descubrimos como hacerlo
    33. 33. No, no siempre
    34. 34. Modelos, Frame works y Metodologias
    35. 35. eXtreme Programming
    36. 36. SCRUMPriorización Planificación Ejecución Valor
    37. 37. KANBAN
    38. 38. SCRUMBAN
    39. 39. DSDM Atern
    40. 40. Proyecto “Ball Point”
    41. 41. Gracias!!(otra vez, nunca esta de mas)
    42. 42. Happiness door
    43. 43. http://agile-barcelona.org @agilebcnhttps://groups.google.com/group/agile-spain-barcelona
    44. 44. AgileSCRUM I @agilebcn #agilebcn
    45. 45. Gracias!!
    46. 46. Scrum?
    47. 47. Scrum: Fundamentos 1.Gestión Empírica 2.Ciclo de vida iterativo e incremental 3.Transparencia 4.Inspección y adaptación
    48. 48. Scrum: Objetivos1.Flexibilidad a cambios2.Gestionar la incertidumbre3.Complejidad4.Maximizar el ROI5.Anticipar TTM6.Comunicación y cooperación7.Maximizar calidad y productividad
    49. 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. 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. 51. Scrum: Equipo “ Desarrolla el producto previsto por el propietario del producto. “
    52. 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. 53. Scrum: Ciclo de Vida
    54. 54. Planificación
    55. 55. Product Backlog Historias de usuario Visión global Incompleta Diferente nivel de detalle Priorizado Cambia a lo largo del proyecto
    56. 56. Historias de UsuarioDescripción de funcionalidad desde el puntodel usuario y que expresa el valor que leaporta 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. 57. Las 3 C’s (al menos en inglés)TARJETA (CARD): Tarjeta física con la descripciónde la funcionalidadCONVERSACIÓN: Sobre los detalles de laimplementación para asegurar el entendimientoCONFIRMACIÓN: Tests de aceptación quepermiten fijar el alcance y verificar si la historiacumple o no los requisitos
    58. 58. Historias de Usuario “ Una historia de usuario es una invitación a conversar “
    59. 59. Historias de Usuario: Forma Como <rol> quiero <funcionalidad> para <beneficio>Como <usuario registrado>quiero <recibir una notificación cada vez queun “amigo” se conecta al sistema>para <poder hablar con el en ese momento>
    60. 60. Historias de Usuario: INVEST I – Independent N – Negotiable V – Valuable E – Estimable S – Small T – Testable
    61. 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. 62. A currar!
    63. 63. Visión“Queremos disponer de una aplicación declimatología para dispositivos móviles, queobtenga la información de un proveedorexterno de meteorología y la muestre alusuario, incluyendo temperatura así comodatos sobre lluvia o nieve”
    64. 64. Priorización Technology risk Business value basedMoSCoW
    65. 65. Gracias!!(otra vez, nunca esta de mas)
    66. 66. Retrospectiva
    67. 67. http://agile-barcelona.org @agilebcnhttps://groups.google.com/group/agile-spain-barcelona
    68. 68. AgileSCRUM II @agilebcn #agilebcn
    69. 69. Gracias!!
    70. 70. Estimación
    71. 71. Estimación ágil“El propósito inicial de la estimación no espredecir cuando un proyecto va a estarlisto;es determinar si los objetivos de unproyecto son lo suficientemente realistascomo para poder alcanzarlos” Steve McConnell, Software Estimation: Demystifying the Black Art
    72. 72. Estimación ágil
    73. 73. Estimación ágil
    74. 74. Estimación ágil
    75. 75. Puntos de HistoriaPuntos de Historia 0, 1, 2, 3, 5, 8, 13, 20, 40, 100Representa niveles de magnitudNos ayuda a expresar incertidumbreFacil y rápidoLa estimación no decae con el tiempo
    76. 76. Planning Poker
    77. 77. Tallas de Camisetas
    78. 78. Velocidad ¿Cuantos puntos somos capaces de entregar por iteración? =100 PH 3 Sprints!
    79. 79. Liturgias
    80. 80. Daily Meeting ¿Qué hiciste ayer? ¿Qué piensas hacer hoy? ¿Qué problemas has encontrado?
    81. 81. Sprint Demo
    82. 82. Retrospectiva
    83. 83. Todo es feedback!!
    84. 84. Burndown
    85. 85. Gracias!!(otra vez, nunca esta de mas)
    86. 86. RetrospectivaEscoger 5 dimensiones que puedan servaloradas sobre la formación
    87. 87. Retrospectiva
    88. 88. http://agile-barcelona.org @agilebcnhttps://groups.google.com/group/agile-spain-barcelona
    89. 89. AgileLEAN, KANBAN, SCRUMBAN @agilebcn #agilebcn
    90. 90. Gracias!!
    91. 91. Lean Thinking: Principios1. Eliminar el desperdicio Brindar un liderazgo técnico y de mercado Crear solamente cosas de valor2. Crear conocimiento Crear equipos multidisciplinares Mantener una cultura de mejora continua3. Embeber a la calidad Sincronizar Automatizar4. Postergar el compromiso Romper con las dependencias Mantener opciones5. Optimizar el total Enfocarse en el flujo completo de valor Entregar un producto completo6. Entregar rápido Trabajar en bloques pequeños Limitar el trabajo a la capacidad7. 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. 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. 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 realizadoExtra Procesamiento Procesos InnecesariosSobreproducción Funcionalidades innecesariasTransporte Cambios Frecuentes de actividadEspera EsperaMovimiento MovimientoDefectos Defectos
    94. 94. Lean Thinking: El 8 Waste Talento!!
    95. 95. Lean Thinking: Flow / Pull
    96. 96. Kanban
    97. 97. Kanban“Kanban is an approach to changemanagement. It isn’t a software developmentor project management lifecycle or process” David Anderson
    98. 98. Kanban: 3 PrincipiosEmpieza donde estas Kanban no preescribe un conjunto de reglas o roles especificos, ni procesos a seguir.Cambio evolutivo, incremental Cambios pequeños y graduales, mejoracontinua (Kaizen)Respeto por el proceso actual, roles,responsabilidades Reduce el miedo / resistencia al cambio yexperimenta los beneficios como equipo
    99. 99. Kanban: 5 PropiedadesVisualiza el flujo de trabajo Kanban significa literalmente “tablero”.Limita el trabajo en curso (WIP) Utiliza un sistema “pull” – establece y respeta tu capacidad idealGestiona el flujo Monitoriza, mide e haz visible el flujo de trabajo en cada estadoHaz 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. 100. Kanban
    101. 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. 102. Kanban: El tablero mas básico
    103. 103. Kanban: Limites
    104. 104. Kanban: Backlog
    105. 105. Kanban: Tu ciclo de vida
    106. 106. Kanban: Transiciones
    107. 107. Kanban: Dia 0
    108. 108. Kanban: El Backlog
    109. 109. Kanban: Dia N
    110. 110. Kanban: Responsabilidades
    111. 111. Kanban: Bloqueos
    112. 112. Kanban: Bloqueos
    113. 113. Kanban: “Priority Lane”
    114. 114. Kanban: Múltiples proyectos
    115. 115. Kanban: Múltiples proyectos
    116. 116. Kanban: Despliegue
    117. 117. Kanban: Despliegue
    118. 118. Scrumban
    119. 119. ¿Kanban + Scrum o Scrum + Kanban?
    120. 120. Gracias!!(otra vez, nunca esta de mas)
    121. 121. Retrospectiva
    122. 122. Retrospectiva
    123. 123. http://agile-barcelona.org @agilebcnhttps://groups.google.com/group/agile-spain-barcelona
    124. 124. AgileOPEN SPACE @agilebcn #agilebcn
    125. 125. Gracias!!
    126. 126. ¿Qué es un Open Space?
    127. 127. Open Space: cuatro principios
    128. 128. Open Space : cuatro principios
    129. 129. Open Space : cuatro principios
    130. 130. Open Space : cuatro principios
    131. 131. Open Space : cuatro principios
    132. 132. Open Space : y una ley
    133. 133. Lean Thinking: Flow / Pull
    134. 134. Gracias!!(otra vez, nunca esta de mas)
    135. 135. Retrospectiva
    136. 136. http://agile-barcelona.org @agilebcnhttps://groups.google.com/group/agile-spain-barcelona

    ×