Certified ScrumMaster

Gestin gil de Proyectos

Rafael Sabbagh CST

Rafael Sabbagh
Certified Scrum Trainer (CST), Scrum Alliance ScrumMaster, Scrum Coach & Scrum Trainer
Conferencista en eventos y congresos:

@rsabbagh

Organizador:

Participante:

Un poco de historia...

Un poco de historia...
Dcada del 50: la gestin de proyectos es reconocida como materia, nacida de la administracin Henri Fayol: Su trabajo es la base de la gestin tradicional de proyectos El gerente posee 5 funciones bsicas:

Planificar Planear

Organizar Comandar

Controlar

Coordinar

Hasta entonces, la gestin de proyectos trataba de grandes proyectos de ingeniera y construccin civil.

Un poco de historia...
Dcada del 60: el desarrollo de software empieza a ganar complejidad Proyectos de software: el uso de metodologas tradicionales empieza a ser aplicado a proyectos de ingeniera y construccin civil Empiezan a aparecer los Problemas:
El desarrollo de software exige cambios frecuentes el cliente no sabe exactamente lo que quiere hasta ver partes del software terminadas

Un poco de historia...
1970: Winston Royce publica un artculo, donde critica el abordaje tradicional en el desarrollo de softwares

Waterfall

Un poco de historia
BDUF Big Design Up Front

Waterfall usa BDUF!

La Revisin exhaustiva de la especificacin puede garantizar la ausencia de cambios crticos en la fase de ejecucin

Es adecuado slo para proyectos estables, con poco o ningn cambio

Los cambios deben ser evitados a toda costo Si no es posible evitarlos, el gerente de proyectos debe gestionarlos

Un poco de historia
Software es diferente! 1990: DeGrace & Stahl presentan factores que vuelven cuestionable el uso de BDUF en proyectos de software: Los requisitos no son totalmente comprendidos al inicio del proyecto;

Los usuarios slo saben exactamente lo que quieren despus de ver una versin inicial del producto;
Los requisitos cambian durante el proceso de desarrollo; Nuevas herramientas y tecnologas vuelven imprevisible la estrategia de desarrollo

Agilidad

Agilidad

2001: representantes de procesos de desarrollo de software se reunieron para discutir sobre lo que posean en comn sus procesos

Los 12 Principios giles

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardas del desarrollo. Los procesos giles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo ms corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecucin del trabajo.

6. El mtodo ms eficiente y efectivo de comunicar informacin al equipo de desarrollo y entre sus miembros es la conversacin cara a cara.

Los 12 Principios giles

7. El software funcionando es la medida principal de progreso. 8. Los procesos giles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atencin continua a la excelencia tcnica y al buen diseo mejora la Agilidad. 10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseos emergen de equipos auto-organizados. 12. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para a continuacin ajustar y perfeccionar su comportamiento en consecuencia.

Por qu Scrum?

Por qu Scrum?
Entrega ROI en cada release (tajada a tajada), no solamente al final Acepta cambios: el input y el feedback del cliente reducen riesgos, permitiendo el desarrollo del producto indicado Evita desperdicio!
Slo produce lo que el cliente realmente usar Planifica solo lo suficiente y necesario, con el nivel de detalle adecuado Slo genera los artefactos necesarios y suficientes (por ejemplo: documentacin)

Por qu Scrum?
Transparencia
El Cliente acompaa y recibe los resultados desde el inicio Indicadores de progreso tempranos reducen riesgos
Sprint burndown. cuadro de tareas, Release burndown Daily Scrum

Aumenta la productividad
Interaccin y comunicacin entre los miembros del Equipo de Desarrollo. Trabajo en ritmo sostenible Propiedad: El equipo de desarrollo es responsable y responde por los resultados de su trabajo

Inspeccin y adaptacin para la mejora continua del producto

Inspeccin y adaptacin para la mejora continua del trabajo del Equipo de Desarrollo

Nivel de Detalle de la Planificacin

Uso de Funcionalidades por el Cliente

Uso de Funcionalidades por el Cliente

Siempre Frecuentemente 7%
45% 16%

A veces 13% Raramente Nunca

19%

Fonte: Standish Group, 2002

El scrum es para proyectos complejos

Fonte: Agile Project Management with Scrum, Ken Schwaber, 2004

Qu es Scrum?

Scrum
...es un framework gil y simple para el desarrollo de productos complejos en ambientes complejos; ...no es un proceso o tcnica: dentro de Scrum se pueden emplear varios procesos y tcnicas;

...utiliza el abordaje iterativo e incremental para mejorar la previsibilidad y la gestin de riesgos;

Scrum...

...genera entregas de valor al frecuentemente y de forma temprana;

cliente,

...vuelve los problemas de las prcticas de desarrollo transparentes, para que se puedan mejorar;

...utiliza inspeccin y adaptacin para la mejora continua del producto y de los procesos de desarrollo;

Scrum...

...utiliza equipos auto-organizados, que definen las mejores formas de desarrollar las funcionalidades de mayor valor

...es orientado a valor y no a planes

...focaliza el orden del trabajo basado en el mayor valor de negocio para el cliente;

Los Orgenes de Scrum

Scrum: Orgenes
Ken Schwaber, inicio de los aos 90: desarrollo en su empresa de lo que se volvera Scrum Jeff Suttherland, 1993: desarrollo del Scrum en Easel Corporation Ken Schwaber : formalizacin de Scrum en la OOPSLA95 Aos siguientes: Schwaber y Sutherland colaboran para unificar sus trabajos

Publicacin del libro Agile Software Development with Scrum, por Ken Schwaber y Mike Beedle

Scrum: Orgenes
The New New Product Development Game, de Takeuchi y Nonaka (1986)
Equipos de desarrollo de nuevos productos de empresas americanas y japonesas

Inestabilidad embebida Equipos auto-organizados Fases de desarrollo superpuestas Aprendizaje mltiple Control sutil Transferencia organizacional de aprendizaje

Scrum: Orgenes
The New New Product Development Game, de Takeuchi y Nonaka (1986)

El nombre

Scrum viene del Rugby!

Scrum: Orgenes
Sistema Toyota de Produccin y Produccin sin Excesos
Produccin orientada por el cliente Produccin del valor en flujo estable y continuo, sin paradas, lotes, filas o departamentos Calidad embebida en el proceso: jidoka Mejora continua: kaizen Combate al desperdicio:
muda: etapas sin valor muri: sobrecarga en las personas y equipos mura: desbalances en los ritmos de produccin

Los Pilares de Scrum

Los Pilares de Scrum

Procesos Definidos vs. Procesos Empricos
Procesos definidos:
Ambientes controlados
Por ejemplo: lneas de produccin

Mismas entradas, mismas salidas

Procesos empricos:
Complejos e imprevisibles Diferentes entradas, diferentes salidas

Scrum se basa en la Teora de Control de Procesos Empricos

Los Pilares de Scrum

#1: Transparencia: ver y entender

#2 Inspeccin: investigar

#3 Adaptacin: mejorar

Introduccin a Scrum

Equipo de Scrum
Product Owner
Garantiza y maximiza el ROI del cliente a partir del trabajo del Equipo

Equipo de Desarrollo
Genera valor para el cliente construyendo incrementos del producto con alta calidad

ScrumMaster
Garantiza que los valores prcticas y reglas de Scrum estn siendo comprendidos y seguidos

El Ciclo de Scrum

Resumen del Ciclo de Scrum

LA VISIN DEL PRODUCTO debe ser creada antes del inicio del desarrollo

Resumen del Ciclo de Scrum

El representante del cliente, llamado Product Owner, define junto con los stakeholders los requisitos de mayor prioridad en ese momento

Resumen del Ciclo de Scrum

A continuacin, incluye esos requisitos en una lista ordenada, llamada PRODUCT BACKLOG

Resumen del Ciclo de Scrum

El Product Owner y el Equipo de Desarrollo se renen en el SPRINT PLANNING MEETING y generan el SPRINT BACKLOG: qu ser realizado y cmo ser realizado en este ciclo de desarrollo (SPRINT)

Resumen del Ciclo de Scrum

El Equipo de Desarrollo hace el trabajo de desarrollo del incremento del producto que fue planificado, buscando llegar a la Meta del Sprint

Resumen del Ciclo del Scrum

Qu hice?

Qu har?
Cules fueron los impedimentos?

A diario, el Equipo de Desarrollo realiza la DAILY SCRUM, una reunin de 15 minutos para promover visibilidad y comunicacin entre los miembros del Equipo

Resumen del Ciclo del Scrum

DEFINICIN DE DONE __ ____ ____ ________ __ _____ ___ __

Al final del ciclo de desarrollo, el Equipo de Desarrollo habr producido un incremento en el producto listo, que significa valor para el cliente

Resumen del Ciclo del Scrum

El Equipo de Desarrollo se rene con el Product Owner y los stakeholders en la SPRINT REVIEW y presenta lo que fue realizado en el Sprint

Resumen del Ciclo del Scrum

A continuacin, el Equipo de Scrum se rene en la SPRINT RETROSPECTIVE, donde verifica lo que funcion bien y lo que puede ser mejorado en los prximos Sprints

Resumen del Ciclo del Scrum

...y un nuevo ciclo comienza.

Roles del Equipo de Scrum

Roles del Equipo de Scrum: ScrumMaster

ScrumMaster: Atribuciones Garantiza que sean seguidos los valores de Scrum, prcticas y reglas
Resuelve los impedimentos que impiden el trabajo del Equipo de Desarrollo. Facilita las reuniones del Scrum Facilita el trabajo del Equipo de Desarrollo y su relacin con el P. O. Ensea Scrum al Equipo de Desarrollo y cmo autoorganizarse Garantiza que el Equipo de Desarrollo posee todo lo necesario para mejorar su trabajo (calidad y productividad) y lo incentiva a realizarlo

ScrumMaster: Atribuciones Garantiza que sean seguidos los valores de Scrum, prcticas y reglas
Alinea las necesidades del Equipo de Desarrollo y las de la organizacin Puede ayudar a seleccionar el P. O. Garantiza que el P. O. posee todo lo que precisa para saber realizar su trabajo

ScrumMaster: Caractersticas
Competente en soft skills: facilitador, negociador, comunicador, gestin de conflictos etc. Valiente para realizar los cambios necesarios y resolver los impedimentos Preferentemente est presente durante todo el trabajo del Equipo de Desarrollo. Exento/imparcial lo necesario para no interferir en las decisiones del Equipo de Desarrollo sobre el trabajo de desarrollo y para no interferir en las decisiones del Product Owner sobre el producto

ScrumMaster

Roles del Equipo de Scrum: Product Owner

Product Owner: Atribuciones Es responsable por garantizar y maximizar el ROI del cliente a partir del trabajo del Equipo de Desarrollo.
Administra el Product Backlog: garantiza la visibilidad, incluye, retira, modifica y ordena los tems Se relaciona con los stakeholders del proyecto
identifica los stakeholders y su nivel de apoyo se comunica con ellos para entender sus necesidades balancea las diferentes necesidades de los stakeholders influencia a los stakeholders

Administra la Visin del Producto: establece, mantiene y comunica

Administra los Releases del producto enviados al cliente

Product Owner: Atribuciones Es responsable por garantizar y maximizar el ROI del cliente a partir del trabajo del Equipo de Desarrollo.
Participa activamente de los Sprints
Est disponible para el Equipo de Desarrollo Sprint Planning / Sprint Review (y Release Planning)

Acepta o rechaza en la Sprint Review el trabajo realizado por el Equipo de Desarrollo. Garantiza que hay presupuesto suficiente para el proyecto durante todo su desarrollo

Product Owner: Caractersticas

nico (slo puede existir uno!) No es un comit, no hay reemplazantes Influenciado por otros (Equipo de Desarrollo, stakeholders e, inclusive, un equipo de negocios) Tiene la palabra final sobre el Product Backlog Est disponible para aclarar las dudas del Equipo de Desarrollo y tomar decisiones sobre el producto para hablar con los stakeholders y actualizar el Product Backlog frecuentemente

Representativo con suficiente poder y conocimiento necesario para tomar decisiones rpidas y correctas sobre el producto

Roles del Equipo de Scrum: Equipo de Desarrollo

Equipo de Desarrollo: Atribuciones Genera valor para el cliente construyendo incrementos del producto con alta calidad
Trabaja sobre el Product Backlog, en direccin a la visin del producto Entrega valor frecuentemente al cliente

Se auto-organiza para realizar el trabajo

poder suficiente para administrar su trabajo, responsable por sus resultados comunicacin: los mejores equipos son pequeos (7 2 miembros) y colocados

Se comunica frecuentemente con el P. O. dudas y decisiones sobre el producto Informa los impedimentos al ScrumMaster en el momento en que son detectados

Equipo de Desarrollo: Caractersticas

Multidisciplinario
todo el conocimiento y las habilidades necesarias para realizar el trabajo terminado(DoD), incluyendo calidad Feature Teams No hay ttulos en el Equipo de Desarrollo. Fertilizacin cruzada: uno aprendiendo del otro

Suficientemente pequeo (7 2) para garantizar la comunicacin Motivado, con la confianza y apoyo necesarios Buscando la excelencia tcnica

Comprometido a alcanzar las metas del Sprint/Release los mejores Equipos de Desarrollo son 100% dedicados al proyecto (sin multitasking)

User Stories para tems del Product Backlog

User Stories

Quin?
Qu?

Como un <PERFIL>, yo puedo/me gustara/debo <FUNCIN> para <VALOR>

Como COMPRADOR, puedo VER LIBROS para ELEGIR LO QUE VOY A COMPRAR

Por qu?

User Stories
Las User Stories son una buena forma de representar los tems del Product Backlog Por qu? User Stories guan el Equipo de Desarrollo con enunciados concisos y directo al punto ayudan a mantener los tems del Product Backlog alineados con la Visin del Producto llevan el P. P./clientes a una profunda reflexin al escribirlas ....invitan al Equipo de Desarrollo y al P. P./clientes a conversar sobre el producto

User Stories: las tres C

CARD (tarjeta)
Describe la story, lo necesario para identificar el requisito y para recordar de qu se trata la story

CONVERSATION (conversacin)
Conversaciones sobre la story, a travs de las cuales, de hecho, el requisito es comunicado por el cliente a los programadores

CONFIRMATION (confirmacin)
Pruebas que documentan los detalles de la story y pueden ser usadas para determinar cundo est terminada

User Stories: INVEST

Una User Story debe ser:

Independent Negotiable Valuable Estimable Small Testable

Independiente de las otras stories Negociable, detalles sern negociados Valiosa para el cliente Estimable por los desarrolladores Pequea en esfuerzo de implementacin Comprobable para permitir su confirmacin

User Stories: Stories, Temas y Epics

STORY

PICA

STORY
STORY

STORY
STORY

STORY

TEMA
STORY STORY STORY STORY STORY
STORY

STORY

STORY

User Stories: Story-Writing Workshop

Reunin que incluye desarrolladores, usuarios, cliente y cualquier persona que pueda contribuir con el descubrimiento de stories Los participantes escriben cuantas stories puedan, sin preocuparse con la prioridad

Uso de brainstorming y estandarizacin rpida, de baja fidelidad

Criterios de Aceptacin y Pruebas de Aceptacin

Criterios de Aceptacin
El Product Owner escribe los criterios de aceptacin para cada tem deseado antes del Sprint Planning Durante el Sprint Planning, los criterios de aceptacin son discutidos y negociados con el Equipo de Desarrollo. Enunciados cortos y fciles de entender Definen los limites para un tem

Son especficos para cada tem, mientras que el DoD funciona para todos los tems de funcionalidades del Product Backlog

Criterios de Aceptacin
Ayudan al P. P. a responder lo que sea necesario para que esa funcionalidad propicie valor Ayudan al Equipo de Desarrollo a ganar una comprensin compartida sobre la Story/funcionalidad Ayudan a los programadores/testers a generar las pruebas Ayudan a los programadores a saber cuando deben parar de agregar ms funcionalidades a una story

Adaptado de un artculo de Sandy Mamoli

Criterios de Aceptacin
Como comprador de libros, quiero poder usar mi tarjeta de crdito para pagar los libros elegidos, teniendo practicidad y seguridad en el pago

Los campos obligatorios del formulario de pago deben estar claramente indicados

Slo debe aceptar las tarjetas de crdito aceptadas por nuestro sistema
Slo debe aceptar tarjetas de crdito con fecha de validez vigente

Criterios de Aceptacin
Sirven para verificar que las funcionalidades (user stories) implementadas funcionan como el cliente solicit Son el tercer C de las user stories (confirmacin) Son definidos a partir de ejemplos suministrados por el cliente Esos ejemplos son aplicados a los Criterios de Aceptacin del tem al formular las Pruebas de Aceptacin

Pruebas de Aceptacin
Como comprador de libros, quiero poder usar mi tarjeta de crdito para pagar los libros elegidos, teniendo practicidad y seguridad en el pago
Verificar si los campos nombre, direccin, nmero de la tarjeta, marca y fecha de vencimiento estn claramente indicados Probar con una tarjeta Visa (nuestro sistema debe aceptar Visa)
Luz verde si la acepta Luz roja si no la acepta !se debe corregir!

Probar con una tarjeta Amex (nuestro sistema no debe aceptar tarjetas Amex)
Luz verde si no la acepta Luz roja si la acepta !se debe corregir!

Probar con la fecha 01/01/2000 (fecha invlida)

Luz verde si no la acepta Luz roja si la acepta !se debe corregir!

Product Backlog

Qu es el Product Backlog?
Lista de requisitos del producto tems con deseos de negocios del cliente, mejoras en el producto, correcciones de bugs, tareas tcnicas etc. Medio para alcanzar la visin del producto tems ordenados por prioridad de desarrollo tems de arriba: < granularidad, > detalle tems de abajo: > granularidad, < detalle Lista incompleta y dinmica en constante evolucin el ambiente evoluciona, los clientes y el Equipo de Desarrollo aprenden sobre el producto

Qu es el Product Backlog?
El Product Owner es el nico responsable por administrar el Product Backlog actualizar, ordenar y dar visibilidad Sus tems pueden poseer descripcin y estimativa El ordenamiento es realizado tratando de maximizar el ROI del proyecto influenciada por el valor que generar al cliente, riesgo y necesidad

Qu es el Product Backlog?

El Product Backlog es...

Ordenado: los tems estn ordenados de acuerdo con la prioridad de su implementacin tratando de maximizar el ROI do cliente Estimable: juzgar y crear una opinin sobre el tamao del Product Backlog o de una parte relevante del mismo (por ejemplo: prximo Sprint o Release) Emergente: incompleto, dinmico, en constante evolucin cambio en el ambiente y en el producto Gradualmente refinado: de acuerdo con el ordenamiento

El Product Backlog es Ordenado

Desarrollado ms temprano Ms detalle

Prximo Sprint

Este Release

Desarrollado ms tarde (posiblemente)

Menos detalle

Futuros Releases

El Product Backlog es Gradualmente Refinado

Cul de estos Product Backlog es el mejor?

(I)

(II)

(III)

Observaciones: menor y ms detallado, mayor granularidad

Definicin de Terminado (Done)

Definicin de Terminado (DoD) = contrato o acuerdo entre el Product Owner y el Equipo de Desarrollo sobre lo que significa cuando el Equipo de Desarrollo dice que un tem est terminado Cuando alguien dice que algo est terminado, todos deben entender lo qu significa! Establecido al inicio, puede evolucionar a lo largo del proyecto Por ejemplo: terminado = software codificado, con pruebas unitarias y de aceptacin automatizadas y la parte del manual del usuario correspondiente actualizada

Product Backlog Grooming

El Product constantes Backlog necesita atencin y cuidados

El Grooming es un proceso que asegura que el Product Backlog sea Ordenado, Estimable, Emergente y Gradualmente Refinado prerrequisito para un Sprint Planning bien realizado Hecho en colaboracin entre el Product Owner y el Equipo de Desarrollo (El Equipo generalmente dedica 10% de su tiempo) Cada Equipo de Scrum tiene su propio proceso de grooming: sesiones diarias cortas, sesiones semanales, workshop etc.

por Roman Pichler

Product Backlog Grooming

Pasos del Grooming: Descubrir y describir nuevos tems; modificar o retirar los existentes Ordenar alto: ms importante bajo: menos importante; qu tems en el prximo release, orden de implementacin

tems de alta prioridad preparados (DoR): decompuestos y refinados; claros: entendimiento comn; factibles: lo suficientemente pequeos para el sprint; probables: verificables El Equipo de Desarrollo estima los nuevos tems y corrige los antiguos
por Roman Pichler

Definicin de Preparado (ready)

Definicin de Preparado (DoR) = contrato o acuerdo entre el Product Owner y el Equipo de Desarrollo sobre el estado en que cada tem del Product Backlog debe estar para calificarse para ser discutido en el Sprint Planning Preparado = tem disponible y preparado para discusin por el Product Owner en el Sprint Planning Objetivo claro para el Equipo de Desarrollo, previene desperdiciar el Sprint Qu, cmo, estimado, lo suficientemente pequeo

por Jeff Sutherland / Serge Beaumont

Estimando tems del Product Backlog

Estimando tems del Product Backlog

Estimar ayuda a planificar!
Estimar ayuda al Equipo de Desarrollo a conocer su velocidad y ser capaz de comprometerse con los tems
Estimar ayuda al Product Owner a crear el Plan de Release, basado en la velocidad del Equipo de Desarrollo Estimar ayuda a medir el progreso en una release usando el Release Burndown

Estimaciones hechas por el Equipo de Desarrollo!

Estimando tems del Product Backlog

Exactitud es ms importante que precisin!
Precisin

Exactitud

Estimando tems del Product Backlog

Story Points

Unidad de medida para determinar el tamao del tem del Product Backlog (generalmente User Stories)
Los Story points representan el tamao del esfuerzo relativo necesario para desarrollar el tem Es una medida relativa (entre os tems) Fibonacci: 0, 1, 2, 3, 5, 8, 13, 21, 34... (o adaptado: 0, 1, 2, 3, 5, 8, 13, 20, 40...)

Estimando tems del Product Backlog

Una de las tcnicas para realizar la estimacin del Product Backlog es el PLANNING POKER

8
STORY POINTS Inicialmente, el Equipo de Desarrollo escoge el tem de menor esfuerzo y le atribuye el tamao 2 El Equipo de Desarrollo escoge un tem y juega el Planning Poker para estimarlo, usando como base el tem de tamao 2 El Equipo de Desarrollo escoge otro tem y juega el Planning Poker para estimarlo, usando como base los tems ya estimados triangulacin

Estimando tems del Product Backlog

Jugando al PLANNING POKER

13
Para un tem, todos los miembros del Equipo de Desarrollo escogen una estimacin en las cartas no se debe mostrar hasta que todos hayan escogido Todos muestran las cartas al mismo tiempo Los miembros con la mayor y la menor estimacin deben justificar y debatir

Se tiran nuevamente las cartas hasta llegar a un consenso El ScrumMaster facilita!

Estimando tems del Product Backlog

T-Shirt Sizing

GG

Midiendo la Velocidad del Equipo de Desarrollo

La velocidad del Equipo de Desarrollo es la media de story points entregada por el Equipo en sus ltimos Sprints Se usa para ayudar al Equipo de Desarrollo a decidir cuntos puntos usar en la planificacin del Sprint s una medida relativa para cada Equipo de Desarrollo, o sea, no puede ser usada para comparar diferentes Equipos Cuanto ms constante sea la formacin del Equipo de Desarrollo y la duracin de los Sprints, mejor funciona

Gestin de Releases

 Qu es un Release?
Es la entrega al cliente de un incremento en el producto

Debe ser decidido por el Product Owner, de acuerdo con las necesidades del cliente
El Release slo puede ser realizado cuando hayan sido realizados tantos incrementos en el producto que puedan generar valor para el cliente

Release 1 Sprint 1 Sprint 2 Sprint 3 Sprint 4

Release 2 Sprint 5 Sprint 6 Sprint 7

Gestin de Release
Escenario de Release
Release por Sprint: release a cada Sprint
Release por tem: continuous delivery Release por valor: El P. P. decide el Release cuando hayan sido creados incrementos suficientes para que el Producto sea de valor para el cliente Release por Plan: reunin de Release Planning y Plan de Release Regla general: haga Releases tan pronto quanto sea possible y con frecuencia

Gestin de Release
Escenario Release por Plan

Los tems del Product Backlog deben ser estimados por el Equipo de Desarrollo y ordenados por el Product Owner
En cada Release se debe realizar la reunin de Release Planning Meeting para crear el Plan de Release Hacer releases tan pronto quanto sea possible y con frecuencia Acompaar el progreso a travs del Release Burndown Actualizar el Plan de Release a cada Sprint

Reunin de Release Planning

Reunin para crear el Plan de Release de un Release
Meta del Release: camino para la Visin del Producto Fecha de entrega tems ordenados del Product Backlog que, inicialmente, sern entregados en los Sprints del Release No es un compromiso Vea que tems caben en el Release usando el nmero calculado de Sprints, estimativas no refinadas del Equipo de Desarrollo para los tems y la velocidad del Equipo No distribuya los tems por las Sprints (quizs por los 2 primeros, pero no sustituye el Sprint Planning!)

Trazando el Release Burndown

El Release Burndown es un grfico que muestra trabajo restante estimado del Release en el tiempo el

Y: trabajo estimado restante

puntos estimados restantes de los tems (story points) () suma de los valores restantes correspondientes a P, M, G, GG (por ejemplo: 2, 4, 8, 16) () nmero de tems restantes

X: tiempo
Iteraciones (Sprints)

Sirve para acompaar el progreso en direccin a una entrega

Es realizado inicialmente en la reunin de Release Planning y debe ser actualizado al final de cada Sprint

Trazando el Release Burndown

El Ciclo de Scrum

Sprint Planning Meeting

Qu es el Sprint Planning Meeting?

Planificacin de la iteracin: El Equipo de Desarrollo y el Product Owner definen los tems del Product Backlog que sern implementados en el Sprint y los dividen en tareas Sprint Backlog Reunin de 8 h (Sprints de 1 mes) o 5% del Sprint 1a. Parte: Qu? Seleccin de los tems ms prioritarios del Product Backlog que sern implementados Definicin de el Objetivo del Sprint El Product Owner debe estar presente 2a. Parte: Como? El Equipo de Desarrollo divide los tems en tareas y estima el tiempo (cuando se utiliza) para la realizacin de cada tarea

Qu es el Sprint Planning Meeting?

Resultado: Sprint Backlog inicial + Objetivo
Tareas a realizar Tareas en realizacin

tems

Listo

Meta

Sprint Backlog

Qu es el Sprint Backlog?
Est formado por una lista de los tems que sern desarrollados durante el Sprint, las tareas correspondientes, su evolucin y las estimaciones Los tems son seleccionados del Product Backlog en el Sprint Planning Meeting Cada tem es dividido en tareas. Parte de las tareas es definida en el Planning y parte a lo largo del Sprint

Qu es el Sprint Backlog?
Las tareas pueden ser estimadas o no, pero debe ser trazado el Sprint Burndown El Sprint Backlog es modificado a lo largo del Sprint
las estimaciones (cuando las hay) son actualizadas las tareas pueden surgir para los tems ya existentes

Debe haber alta visibilidad Pertenece al Equipo de Desarrollo

Estimando las Tareas

En la segunda parte del Sprint Planning, los miembros del Equipo de Desarrollo estiman las tareas del Sprint Backlog Estimacin por horas: nmero de horas previstas para desarrollar la tarea Estimacin T-Shirt Sizing: P, M, G, GG Algunos Equipos de Desarrollo no estiman sus tareas De preferencia, cada tarea es < 1 da y > 2 horas Las estimaciones deben ser actualizadas siempre que sea pertinente

Trazando el Sprint Burndown

El Sprint Burndown es un grfico que muestra el trabajo restante estimado para las tareas del Sprint Backlog en el tiempo Y: trabajo restante estimado para las tareas
suma de las horas estimadas restantes de las tareas () suma de los valores restantes correspondientes a P, M, G, GG (por ejemplo: 2, 4 ,8, 16) () nmero de tareas restantes

X: tiempo
Das del Sprint

Sirve para acompaar el progreso de un sprint Inicialmente, es realizado en el Sprint Planning Meeting y debe ser actualizado a cada da del Sprint

Trazando el Sprint Burndown

Sprint

Qu es el Sprint?
El Sprint es la iteracin (ciclo) de desarrollo Sprint Planning Meeting Trabajo de Desarrollo Sprint Review Sprint Retrospective Cada Sprint debe contar con una meta de negocios Tienen duracin fija (de 1-2 semanas a 1 mes) y ocurren uno atrs del otro No debe haber ningn cambio que afecte el Objetivo del Sprint

Qu es el Sprint?
Cada Sprint debe tener como resultado un incremento entregable del producto que satisfaga el objetivo del Sprint Al final del Sprint, un trabajo entregable debe estar terminado

El deadline no puede ser cambiado. Slo puede variar su alcance (siempre que no afecte el objetivo del Sprint)
Durante el Sprint, el P. P. debe estar disponible para el Equipo de Desarrollo

Cancelacin del Sprint

El Sprint puede ser cancelado si la Meta del Sprint pierde el sentido Slo el Product Owner puede decidir sobre la cancelacin del Sprint Pero es una excepcin, debe ocurrir raramente Los tems listos (done) son revisados y pueden ser aceptados. Inmediatamente, se inicia un nuevo Sprint

El Tamao del Sprint

El tamao del Sprint es fijo! (1-4 semanas) Slo puede ser modificado si es detectada la necesidad en el Sprint Retrospective Horizonte suficientemente corto para que los cambios necesarios no modifiquen la meta del Sprint Sprints cortos: cambios muy frecuentes, entregas ms frecuentes, proyectos cortos Sprints largos: cambios menos frecuentes, overhead de reuniones

Daily Scrum

Qu es el Daily Scrum?
Reunin de 15 minutos realizada todos los das en el mismo lugar, a la misma hora. Visibilidad Comunicacin Decisin rpida Cada miembro del Equipo de Desarrollo detalla: Lo que complet desde el ltimo Daily Scrum; Lo que va a hacer antes del prximo Daily Scrum; Qu obstculos hay en su camino. El ScrumMaster debe ocuparse de los obstculos, pero tiene que ser inmediatamente informado !no en el Daily Scrum! Es un buen momento para actualizar el Sprint Burndown!

Sprint Review

Qu es el Sprint Review?
Reunin informal en que el Equipo de Desarrollo muestra al Product Owner y a los stakeholders lo que fue hecho durante el Sprint Reunin de 4 h (Sprints de 1 mes) o 5% del Sprint El Product Owner debe estar presente El Equipo de Desarrollo demuestra lo que hizo y responde las preguntas !focalizando el incremento del producto! El PP verifica lo que fue y lo que no fue hecho en el Sprint y establece si el objetivo fue cumplido Entrada al Product Backlog - adaptacin

Sprint Retrospective

Qu es el Sprint Retrospective?
Reunin para fiscalizar como se desarroll el Sprint con relacin a los procesos: Reunin de 3h En general, el Product Owner debe estar presente Identificar y priorizar:

Qu fue lo que estuvo bien?

Qu se puede mejorar? Se deben Identificar las acciones de mejora - adaptacin

Qu es el Sprint Retrospective?
Cinco pasos:
Preparacin
Recolectar datos Generar insights Decidir qu hacer Terminar la retrospectiva

Qu es el Sprint Retrospective?

Qu estuvo bien?

Qu se puede mejorar?

Acciones para la mejora

Qu es el Sprint Retrospective?

Escalando Scrum

Escalando Scrum
Problema: proyecto muy grande El Equipo de Desarrollo debe contar con, como mximo, 9 miembros

Escalando Scrum
Solucin: diversos Equipos de Desarrollo en el mismo proyecto

Escalando Scrum
Scrum of Scrums

Mecanismo para la coordinacin de varios Equipos de Desarrollo trabajando en el mismo proyecto

Daily Scrum adicional (Daily Scrum of Scrums), formado por un miembro de cada Equipo de Desarrollo del mismo proyecto (!no puede ser el ScrumMaster!), tratando de sincronizar el trabajo de todos los Equipos de Desarrollo y tratar los problemas Focalizado en dependencias, integracin y sobreposiciones de trabajo

Escalando Scrum
Scrum of Scrums El mismo Product Backlog para todos los Equipos de Desarrollo Funciona cuando no hay grandes dependencias entre el trabajo de los Equipos de Desarrollo Minimizar dependencias, ortogonalizar el trabajo de los Equipos Cuestiones: Qu hizo el Equipo desde la ltima reunin? Qu pretende hacer el Equipo hasta la prxima reunin? Qu complic la actuacin del Equipo? El Equipo generar impedimentos para otros Equipos?

Scrum Alliance
http://www.scrumalliance.org

Scrum Alliance

Certificaciones de Scrum Alliance

Gracias!

Rafael Sabbagh
sabbagh@gmail.com rsabbagh http://rsabbagh.com http://facebook.com/SabbaghTC