Introducción a ScrumRodrigo [email protected]://geeks.ms/blogs/rcorralTwitter: r_corral
MVP Team System / CSM / CSP / PSDTPlain Concepts
El manifiesto ágil
Individuos e iteraciones sobre Procesos y Herramientas
Sofware que funciona sobre documentación exhaustiva
Colaboración con el cliente sobre negociación de contratos
Responder al cambio sobre seguir un plan
Aunque hay valor en los elementos de la derecha , valoramos más los elementos de la izquierda.
“La agilidad es un marco común las metodologías implementaciones”
Principios ágiles
Satisfacer al cliente.
Los cambios son bienvenidos.
Las entregas son frecuentes.
Trabajamos en equipo.
Motivamos a la gente.
Nos gusta la comunicación cara a cara.
Medida de progreso: Software que funciona.
Mantenemos un ritmo sostenido y sostenible.
La calidad no es opcional.
Primamos la simplicidad.
Evolucionamos nuestros diseños.
Reflexionamos con regularidad.
¿Por qué queremos ser ágiles?La aproximación ágil al desarrollo de software a demostrado ser mejor para lograr:
Reaccionar frente a cambios (en los requisitos, en el mercado, en las prioridades, en la arquitectura…)
Priorizar el desarrollo para logra maximzar el retorno de la inversión
Controlar en tiempo real el progreso del desarrollo, la calidad y los impedimientos.
Involucrar y motivar a los desarrolladores.
¿Quién usa Scrum?
Fuente: TFS Adoption within EMEA – A Process Perspectivehttp://processmentor.com/Community/blogs/carl_rogers/archive/2008/02/29/481.aspx
¿Quién usa Scrum?
Fuente: Scrum Alliance – Firms using Scrumhttp://scrumcommunity.pbworks.com/Firms+Using+Scrum
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
• Scrum permite que equipos de desarrolladores sean productivos en entornos con incertidumbre y cambios.
• Es un marco simple y poderoso, con reglas claras, que permite a los equipos y sus clientes adaptar y controlar el desarrollo de los proyectos.
• Proporciona una alto grado de claridad, visibilidad y transparencia.
• Scrum hace visibles rápidamente los problemas y permite y exige mejorar continuamente los resultados.
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• El Product Owner decide que se debe producir para lograr el éxito del proyecto y asegura el ROI.
• El Product Owner recoge la información proporcionada por usuarios finales, gestores, ‘stakeholders’, ejecutivos, expertos etc… y elabora una visión unificada.
• Esta visión unificada se recoge en una lista priorizada atendiendo al ROI y riesgo.
• Esta lista se llama Product Backlog.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• El Product Backlog el la lista única y maestra de requisitos.• Recoge requisitos funcionales y no funcionales priorizados
según el valor para el negocio y el riesgo según el criterio del Product Owner.
• El orden dentro de la lista deja clara la prioridad.• El Product Backlog es revisado constantemente y refinado
constantemente por el Product Owner y se añaden, eliminan o modifican los elementos para maximizar el valor para el negocio de esfuerzo del equipo.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• Descripción de una funcionalidad atómica desde el punto de vista del negocio.
• La descripción debe ser ‘suficiente buena’ para permitir a los desarrolladores primero estimarla y después dividirla en tareas y desarrollarla.
• Debe incluir criterios de aceptación.
Product Backlog Item / Historia de usuario
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• El tamaño ideal es de unos 7 miembros.• El equipo es multidisciplinar y tiene todos las capacidades
necesarias para desarrollar el proyecto. Todo el mundo contribuye según su capaciada, no según su puesto.
• El equipo es autoorganizado y auto gestionado.• El equipo es responsible de realizar compromisos basados
en estimaciones realista y alcanzar sus propios objetivos.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• El Scrum Master trabaja al servicio del equipo (elimina impedimentos), protege al equipo (de ruido, interrupciones, o interferencias) y les guía y enseña a usar Scrum.
• El Scrum Master es un facilitador (una jardinero, un apicultor…)
• Es el responsable de que todas las liturgias de Scrum ocurran.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• El equipo trabaja en periodos fijos de tiempo llamados Sprints.
• Los Sprints duran entre 1 y 4 semanas. Nunca más.• Los Sprints se suceden de manera continua.• Nada ocurre fuera de un Sprint (salvo Spikes puntuales).
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• El Product Owner propone el trabajo a realizar en cada sprint.• El Product Owner describe verbalmente el trabajo que el equipo
ha de realizar en el próximo sprint.• El equipo divide el trabajo a realizar el próximo sprint en tareas.• El equipo compromete el trabajo que estima que es posible
realizar.• Todo el equipo forma parte de este proceso.• Problema: todos los equipos comprometen más de lo que son
capaces de hacer en los primeros sprints.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• Durante el Sprint no cambia el alcance del trabajo comprometido por el equipo, ni la duración del spring (máximo 30 días)
• Esto permite al equipo mantener sus compromisos y permite que trabaje enfocado.
• Duarnte el sprint el PO trabaja para preparar el siguiente Sprint.• Si ocurre una circustancia anomala el Scrum Master puede
cancelar el sprint. Esto es un mecanismo de protección.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• En compensación por no hacer cambios durante el Sprint el Produc Owner puede hacer los cambios que considere necesarios antes de comenzar el siguiente Sprint.
• El Product Owner puede añadir, quitar, o reordenar elementos del Producto Backlog.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• Cada día el equipo mantiene una reunión corta de seguimiento (15 min. max.)
• Típicamente de pié cada miembro contesta tres preguntas:• ¿Qué hiciste ayer?• ¿Qué vas ha hacer hoy?• ¿Qué te impide avanzar?
• Es labor del Scrum Master actuar sobre los impedimentos detectados.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• El afán del equipo es completar el 100% del trabajo comprometido.
• Completado significa completado: funcionalidad totalmente diseñada, implementada y probada, sin defectos aparentes.
• Deplegar los incrementos de funcionalidad potencialmente entregables es opcional, pero siempre debería ser posible.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• Al final del Sprint el Product Owner, el equipo , el Scrum Master y todos los stakeholders que lo deseen se reúnen para ver una demostración de lo que el equipo a producido.
• El Product Owner recoge el ‘feedback’ de todo el mundo con el fin de mejorar los resultados del proyecto.
• El ‘feedback’ se incorpora al Producto Backlog y el Product Owner es quien lo prioriza.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
• El equipo, el Product Owner, y el ScrumMaster se reunen al final de cada Sprint y revisan cómo trabajan buscando maneras de mejorar su efectividad.
• Este es el mecanísmo de mejora continua y la manera de detectar problemas que deben ser corregidos y comunicados a gestores o clientes.
Scrum
2.3.4.
5.
1.
7.8.9.10.
6.
Product Backlog
TeamProduct Owner
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review
Incremento de funcionalidad
Sprint Retrospective
Scrum Master
Sprint
Sin cambios (ni en duración, ni en
alcance)
Tiempo
Recursos Alcance
Calidad
Flujo acumulado de proyecto¿Cuándo
terminaremos?¿Cuánto han cambiado los
requisitos?
Sprint burndown chart
¿Cuánto retraso tenemos
acumulado?
¿Qué ha cambiado?• Visibilidad total de como ‘funciona la fabrica’.• Implicar a todos en:
– La cultura de excelencia y calidad.– La gestión de los proyectos.– La inquietud por la mejora continua.– El servicio al cliente.
• Gestión basada en métricas claras y simples.• Todos el mundo tiene un modelo claro de como se
desarrolla software.• Todo el mundo trabaja contra objetivos claros, realistas y a
corto plazo.
Q&A, Recursos
Cursos Professional ScrumCalendario e información http://bit.ly/xc3rPE
May 7-8 Professional Scrum Foundations May 9-11 Professional Scrum Developer (.NET)
[email protected]://geeks.ms/blogs/jlsoria@jlsoriat
¡GRACIAS!