Portada Titulo CharlaCurso Scrum Sprint #1 Expositores Expositor: Juan Sebastián Cardona Giraldo Temas Sprint 1 1. Presentaciones. 2. Teoría Agile. 3. ¿Qué es Scrum? 4. Ciclo Scrum. 5. Manifiesto Ágil. 6. Ejercicio Manifiesto Ágil. 7. Principios Ágiles. 8. Ejercicio Principios Ágiles. 9. Pilares Scrum. 10. Ejercicio Roles Scrum. 11. Roles Scrum. 12. Herramientas y Técnicas. 13. Ceremonias Scrum. 14. Artefactos Scrum. 15. Ejercicio Product Backlog. 2/24 Presentación Consultor JUAN SEBASTIÁN CARDONA GIRALDO Ingeniero Informático Especialista en Gerencia Integral Certificaciones: • Microsoft Specialist • Microsoft Certified Specialist • Microsoft Certified Technology Specialist 4/24 Teoría Agile Contexto Base Tradicional Fijo Ágil Alcance Tiempo Costo Valor en Marcha Plan en Marcha Estimado Costo Tiempo Alcance 5/24 Teoría Agile Enfoques Proyectos Predictivo • Bajamos la incertidumbre al inicio, a través de definiciones de alcance intensas. • Planeamos detalladamente. • Seguimiento continuo. • Resultado al final. • Hitos / Entregables validados, intermedios sin producto terminado, beneficio al final. Iterativo • Definición y planeación global al inicio. • Diferentes etapas que producen resultados que valida el cliente. • Productos intermedios que puede ir recuperando el beneficio. • El alcance y planeación detallada por etapa. Incremental • Definiciones de objetivo alcance global. • Ciclos de trabajo para validar resultados intermedios, no necesariamente recuperan el beneficio, pero mitigan riesgos. Agile • Iterativo + incremental siempre buscando capturar beneficio. • Ciclos cortos o iteraciones cortas (2 a 4 semanas, fijos = Timebox). • Alcance variable durante el proceso: backlog priorizado y continuamente refinado. Hibrido • La organización combina las diferentes opciones dependiendo de sus necesidades. 6/24 Teoría Agile Enfoques Proyectos ¿Su proyecto es ágil o no? • Predictivo: tradicional, proceso secuencial, productos terminados al final. • Iterativo: permite feedback para trabajo no finalizado totalmente para mejorarlo y modificarlo. • Incremental: entrega productos terminados aunque no con el alcance completo, el cliente puede usar – mínimos productos viables. • Agile: es ambos incremental e iterativo para refinar el trabajo y entregar frecuentemente. Método Requerimientos Actividades Entrega Meta Predictivo Fijos Ejecutadas una vez para el proyecto Entregables al final Costo - alcance Iterativo Dinámico Repetitivos Entregable único Solución correcta Incremental Dinámico Una vez por cada incremento Frecuentes Velocidad Agile Dinámico Repetitivos Frecuentes Entrega de valor En proyectos todos son válidos, cada uno es responsable de usar el adecuado. *Guía Agile PMBOK 6 7/24 Teoría Agile Modelo Cynefin Complejo Prácticas emergentes Probar, Percibir, Responder Caótico Prácticas novedosas Actuar, Percibir, Responder Complicado Buenas prácticas Percibir, Categorizar, Responder. Simple Mejores prácticas Percibir, Categorizar, Responder 8/24 9/24 ¿Qué es Scrum? Scrum es un framework para gestionar proyectos de manera ágil, usado principalmente para desarrollo de software. Este describe un acercamiento iterativo e incremental del trabajo de un proyecto. Los equipos que desarrollaron de estos productos partían de requisitos muy generales, así como novedosos y debían salir al mercado en un tiempo menor del que se tardaron en lanzar productos anteriores. Estos equipos seguían patrones de ejecución de proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboración entre los jugadores de Rugby y su formación de Scrum. 10/24 ¿Qué es Scrum? • Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el trabajo en productos complejos desde principios de los años 90. Scrum NO es un proceso, una técnica o método definitivo. En lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas. • Scrum muestra la eficacia relativa de las técnicas de gestión de producto y las técnicas de trabajo de modo que podamos mejorar continuamente el producto, el equipo y el entorno de trabajo. El marco de trabajo Scrum consiste en los Equipos Scrum y sus roles, eventos, artefactos y reglas asociadas. • Cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de Scrum y para su uso. Las reglas de Scrum relacionan los roles, eventos y artefactos y rigen las relaciones e interacciones entre ellos. Las estrategias específicas para usar el marco de trabajo Scrum son diversas y están descritas en otros lugares. 11/24 Fundadores de Scrum Ken Schwaber Jeff Sutherland 12/24 Beneficios • Se pueden gestionar las expectativas del cliente de manera regular (requisitos desarrollados, velocidad de desarrollo, calidad), y se puede tomar decisiones en cada iteración. Considera que: ➢ El cliente no sabe exactamente qué es lo que necesita, lo va sabiendo conforme va viendo cuáles son los resultados del proyecto. ➢ El cliente necesita hacer cambios a corto plazo (nuevos requisitos o cambios en los ya realizados). ➢ El equipo necesita saber si lo que ha entendido es lo que el cliente espera. • El cliente puede obtener resultados importantes y utilizables desde las primeras iteraciones. • El cliente puede comenzar el proyecto con requerimientos de alto nivel. Sólo es necesario el detalle de requerimientos de las primeras iteraciones que son las que aportan más valor. • Se puede administrar de manera natural los cambios que van apareciendo durante el proyecto. • Al finalizar cada iteración el equipo puede decidir cómo mejorar su proceso de trabajo, en función de la experiencia obtenida. 13/24 Beneficios • Permite mitigar desde el inicio los riesgos del proyecto. • Permite gestionar la complejidad del proyecto. • Permite optimizar el uso de recursos disponibles, generando continuamente las características del producto de mayor valor. • Dado que cada iteración debe dar como resultado requerimientos terminados, se minimiza el número de errores, que se producen en el desarrollo y se aumenta la calidad. 14/24 Restricciones • La disponibilidad del cliente debe ser alta durante todo el proyecto dado que participa de manera continua. • La relación con el cliente ha de estar basada en los principios de colaboración más que tratarse de una relación contractual. • Cada iteración debe dar como resultados requisitos implementados, de manera que el resultado sea realmente útil para el cliente y no deje tareas pendientes para futuras iteraciones o para la finalización del proyecto. 15/24 Ciclo Scrum 16/24 Ciclo Scrum 17/24 Manifiesto Ágil (2001) Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas. Software funcionando sobre documentación extensiva. Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. Colaboración con el cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un plan. 18/24 Ejercicio Manifiesto Ágil En equipos seleccionar un enunciado del Manifiesto Ágil e identificar los atributos principales. Utilice un dibujo, palabras, cuadros o cualquier ayuda que le permita expresar sus ideas. Tiempo estimado: 20 minutos 19/24 Los 12 Principios Ágiles 1. La prioridad es satisfacer al cliente a través de entregas tempranas y frecuentes. 2. Recibir cambios de requerimientos, aún en etapas finales. 3. Entregas frecuentes (entre 2 semanas a un mes). 4. Técnicos y no técnicos trabajando juntos TODO el proyecto. 5. Hacer proyectos con individuos motivados. 6. El medio de comunicación por excelencia es cara a cara. 7. La mejor métrica de progreso es la cantidad de producto funcionando. 8. El ritmo de entrega es sostenible en el tiempo. 9. Atención continua a la excelencia técnica. 10. Simplicidad - Maximización del trabajo no hecho. 11. Las mejores arquitecturas, diseños y requerimientos emergen de equipos auto – organizados. 12. A intervalos regulares, el equipo evalúa su desempeño y ajusta la manera de trabajar. 20/24 Ejercicio Principios Seleccionar un Principio Ágil e identificar sus palabras claves. Dibujar un objeto que permita recordar el principio. Tiempo estimado: 20 minutos 21/24 Pilares Scrum El conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce, Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo. 3 pilares soportan la implementación del control de procesos empírico: Transparencia PILAR 1 • Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado. • Dichos aspectos tienen que estar definidos por un estándar común para que los observadores compartan entendimiento común de lo que se está viendo. Inspección PILAR 2 PILAR 3 • Los usuarios deben inspeccionar frecuentemente los artefactos de Scrum y el progreso para detectar variaciones. • La inspección tiene lugar durante: Sprint Planning, Daily Meeting, Sprint Review y Sprint Retrospective. Adaptación • Si se determina que uno o más aspectos se desvían de límites aceptables deberá ajustarse y hacerlo lo antes posible. • La Retrospectiva del Sprint es el momento que formalmente se reserva para implantar las mejoras durante el siguiente Sprint. 22/24 El concepto Shu Ha Ri para ágil Ri Ignorar las reglas. Ha Shu Adaptar las reglas. Aprender las reglas. Mezclar técnicas, crear estilo propio adaptado al contexto. Aprender otras técnicas, ver más allá de lo básico. Aprender y ejecutar lo que indica el “maestro”. 23/24 Roles Scrum Product Owner Team Scrum Master 24/24 Ejercicio Roles ¿Cuáles creen que son las Responsabilidades/Habilidades de cada rol? Tiempo estimado: 15 minutos 25/24 Roles Scrum Product Owner • Responsable de qué será desarrollado y en qué orden. • Empoderado para ser el punto central del producto. • Comunica a los otros participantes la visión de lo que se espera obtener. • Responsable del éxito de la solución desarrollada. • Responsable de que se realice el trabajo que de mayor valor de negocio (ROI). • Responsable de revisar el producto desarrollado. • Trabaja de forma colaborativa con el Scrum Master y el equipo de desarrollo. • Debe estar disponible para responder las preguntas sobre el producto, tan pronto como se presenten. 26/24 Roles Scrum Scrum Master • • • • • • • Responsable de guiar al equipo en crear y seguir su propio proceso basado en el marco de Scrum. • Es un facilitador que ayuda al equipo a resolver los problemas que se vayan presentando y a mejorar la aplicación de las prácticas de Scrum. • Líder de procesos, ayudando al equipo a lograr un alto desempeño siguiendo el proceso Scrum. Responsable por proteger al equipo de cualquier interferencia externa. Enseñar al equipo a auto administrarse. Guía las reuniones de Scrum. Es un mentor, no una autoridad jerárquica en el equipo. Actúa como interface entre el equipo y la gerencia, busca apoyo de la gerencia. Toma el liderazgo para remover los impedimentos del equipo. 27/24 Roles Scrum Team • Responsables por determinar cómo entregar el producto solicitado por el Product Owner. • Se auto organiza para determinar la mejor forma de cumplir con las metas definidas por el Product Owner. • Tamaño típico 7 +/- 2 (puede ser entre 5 y 9). • Los miembros del equipo deben tener todas las habilidades para crear un producto funcional de alta calidad (equipo multifuncional). • Trabajo en equipo. • Comunicación constante y transparente. • Enfocados y comprometidos. 28/24 Historias de usuario Tableros Kanban Priorización Technicas Retrospective Planning Poker Velocidad Mapa Resumen Scrum Herramientas y Técnicas 29/24 Herramientas y Técnicas Velocidad • La rata a que un equipo puede producir, es una medida que no es tiempo, por ejemplo, puntos de historia de usuario. Se usa para poder estimar y planear, es la entrada. • Lo más cercano es medir en puntos de historia que el equipo puede entregar por Sprint una vez tenemos la “Definition of Done”. • Los puntos no suman si no se acepta el producto. Si no aceptan nada quiere decir que el equipo generó 0 producción. • Se requiere estabilizar en el equipo para poder tomarse como un punto confiable para planear. 30/24 Herramientas y Técnicas Velocidad Definición Puntos entregados por Sprint. ¿Cómo se calcula? Tener en cuenta ¿Cómo se usa? Por 3 a 4 Sprints contar los mínimos máximos y promedios de velocidad. • Velocidad cambia con elementos de calidad. • Velocidad de 2 equipos no es comparable. • Velocidad cambia con la composición del equipo. • No incluye bugs ni historias rechazadas. • Para determinar que entra al Sprint. • Para calcular costo aproximado de un release. • Verificar el progreso del Sprint. 31/24 Herramientas y Técnicas Planning Poker Método de estimación relativa. Pasos: • • • • • Cada estimador tiene sus cartas. Cada carta tiene los puntos de estimación. El Product Owner lee una historia y la discuten en breve. Cada estimador selecciona una carta en forma anónima. Al contar de 3 todos muestran su carta. Se discuten las diferencias mayores y se vuelve a correr hasta que se tenga un valor más homologado. • El equipo decide cuando ya puede decir el valor estimado. 32/24 Herramientas y Técnicas Technicas Retrospective ¿Quién? “Equipo Scrum” ¿Cuándo?¿Cuánto? Después del Sprint Review Duración 2 horas por Sprint de 2 semanas ¿Entrada? Información de los equipos acerca del último Sprint. ¿Salida? Lo que salió bien Plan de mejoras (Potenciales) 33/24 Herramientas y Técnicas Priorización El Product Owner y el equipo pueden usar diferentes técnicas para decidir la prioridad del Backlog. La decision final de esta prioridad es del Product Owner. 34/24 Herramientas y Técnicas Tableros Kanban Promueve que se minimice el trabajo en progreso (multitasking del equipo) y genera una forma visual de ver los esfuerzos en el proceso. Principios: • • • • • Visualizar el workflow Límite el trabajo en progreso Administrar el flujo Hacer explicitas las políticas Mejorar colaborativamente (using models & the scientific method) 35/24 Herramientas y Técnicas Historias de Usuario • Es un requerimiento simple y breve desde la perspectiva del usuario. • Son homólogos a conversaciones cortas que representan la necesidad y el criterio de aceptación. 1. 2. 3. 4. ¿Quién? ¿Qué? ¿Por qué? Criterio de aceptación NO son historias: • Crear una tabla. • Encriptar un password. • Adicionar un botón. Grandes/épicas/características: • Login page • Un Website • Un documento Es una pequeña pieza de funcionalidad que provee valor para el usuario. ¿Quién escribe las Historias de Usuario? • Todo aquel que tenga la necesidad. • Liderado por Product Owner • Asistido por el equipo (Team). • Requiere colaboración. 36/24 Scrum El corazón de Scrum es el Sprint, es un bloque de tiempo (timebox) definido durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable. Es más conveniente si la duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior. 37/24 Scrum Los Sprints contienen y consisten: • • • • • Planificación del Sprint (Sprint Planning) Reunión Diaria (Daily Meeting) Revisión del Sprint (Sprint Review) Retrospectiva del Sprint (Sprint Retrospective) Trabajo de desarrollo 38/24 Scrum Los Sprints contienen y consisten: • • • • • Planificación del Sprint (Sprint Planning) Reunión Diaria (Daily Meeting) Revisión del Sprint (Sprint Review) Retrospectiva del Sprint (Sprint Retrospective) Trabajo de desarrollo 39/24 Cancelación Scrum Un Sprint puede cancelarse antes de que el bloque de tiempo llegue a su fin. Solo el Product Owner tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del Team o del Scrum Master. Las cancelaciones de Sprint consumen recursos ya que todos se reagrupan en otra Planificación de Sprint para empezar otro Sprint. Las cancelaciones de Sprint son a menudo traumáticas para el Equipo Scrum y son muy poco comunes. 40/24 Scrum Goal El Objetivo del Sprint es una meta establecida para el Sprint que puede lograrse mediante la implementación de la Product Backlog. Proporciona una guía al Team acerca de por qué está construyendo el incremento. Se crea durante la Sprint Planning. El objetivo del Sprint brinda al equipo de desarrollo cierta flexibilidad con respecto a la funcionalidad implementada en el Sprint. 41/24 Ceremonias Scrum • Ceremonias o eventos son predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. • Todos los eventos son bloques de tiempo (Time boxes) por lo que tienen una duración máxima. Una vez que comienza Sprint su duración es fija y no puede acortarse o alargarse. • Los demás eventos pueden terminar siempre que se alcance el objetivo del evento. • Cada uno de los eventos de Scrum constituye una oportunidad formal para la inspección y adaptación de algún aspecto. • Estos eventos se diseñaron específicamente para habilitar los pilares vitales de transparencia e inspección. Sprint Planning Daily Meeting Sprint Review Sprint Retrospective 42/24 Ceremonias Scrum • El equipo decide que ítems del Backlog realizará. • Detalla las actividades para lograrlo y su auto organización. • 4 horas por Sprints de 2 semanas. Sprint Planning Daily Meeting Sprint Review Sprint Retrospective 43/24 Ceremonias Scrum La Planificación de Sprint responde a las siguientes preguntas: • ¿Qué puede entregarse en el Incremento resultante del Sprint que comienza? • ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento? Sprint Planning Daily Meeting Sprint Review Sprint Retrospective 44/24 Ceremonias Scrum Capacidad del equipo Sprint Planning Meeting Objetivo del Sprint Product Backlog Priorización: • Analizar y evaluar el Product Backlog. • Seleccionar el objetivo del Sprint. Condiciones del Negocio Producto Actual Tecnología Planificación: • Decidir cómo alcanzar el objetivo del Sprint. • Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog. • Estimar Sprint Backlog en horas. Sprint Backlog 45/24 Ceremonias Scrum Plantilla sugerida: Actividades Objetivo del Sprint Riesgos / Dependencias 46/24 Ceremonias Scrum • • • • Punto de inspección y adaptación en Scrum, máximo 15 minutos. El equipo se reúne para comunicar y entender el estatus. Esencial para conocer el progreso continuo y evitar bloqueos. No tiene como objetivo reportar progreso al Scrum Master, Product Owner o cualquier otro Stakeholder. • El Product Owner podrá participar siempre y cuando su participación sea pasiva. • El Scrum Master se asegura de que el Equipo de Desarrollo mantenga la reunión, pero éste último es quien es responsable de dirigir el Scrum Diario. Sprint Planning Daily Meeting Sprint Review Sprint Retrospective 47/24 • Si hay otros asistentes que no hablen • Focaliza que los equipos tengan transparencia cuenten los impedimentos y evita otras reuniones Parámetros • Si un tema se identifica que requiere ser Diaria sin falta resuelto por el equipo no se resuelve ahí , el 15 minutos scrum facilita un espacio posterior solo con los Todos de pie involucrados. No es para resolver problemas • Fallas comunes de disciplina con el tiempo, Promueve el compromiso del equipo con tomarlo para otras cosas , interrupciones, Promueve relaciones mas cercanas dificultad de equipos remotos, Ayuda a resolver incidencias mas rápidamente • Maneje los tableros de apoyo en el Daily. Todo el equipo debe estar presente Solo habla uno a la vez sin interrupciones Ceremonias Scrum • • • • • • • • • • Sprint Planning Daily Meeting Sprint Review Sprint Retrospective 48/24 Ceremonias Scrum Para esta reunión la idea es que se respondan estas 3 preguntas: 1. ¿Qué hiciste ayer? 2. ¿Qué vas a hacer hoy? 3. ¿Qué impedimentos/riesgos tengo? Sprint Planning Daily Meeting Sprint Review Sprint Retrospective 49/24 Ceremonias Scrum • Demostración de las nuevas funcionalidades que el equipo desarrolló durante el Sprint. • Se inspecciona lo entregado por el equipo y se obtiene retroalimentación de los asistentes para poder adaptar el plan para próximos Sprints. • Deben asistir todos los involucrados relevantes, para ayudar al equipo con retroalimentación valiosa sobre el producto. • El resultado es un Product Backlog revisado, que define los elementos posibles para el siguiente Sprint. • La duración es de 4 horas para un Sprint de un mes. Sprint Planning Daily Meeting Sprint Review Sprint Retrospective 50/24 Ceremonias Scrum • El foco es la mejora continua del proceso. • La retrospectiva se restringe a los miembros del equipo Scrum: Product Owner, equipo de desarrollo y Scrum Master. • Se inspecciona en profundidad cuán colaborativo y productivo es el equipo y cómo hacer para mejorar. • Al final el equipo debe haber identificado y se debe haber comprometido con acciones de mejora al proceso. • Duración de 3 horas para un Sprint de un mes. Sprint Planning Daily Meeting Sprint Review Sprint Retrospective 51/24 Artefactos Scrum Product Backlog • Se busca hacer el trabajo más valioso primero. • Es responsable por determinar y administrar la secuencia del trabajo. • Características requeridas para cumplir la visión del producto. • Se puede alimentar con nuevas características, cambios, corrección de defectos, mejoras técnicas, etc. 52/24 Artefactos Scrum Product Backlog • Única fuente de requerimientos. • Contiene todo lo necesario para cumplir con la visión del producto • Lista ordenada de características, funciones, requerimientos, mejoras, y arreglos. • Nunca está completo. • Constante cambio para identificar las necesidades del Producto – Dinámico • Re priorizado frecuentemente. • El backlog consiste de elementos del Product Backlog (PBI). • La mayoría de los equipos Scrum utilizan historias de usuario como PBI. 53/24 Ejercicio Product Backlog Crear el Backlog del ejercicio de la Tienda de Libros. Tiempo estimado: 30 minutos 54/24 Artefactos Scrum Duración promedio del Sprint Timebox 60% 1 semana 2 semanas 7% 5% Otros 29% 3- 4 semanas * Reporte Sate de Scrum de 2015 55/24 Artefactos Scrum • Se revisa el Product Backlog y se determinan los elementos de alta prioridad que puedan ser incluidos realmente en el Sprint. Sprint Backlog • Se determina la “Velocidad” del equipo para determinar el tiempo (esfuerzo). • Se dividen los elementos del Product Backlog en tareas. 56/24 Artefactos Scrum • La liberación es una decisión de negocio. • El equipo tiene confianza en que el producto está listo para ser deliberado. Burn Down / Burn Up Charts • Una parte determinada del producto o un incremento del producto existente. 57/24 www.sistemas-expertos.com
