Introducción a ScrumRodrigo Corralrcorral@plainconcepts.comhttp://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)

jlsoria@plainconcepts.comhttp://geeks.ms/blogs/jlsoria@jlsoriat

¡GRACIAS!