• Author / Uploaded
• juan992276377

Citation preview

Certified ScrumMaster Gestión Á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... • Década del 50: la gestión de proyectos es reconocida como materia, nacida de la administración • Henri Fayol: • Su trabajo es la base de la gestión tradicional de proyectos • El gerente posee 5 funciones básicas:

Planificar Planear

Organizar Comandar

Controlar

Coordinar

• Hasta entonces, la gestión de proyectos trataba de grandes proyectos de ingeniería y construcción civil.

Un poco de historia... • Década del 60: el desarrollo de software empieza a ganar complejidad • Proyectos de software: el uso de metodologías tradicionales empieza a ser aplicado a proyectos de ingeniería y construcción 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 artículo, donde critica el abordaje tradicional en el desarrollo de softwares

Waterfall

Un poco de historia … BDUF Big Design Up Front

• Waterfall usa BDUF! • “La Revisión exhaustiva de la especificación puede garantizar la ausencia de cambios críticos en la fase de ejecución”

• Es adecuado sólo para proyectos estables, con poco o ningún 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 sólo saben exactamente lo que quieren después de ver una versión inicial del producto; • Los requisitos cambian durante el proceso de desarrollo; • Nuevas herramientas y tecnologías vuelven imprevisible la estrategia de desarrollo

Agilidad

Agilidad

2001: representantes de procesos de desarrollo de software se reunieron para discutir sobre lo que poseían en común 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 tardías 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 más 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 ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación 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 atención continua a la excelencia técnica y al buen diseño 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 diseños emergen de equipos auto-organizados. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación 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! • Sólo produce lo que el cliente realmente usará • Planifica solo lo suficiente y necesario, con el nivel de detalle adecuado • Sólo genera los artefactos necesarios y suficientes (por ejemplo: documentación)

¿Por qué Scrum? • Transparencia • El Cliente acompaña 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 • Interacción y comunicación 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

• Inspección y adaptación para la mejora continua del producto

• Inspección y adaptación para la mejora continua del trabajo del Equipo de Desarrollo

Nivel de Detalle de la Planificación

Uso de Funcionalidades por el Cliente Uso de Funcionalidades por el Cliente

Siempre Frecuentemente 7%

A veces 13%

Raramente

45% 16%

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 técnica: dentro de Scrum se pueden emplear varios procesos y técnicas;

• ...utiliza el abordaje iterativo e incremental para mejorar la previsibilidad y la gestión de riesgos;

Scrum...

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

cliente,

• ...vuelve los problemas de las prácticas de desarrollo transparentes, para que se puedan mejorar;

• ...utiliza inspección y adaptación 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 Orígenes de Scrum

Scrum: Orígenes • Ken Schwaber, inicio de los años 90: desarrollo en su empresa de lo que se volvería Scrum • Jeff Suttherland, 1993: desarrollo del Scrum en Easel Corporation • Ken Schwaber : formalización de Scrum en la OOPSLA’95 • Años siguientes: Schwaber y Sutherland colaboran para unificar sus trabajos

• Publicación del libro “Agile Software Development with Scrum”, por Ken Schwaber y Mike Beedle

Scrum: Orígenes “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 múltiple Control sutil Transferencia organizacional de aprendizaje

Scrum: Orígenes “The New New Product Development Game”, de Takeuchi y Nonaka (1986)

¡El nombre

Scrum viene del Rugby!

Scrum: Orígenes • Sistema Toyota de Producción y Producción sin Excesos • Producción “orientada” por el cliente • Producción 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 producción

Los Pilares de Scrum

Los Pilares de Scrum Procesos Definidos vs. Procesos Empíricos • Procesos definidos: • Ambientes controlados • Por ejemplo: líneas de producción

• Mismas entradas, mismas salidas

• Procesos empíricos: • Complejos e imprevisibles • Diferentes entradas, diferentes salidas

• Scrum se basa en la Teoría de Control de Procesos Empíricos

Los Pilares de Scrum • #1: Transparencia: ver y entender

• #2 Inspección: investigar

• #3 Adaptación: mejorar

Introducción 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 prácticas y reglas de Scrum están siendo comprendidos y seguidos

El Ciclo de Scrum

Resumen del Ciclo de Scrum LA VISIÓN 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 continuación, incluye esos requisitos en una lista ordenada, llamada PRODUCT BACKLOG

Resumen del Ciclo de Scrum El Product Owner y el Equipo de Desarrollo se reúnen en el SPRINT PLANNING MEETING y generan el SPRINT BACKLOG: qué será realizado y cómo 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é? ¿Cuáles fueron los impedimentos?

A diario, el Equipo de Desarrollo realiza la DAILY SCRUM, una reunión de 15 minutos para promover visibilidad y comunicación entre los miembros del Equipo

Resumen del Ciclo del Scrum DEFINICIÓN 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 reúne 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 continuación, el Equipo de Scrum se reúne en la SPRINT RETROSPECTIVE, donde verifica lo que funcionó bien y lo que puede ser mejorado en los próximos 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, prácticas 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 relación con el P. O. • Enseña Scrum al Equipo de Desarrollo y cómo 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, prácticas y reglas • Alinea las necesidades del Equipo de Desarrollo y las de la organización • Puede ayudar a seleccionar el P. O. • Garantiza que el P. O. posee todo lo que precisa para saber realizar su trabajo

ScrumMaster: Características • Competente en soft skills: facilitador, negociador, comunicador, gestión 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 Visión 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: Características • Único (¡sólo 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 rápidas 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 dirección a la visión del producto • Entrega valor frecuentemente al cliente

• Se auto-organiza para realizar el trabajo • poder suficiente para administrar su trabajo, responsable por sus resultados • comunicación: los mejores equipos son pequeños (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: Características • Multidisciplinario • todo el conocimiento y las habilidades necesarias para realizar el trabajo “terminado”(DoD), incluyendo calidad • Feature Teams • No hay títulos en el Equipo de Desarrollo. • Fertilización cruzada: uno aprendiendo del otro

• Suficientemente pequeño (7 ± 2) para garantizar la comunicación • Motivado, con la confianza y apoyo necesarios • Buscando la excelencia técnica

• 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

¿Quién?

Como un , yo puedo/me gustaría/debo para

¿Qué? 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… • … guían el Equipo de Desarrollo con enunciados concisos y directo al punto • … ayudan a mantener los ítems del Product Backlog alineados con la Visión del Producto • … llevan el P. P./clientes a una profunda reflexión 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 (conversación) Conversaciones sobre la story, a través de las cuales, de hecho, el requisito es comunicado por el cliente a los programadores

CONFIRMATION (confirmación) Pruebas que documentan los detalles de la story y pueden ser usadas para determinar cuándo está terminada

User Stories: INVEST

Una User Story debe ser:

Independent Negotiable Valuable Estimable Small Testable

Independiente de las otras stories Negociable, detalles serán negociados Valiosa para el cliente Estimable por los desarrolladores Pequeña en esfuerzo de implementación Comprobable para permitir su confirmación

User Stories: Stories, Temas y Epics STORY STORY

STORY

ÉPICA

STORY

STORY

STORY

TEMA STORY STORY

STORY STORY

STORY

STORY

STORY

STORY

User Stories: Story-Writing Workshop • Reunión 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 estandarización rápida, de baja fidelidad

Criterios de Aceptación y Pruebas de Aceptación

Criterios de Aceptación • El Product Owner escribe los criterios de aceptación para cada ítem deseado antes del Sprint Planning • Durante el Sprint Planning, los criterios de aceptación son discutidos y negociados con el Equipo de Desarrollo. • Enunciados cortos y fáciles de entender • Definen los limites para un ítem

• Son específicos para cada ítem, mientras que el DoD funciona para todos los ítems de funcionalidades del Product Backlog

Criterios de Aceptación • Ayudan al P. P. a responder lo que sea necesario para que esa funcionalidad propicie valor • Ayudan al Equipo de Desarrollo a ganar una comprensión 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 más funcionalidades a una story

Adaptado de un artículo de Sandy Mamoli

Criterios de Aceptación Como comprador de libros, quiero poder usar mi tarjeta de crédito para pagar los libros elegidos, teniendo practicidad y seguridad en el pago

• Los campos obligatorios del formulario de pago deben estar claramente indicados

• Sólo debe aceptar las tarjetas de crédito aceptadas por nuestro sistema • Sólo debe aceptar tarjetas de crédito con fecha de validez vigente …

Criterios de Aceptación • Sirven para verificar que las funcionalidades (user stories) implementadas funcionan como el cliente solicitó • Son el tercer C de las user stories (“confirmación”) • Son definidos a partir de ejemplos suministrados por el cliente • Esos ejemplos son aplicados a los Criterios de Aceptación del ítem al formular las Pruebas de Aceptación

Pruebas de Aceptación Como comprador de libros, quiero poder usar mi tarjeta de crédito para pagar los libros elegidos, teniendo practicidad y seguridad en el pago • Verificar si los campos “nombre”, “dirección”, “número de la tarjeta”, “marca” y “fecha de vencimiento” están 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 inválida) •

• • …

● 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 técnicas etc. • Medio para alcanzar la visión del producto • Ítems ordenados por prioridad de desarrollo • ítems de arriba: < granularidad, > detalle • ítems de abajo: > granularidad, < detalle • Lista incompleta y dinámica en constante evolución – 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 descripción 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 están ordenados de acuerdo con la prioridad de su implementación – tratando de maximizar el ROI do cliente • Estimable: juzgar y crear una opinión sobre el tamaño del Product Backlog o de una parte relevante del mismo (por ejemplo: próximo Sprint o Release) • Emergente: incompleto, dinámico, en constante evolución – cambio en el ambiente y en el producto • Gradualmente refinado: de acuerdo con el ordenamiento

El Product Backlog es Ordenado Desarrollado más temprano Más detalle

Próximo Sprint

Este Release

Desarrollado más tarde (posiblemente) Menos detalle

Futuros Releases

El Product Backlog es Gradualmente Refinado ¿Cuál de estos Product Backlog es el mejor?

(I)

(II)

(III)

Observaciones: menor y más detallado, mayor granularidad

Definición de Terminado (“Done”) • Definición 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 aceptación automatizadas y la parte del manual del usuario correspondiente actualizada

Product Backlog Grooming • El Product constantes

Backlog

necesita

atención

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 colaboración 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: más importante  bajo: menos importante; qué ítems en el próximo release, orden de implementación

• Ítems de alta prioridad preparados (DoR): decompuestos y refinados; claros: entendimiento común; factibles: lo suficientemente pequeños para el sprint; probables: verificables • El Equipo de Desarrollo estima los nuevos ítems y corrige los antiguos por Roman Pichler

Definición de Preparado (“ready”) • Definición 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 discusión por el Product Owner en el Sprint Planning • Objetivo claro para el Equipo de Desarrollo, previene “desperdiciar” el Sprint • Qué, cómo, estimado, lo suficientemente pequeño

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 más importante que precisión! Precisión

Exactitud

Estimando Ítems del Product Backlog • Story Points

• Unidad de medida para determinar el tamaño del ítem del Product Backlog (generalmente User Stories) • Los Story points representan el tamaño 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 técnicas para realizar la estimación 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 tamaño 2

•

El Equipo de Desarrollo escoge un ítem y juega el Planning Poker para estimarlo, usando como base el ítem de tamaño 2

•

El Equipo de Desarrollo escoge otro ítem y juega el Planning Poker para estimarlo, usando como base los ítems ya estimados triangulación

Estimando Ítems del Product Backlog Jugando al PLANNING POKER

13 •

Para un ítem, todos los miembros del Equipo de Desarrollo escogen una estimación 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 estimación deben justificar y debatir

•

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

2

Estimando Ítems del Product Backlog

•T-Shirt Sizing

P

M

G

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 cuántos puntos usará en la planificación del Sprint • És una medida relativa para cada Equipo de Desarrollo, o sea, no puede ser usada para comparar diferentes Equipos • Cuanto más constante sea la formación del Equipo de Desarrollo y la duración de los Sprints, mejor funciona

Gestión 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 sólo puede ser realizado cuando hayan sido realizados tantos incrementos en el producto que puedan generar valor para el cliente

Release 2…

Release 1 Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Sprint 7

S

Gestión 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: reunión de Release Planning y Plan de Release Regla general: haga Releases tan pronto quanto sea possible y con frecuencia

Gestión 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 reunión de Release Planning Meeting para crear el Plan de Release • Hacer releases tan pronto quanto sea possible y con frecuencia • Acompañar el progreso a través del Release Burndown • Actualizar el Plan de Release a cada Sprint

Reunión de Release Planning • Reunión para crear el Plan de Release de un Release • Meta del Release: camino para la Visión del Producto • Fecha de entrega • Ítems ordenados del Product Backlog que, inicialmente, serán entregados en los Sprints del Release • No es un compromiso • Vea que ítems caben en el Release usando el número 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 (quizás por los 2 primeros, ¡pero no sustituye el Sprint Planning!)

Trazando el Release Burndown • El Release Burndown es un gráfico 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) • (Ó) número de ítems restantes

• X: tiempo • Iteraciones (Sprints)

• Sirve para acompañar el progreso en dirección a una entrega

• Es realizado inicialmente en la reunión 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? • Planificación de la iteración: • El Equipo de Desarrollo y el Product Owner definen los ítems del Product Backlog que serán implementados en el Sprint y los dividen en tareas – Sprint Backlog • Reunión de 8 h (Sprints de 1 mes) o 5% del Sprint • 1a. Parte: ¿Qué? • Selección de los ítems más prioritarios del Product Backlog que serán implementados • Definición 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 realización de cada tarea

¿Qué es el Sprint Planning Meeting? • Resultado: Sprint Backlog inicial + Objetivo

Ítems

Tareas a realizar

Tareas en realización

Listo

Meta

Sprint Backlog

¿Qué es el Sprint Backlog? • Está formado por una lista de los ítems que serán desarrollados durante el Sprint, las tareas correspondientes, su evolución 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 • Estimación por horas: número de horas previstas para desarrollar la tarea • Estimación T-Shirt Sizing: P, M, G, GG • Algunos Equipos de Desarrollo no estiman sus tareas • De preferencia, cada tarea es < 1 día y > 2 horas • Las estimaciones deben ser actualizadas siempre que sea pertinente

Trazando el Sprint Burndown • El Sprint Burndown es un gráfico 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) • (Ó) número de tareas restantes

• X: tiempo • Días del Sprint

• Sirve para acompañar el progreso de un sprint • Inicialmente, es realizado en el Sprint Planning Meeting y debe ser actualizado a cada día del Sprint

Trazando el Sprint Burndown

Sprint

¿Qué es el Sprint? • El Sprint es la iteración (ciclo) de desarrollo • Sprint Planning Meeting • Trabajo de Desarrollo • Sprint Review • Sprint Retrospective • Cada Sprint debe contar con una meta de negocios • Tienen duración fija (de 1-2 semanas a 1 mes) y ocurren uno atrás del otro • No debe haber ningún 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. Sólo 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

Cancelación del Sprint • El Sprint puede ser cancelado si la Meta del Sprint pierde el sentido • Sólo el Product Owner puede decidir sobre la cancelación del Sprint • Pero es una excepción, debe ocurrir raramente • Los ítems listos (“done”) son revisados y pueden ser aceptados. Inmediatamente, se inicia un nuevo Sprint

El Tamaño del Sprint • ¡El tamaño del Sprint es fijo! (1-4 semanas) Sólo 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 más frecuentes, proyectos cortos • Sprints largos: cambios menos frecuentes, overhead de reuniones

Daily Scrum

¿Qué es el Daily Scrum? • Reunión de 15 minutos realizada todos los días en el mismo lugar, a la misma hora. • Visibilidad • Comunicación • Decisión rápida • Cada miembro del Equipo de Desarrollo detalla: • Lo que completó desde el último Daily Scrum; • Lo que va a hacer antes del próximo Daily Scrum; • Qué obstáculos hay en su camino. • El ScrumMaster debe ocuparse de los obstáculos, 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? • Reunión informal en que el Equipo de Desarrollo muestra al Product Owner y a los stakeholders lo que fue hecho durante el Sprint • Reunión 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 - adaptación

Sprint Retrospective

¿Qué es el Sprint Retrospective? • Reunión para fiscalizar como se desarrolló el Sprint con relación a los procesos: • Reunión 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 mejoría - adaptación

¿Qué es el Sprint Retrospective? • Cinco pasos: • Preparación • 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 máximo, 9 miembros

?

Escalando Scrum • Solución: diversos Equipos de Desarrollo en el mismo proyecto

Escalando Scrum • Scrum of Scrums

• Mecanismo para la coordinación 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, integración 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 reunión? • ¿Qué pretende hacer el Equipo hasta la próxima reunión? • ¿Qué complicó la actuación del Equipo? • ¿El Equipo generará impedimentos para otros Equipos?

Scrum Alliance http://www.scrumalliance.org

Scrum Alliance

Certificaciones de Scrum Alliance

¡Gracias!

Rafael Sabbagh [email protected] rsabbagh http://rsabbagh.com http://facebook.com/SabbaghTC