• Author / Uploaded
• Luis Rodrigo Arauz

Citation preview

Gestión de proyectos con SCRUM

Alex Ballarín Barcelona, Septiembre 2015

V14 – Grup Oct. 2015

Framework de desarrollo de producto

Gestión de proyectos SCRUM – Clase 1 Metodologías ágiles vs tradicionales Fundamentos de Scrum Roles de Scrum Eventos de Scrum Artefactos de Scrum Escalando Agile Agilidad disciplinada: DAD Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

1 2 3 4 5 6 7

2

Gestión de proyectos SCRUM – Clase 1 Metodologías ágiles vs tradicionales Fundamentos de Scrum Roles de Scrum Eventos de Scrum Artefactos de Scrum Escalando Agile Agilidad disciplinada: DAD Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

1 2 3 4 5 6 7

3

1. Metodologías ágiles vs tradicionales Metodologías: una clasificación Centralizado (Command & Control)

Definido Predictivo

¿?

Según su ciclo de vida y organización

Metodologías iterativas Adaptativo Iterativo Metodologías ágiles V14 – Grup Oct. 2015

Metodologías tradicionales

2 3 4 5 6 7

Descentralizado (Autoorganización) Curso Scrum – S1: Scrum Master

4

1. Metodologías ágiles vs tradicionales Ciclos de vida

2 3 4 5 6 7

 Cascada (waterfall) » Simple y fácil de entender » Aproximación “disciplinada” × Definición exhaustiva del trabajo × Revisión sistemática en hitos × Énfasis en control y documentación

» Desafío: Big Design Up Front (BDUF) » Cambios más caros cuanto más tarde se descubren » Riesgo para cliente y proveedor

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

× Seguimiento sobre calendario engañoso: “Efecto 90%” × Validación al final del proyecto: funcionalidades y arquitectura × Fomenta la “deuda técnica”

5

1. Metodologías ágiles vs tradicionales Ciclos de vida

2 3 4 5 6 7

V14 – Grup Oct. 2015

 Systems Development Life Cycle (elaboración de Cascada)

Curso Scrum – S1: Scrum Master

6

1. Metodologías ágiles vs tradicionales El triangulo de acero

2 3 4 5 6 7

 Grados de libertad para planificar un proyecto Alcance (Requisitos)

Curso Scrum – S1: Scrum Master

Presupuesto (Equipo)

V14 – Grup Oct. 2015

Tiempo (Calendario)

Calidad

7

1. Metodologías ágiles vs tradicionales Ciclos de vida

2 3 4 5 6 7

 V-Model

Diagrama realizado por Gemma Grau

Curso Scrum – S1: Scrum Master

8

V14 – Grup Oct. 2015

» Permite validar cada actividad de requisitos y diseño con sus pruebas correspondientes » Permite trabajar en paralelo a diferentes roles del equipo » El “feedback” del cliente llega antes » Avance más seguro, las pruebas detectan menos “sorpresas”

1. Metodologías ágiles vs tradicionales Ciclos de vida

2 3 4 5 6 7

 Iterativo o Espiral » Evita el “BDUP” (gran diseño inicial) » Permite obtener antes el feedback del cliente » Se evita el riesgo de fallo × Se prueban antes las funciones más dudosas × Se prueba antes las tecnologías más complejas

» Entrega antes las partes del producto al cliente

V14 – Grup Oct. 2015

× Menos riesgo (aprendizaje, descubrir cambios...) × El cliente disfruta antes del beneficio del producto (especialmente en proyectos largos)

Curso Scrum – S1: Scrum Master

9

1. Metodologías ágiles vs tradicionales Agile Manifesto

2 3 4 5 6 7

 12 Principios Customer satisfaction by rapid delivery of useful software Welcome changing requirements, even late in development Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Close, daily co-operation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

» » » » » » » » » » » »

10

1. Metodologías ágiles vs tradicionales Algunas metodologías

Scrum (1995)

RUP (1996)

DevOps (2009) Extreme Programming (1999)

Agile Manifesto (2001)

DAD (2011)

Spiral (1986)

50

60

70

80

90

2000

10 V14 – Grup Oct. 2015

Toyota Production System (1950)

2 3 4 5 6 7

V-Model (1982) Waterfall (1956)

PMBOK (1996)

Curso Scrum – S1: Scrum Master

PRINCE2 (1996)

11

1. Metodologías ágiles vs tradicionales Extreme Programming (1999)

2 3 4 5 6 7

 Practices » Fine Scale Feedback × × × ×

Pair programming Planning game Test-driven development Whole team

» Continuous Process × Continuous integration × Refactoring × Small Releases

× × × ×

Coding Standards Collective Code Ownership Simple Design System Metaphor

V14 – Grup Oct. 2015

» Shared Understanding

Ver también Metas y Valores de XP

Curso Scrum – S1: Scrum Master

12

1. Metodologías ágiles vs tradicionales Disciplined Agile Delivery (2011)

2 3 4 5 6 7

 Agilidad híbrida  Cubre ciclo de vida completo de la solución

V14 – Grup Oct. 2015

» Scrum solo se ocupa de la “construcción” » Incluye contenido de Scrum, XP, Agile Modeling, OpenUP, etc...

Curso Scrum – S1: Scrum Master

13

1. Metodologías ágiles vs tradicionales 2 3 4 5 6 7 Problemas habituales de los proyectos “en cascada”  Falta de conocimiento del alcance y del contexto al hacer la oferta comercial » » » » »

Competencia fuerte El cliente confía en el proveedor El cliente no se implica Alcance, calendario y presupuesto posiblemente incorrectos Dada una estimación de esfuerzo, ¿con que probabilidad se cumplirá?

 El objetivo suele ser cumplir el plan de proyecto y especificación original, ¡no aquello que necesita el cliente! V14 – Grup Oct. 2015

» Los cambios en las fases finales son más costosos

 ¡ La deuda técnica se acaba pagando al final ! Curso Scrum – S1: Scrum Master

14

Gestión de proyectos SCRUM – Clase 1 Metodologías ágiles vs tradicionales Fundamentos de Scrum Roles de Scrum Eventos de Scrum Artefactos de Scrum Escalando Agile Agilidad disciplinada: DAD Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

1 2 3 4 5 6 7

15

V14 – Grup Oct. 2015

1 2. Fundamentos de Scrum 3 4 5 6 7 Tener compromiso y estar comprometido

Curso Scrum – S1: Scrum Master

16

1 2. Fundamentos de Scrum Proceso empírico vs definido

3 4 5 6 7

 Proceso definido

V14 – Grup Oct. 2015

» Todas las actividades y tareas deben entenderse previamente » Dadas unas entradas caracterizadas, las mismas salidas se obtienen en cada ejecución

Curso Scrum – S1: Scrum Master

17

1 2. Fundamentos de Scrum Proceso empírico vs definido

3 4 5 6 7

 Proceso empírico

V14 – Grup Oct. 2015

» El resultado de los procesos no está definido a priori. » El control del proceso no se realiza comparando las ejecuciones contra la definición del proceso. » El control del proceso se realiza mediante la inspección y adaptación del proceso en base a los resultados obtenidos. Además, se fomenta la transparencia para deducir las mejoras de manera compartida.

Curso Scrum – S1: Scrum Master

18

1 2. Fundamentos de Scrum ¿Cuando definido y cuando empírico?

3 4 5 6 7

V14 – Grup Oct. 2015

 Depende de la incertidumbre del proyecto

Curso Scrum – S1: Scrum Master

19

1 2. Fundamentos de Scrum 3 4 5 6 Scrum en 1 minuto: productos, roles y eventos Product Owner

Development Team

Scrum Master

Sprint

2 semanas

Backlog Producto: 800h

Backlog Sprint: 280h

V14 – Grup Oct. 2015

BACKLOG REFINEMENT

Capacidad del Sprint: 320h

Curso Scrum – S1: Scrum Master

20

1 2. Fundamentos de Scrum Roles de Scrum

3 4 5 6 7

 Development Team  Product Owner » Representa los intereses del cliente » Define los requisitos y marca las prioridades » Valida la implementación de los requisitos al final del sprint

 Scrum Master V14 – Grup Oct. 2015

» Se asegura que Scrum se adopta correctamente » No es jefe de proyecto ni se encarga de artefactos como el Burndown

 Scrum Team » La conjunción del Product Owner, Scrum Master y el Dev Team Curso Scrum – S1: Scrum Master

21

1 2. Fundamentos de Scrum Eventos (reuniones) de Scrum

3 4 5 6 7

 Sprint Planning » Refinar la estimación de las historias asignadas al Sprint » Comunicar el alcance de Sprint al Product Owner

 Scrum Diario » En el mismo sitio y lugar, 15 minutos como máximo y de pie » ¿Qué hiciste ayer?, ¿Qué harás hoy?, ¿Qué problemas has tenido?

 Retrospectiva de Sprint Curso Scrum – S1: Scrum Master

Rol opcional en la reunión

22

V14 – Grup Oct. 2015

 Revisión de Sprint

1 2. Fundamentos de Scrum Las horas de un Sprint

1 Sprint Planning (4h)

2

3

4

5

6

7

3 4 5 6 7

8

9

10

Daily Scrum (15 min)

Sprint Review (2h) Retrospective Sprint (2h)

Equipo 5 personas (40h/semana)

Reserva para desarrollo: 80%

Sprint de 2 semanas (10 días labor.)

Reserva para incidencias, etc.: 20%

Capacidad sprint: 5 * 40 * 2 = 400h

Desarrollo neto: 400h * 80% – 5*4h – 5*2h – 5*2h = 280h

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

Ejemplo del reparto de horas de un Sprint

23

1 2. Fundamentos de Scrum Características de Scrum

3 4 5 6 7

 Ciclo de vida iterativo con fases fijas Las iteraciones (Sprint) tiene duración fija (2, 4, 6 semanas). Durante el sprint, no se cambia su alcance comprometido. Tras cada iteración, se entrega una parte “funcionando” del producto. Las funcionalidades se ordenan por prioridad en un Project Backlog y se agrupan en Sprints según su tamaño. » Los recursos, tiempo y calidad no varían, el alcance sí. » » » »

× Se entrega el alcance, de manera priorizada en sprints, hasta que se acaba el presupuesto.

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

» El cliente fija expresamente sus prioridades y está informado en todo momento del avance del proyecto.

24

1 2. Fundamentos de Scrum Scrum vs PMBOK SCRUM

Requisitos

Estimados antes de comenzar el proyecto, detallados antes de planificar

Detallados progresivamente, Product Backlog > Sprint Backlog.

Alcance

Descomposición de productos (PBS) y tareas (WBS) durante planificación.

Contenido Product Backlog.

Presupuesto

Estimado respecto alcance (fijo).

Estimado respecto trabajo (fijo).

Programación

Diagramas de red, PERTT, cadena crítica, calendario como Diagrama de Gantt

Orden del Product Backlog en Sprints de duración fija.

Fases

Se cierran con un hito, punto principal de validación con los actores.

Sprints cortos (2-4 semanas). Se reevalúa todo el proyecto (backlog).

Seguimiento

Avance: ejecución de tareas (Gantt) y trabajo/presupuesto dedicados.

Producto entregado en cada Sprint (trabajo fijo).

Típicamente mensual y en hitos.

Reestimación de fechas contínua (Rectas de burndown de proyecto y Sprint).

Reestimación de fechas según criterio.

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

PMBOK

3 4 5 6 7

25

1 2. Fundamentos de Scrum Los 3 pilares de Scrum

3 4 5 6 7

 Transparencia (entendimiento común)

» Tener un entendimiento común del proceso basado en Scrum » Comprender y compartir la definición de hecho (DoD)

 Inspección (empirismo, contrastar lo deseado con lo obtenido)

» Inspeccionar el proceso y el producto para detectar desviaciones » Frecuente (mitigar riesgo), pero no demasiado (sobrecarga de trabajo)

 Adaptación (optimización del trabajo y del producto)

CONFIANZA CORAJE

TRANSPARENCIA

INSPECCIÓN ADAPTACIÓN

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

» Ajustar el trabajo (Daily Scrum y Sprint Review) » Ajustar el producto (Sprint Review) » Ajustar el proceso (Sprint Retrospective)

SCRUM 26

Gestión de proyectos SCRUM – Clase 1 Metodologías ágiles vs tradicionales Fundamentos de Scrum Roles de Scrum Eventos de Scrum Artefactos de Scrum Escalando Agile Agilidad disciplinada: DAD Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

1 2 3 4 5 6 7

27

1 2 3. Roles de Scrum

Product Owner (PO)

4 5 6 7

 Responsabilidad » Maximizar el valor del producto (ROI y TCO) y del trabajo del equipo de desarrollo

 Funciones

V14 – Grup Oct. 2015

» Definir claramente los items del Product Backlog » Priorizar el Product Backlog y asegurar que el equipo lo utiliza en sus sprints » Los requisitos del producto siempre deben pasar por esta persona

Curso Scrum – S1: Scrum Master

28

1 2 3. Roles de Scrum Development Team (DT)

4 5 6 7

 Responsabilidad » Realizar todas las actividades para producir los incrementos del producto durante los sprints

 Características

V14 – Grup Oct. 2015

» Tamaño por encima de 3 (poca “potencia”) y por debajo de 9 (demasiada “complejidad”) » Se auto-organizan para realizar los ítems del Sprint Backlog » El Scrum Master ayuda a seguir los eventos, artefactos y roles de Scrum, pero no dice al equipo como deben realizar su trabajo

Curso Scrum – S1: Scrum Master

29

1 2 3. Roles de Scrum

Scrum Master (SM)

4 5 6 7

 Soporte al Product Owner » Definir y gestionar un backlog que maximice el valor » Planificación de producto con un enfoque ágil

 Soporte al Development Team » Actuar de manera auto-organizada y polivalente (cross-skill) » Eliminar bloqueos e impedimentos » Crear productos de alto valor

V14 – Grup Oct. 2015

 Soporte a la organización » Planificar, dar seguimiento y liderar la adopción de Scrum » Ayudar al resto de la organización a colaborar con el Scrum Team Curso Scrum – S1: Scrum Master

30

Gestión de proyectos SCRUM – Clase 1 Metodologías ágiles vs tradicionales Fundamentos de Scrum Roles de Scrum Eventos de Scrum Artefactos de Scrum Escalando Agile Agilidad disciplinada: DAD Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

1 2 3 4 5 6 7

31

1 2 3 4. Eventos de Scrum Reunión de planificación de Sprint

5 6 7

 Objetivo » Planificar el trabajo a realizar durante el Sprint

 Duración: 8h (sprint 30 dias)  Parte 1: ¿Qué se hará en el Sprint? » Participa el Product Owner y el Development Team » Se estima la parte del Product Backlog que puede realizarse con el tiempo (Sprint) y recursos (tamaño del equipo) disponibles

 Parte 2: ¿Cómo se hará?

Sprint Backlog reestimado

Diseño y tareas del Sprint

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

» Participa sólo el Development Team » El alcance del Sprint se analiza y descompone en tareas más pequeñas (4..8 horas) y se consensúa la estrategia para realizarlas Frase “Sprint Goal”

32

1 2 3 4. Eventos de Scrum

5 6 7

Scrum diario

 Objetivo » El equipo da seguimiento a su trabajo, se coordina y planifica el trabajo a realizar durante la jornada

 Duración: 15 minutos (de pie, en el mismo lugar/hora)  El equipo se coordina explicando cada miembro: • Persona óptima para la tarea • Eliminación de cuellos de botella V14 – Grup Oct. 2015

» ¿Qué hiciste ayer? » ¿Qué harás hoy? » ¿Qué obstáculos has tenido o tendrás?

 ¡Sólo responder las preguntas! !No permitir un debate! Curso Scrum – S1: Scrum Master

33

1 2 3 4. Eventos de Scrum Revisión de Sprint

5 6 7

 Objetivo » Revisar y validar el resultado del Sprint » Mejorar la colaboración entre equipo y los actores externos

 Duración: 4 horas (sprint 30 dias)  Actividades

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

» El DT muestra el resultado conseguido al PO » El DT explica qué fue bien, qué fue mal y como se reaccionó » El PO actualiza el Product Backlog según el avance conseguido y explica a los demás las previsiones de versiones y fechas » Todos colaboran para planificar los próximos pasos

34

1 2 3 4. Eventos de Scrum Retrospectiva de Sprint

5 6 7

 Objetivo » Aprender de lo que ha ido mal para mejorar en el próximo sprint (desde el punto de vista de todos los roles)

 Duración: 3h (sprint 30 dias)  Participa: Scrum Team  Contenidos

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

» Identificar como fue el Sprint respecto gente, relaciones, procesos y herramientas (post it en Kanban, votaciones imanes…) » Identificar las cosas que fueron bien y como mejorar las que no » Planificar (que, quien, como) las mejoras para el Sprint

35

1 2 3 4. Eventos de Scrum Aplicabilidad de Scrum

5 6 7

 Tipos de proyecto donde Scrum es muy adecuado » » » »

Desarrollo interno de producto Existe confianza entre cliente y proveedor No se requieren grandes inversiones materiales iniciales Equipo cohesivo (objectivos y disponibilidad comunes)

 Tipos de proyecto donde mejor no usar Scrum

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

» Relación “contractual” entre cliente y proveedor » Plazo, alcance y recursos fijados de antemano » Se requiere una gran inversión inicial relacionada con el alcance definido para el proyecto » Equipo de diferentes empresas con objetivos propios

36

Gestión de proyectos SCRUM – Clase 1 Metodologías ágiles vs tradicionales Fundamentos de Scrum Roles de Scrum Eventos de Scrum Artefactos de Scrum Escalando Agile Agilidad disciplinada: DAD Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

1 2 3 4 5 6 7

37

1 2 3 4 5. Artefactos de Scrum “Planificación” del proyecto (1)

6 7

 Product Backlog Sprint #1 (15/Feb) [320h] Historia 1 (45h) Historia 2 (80h) Historia 3 (90h) Historia 4 (70h)

285h

Sprint #2 (1/Mar) [320h] Historia 5 (80h) Historia 6 (90h) Historia 7 (60h) Historia 8 (70h)

300h V14 – Grup Oct. 2015

Sprint #3 (15/Mar) [320h] Historia 9 ···

Curso Scrum – S1: Scrum Master

38

1 2 3 4 5. Artefactos de Scrum “Planificación” del proyecto (2)

6 7

 Product Backlog » Contiene todo el trabajo pendiente (relevante para el Product Owner) × Normalmente funcional (en forma de “historias de usuario”) × Tareas técnicas de “I+D” (p.e. Architectural Spike) × Cualquier otro tipo de item relevante para el P.O. (bug, cambio…)

» La priorización la da el “product owner”, y en la estimación participa todo el equipo. El orden se calcula con: {valor, riesgo, necesidad}. » Es un elemento de gestión, NO de documentación (habitualmente estará en wikis, maquetas, etc.) V14 – Grup Oct. 2015

» Los elementos se van detallando tal y como se aproximan: ¿porqué elaborar un elemento lejano que puede cambiar o desestimarse? » La priorización puede realizarse durante el sprint o en la revisión de sprint, pero su elaboración es continua (backlog grooming) Curso Scrum – S1: Scrum Master

39

1 2 3 4 5. Artefactos de Scrum “Planificación” del proyecto (3)

6

 Refinamiento y Sprint Plan

EPIC Story

IDEA

EPIC

Story

Story Task Task

Sprint Review Daily

V14 – Grup Oct. 2015

IDEA

Sprint Planning Backlog Refinement

Curso Scrum – S1: Scrum Master

40

1 2 3 4 5. Artefactos de Scrum “Planificación” del proyecto (3)

6

 Refinamiento y Sprint Plan Epic 1

Backlog / Roadmap H2

H5 H6 H10 H13 E2

H3

H7 H8 H9

H11

H12

E3 E5 E6

Sprint 1 (1-15/Mar) Sprint 2 (16-30/Mar)

Backlog Refinement (durante Sprint) DoR

H2

H3

H4

H1a

H1b

Sprint 3 (1-15/Abr) Sprint 4 (16-30/Abr)

E2

E4 H14

H4

Historia 1

Sprint 5 (1-5/May) Versión 2

Sprint 2

Sprint 1 Plan H2 H4

No comprometido

Curso Scrum – S1: Scrum Master

H5* Nueva historia

H3 Tarea 31: Web

V14 – Grup Oct. 2015

H1

Epic 2

Tarea 32: Back Tarea 33: Doc + Test

41

1 2 3 4 5. Artefactos de Scrum The Definition of Ready (DoR)

6 7

 Definida por el equipo y Product Owner » Se usa para decidir cuando un ítem del backlog está suficientemente definido para entrar al Sprint » Ejemplo: Estimación de esfuerzo < 40 horas Se puede definir su prueba de aceptación (p.e. Story Test) No existe un riesgo técnico que merezca una exploración previa (I+D) No existe una cohesión técnica o funcional que merezca mover el ítem a otro sprint

V14 – Grup Oct. 2015

× × × ×

DoR

Curso Scrum – S1: Scrum Master

42

1 2 3 4 5. Artefactos de Scrum “Planificación” del proyecto (4)

6 7

 Release Plan / Roadmap » Plan de entregas (versiones) del producto de alto nivel » Objetivo: presupuesto y planificación (usuarios, otros equipos técnicos) V3

??

V14 – Grup Oct. 2015

V1

V2

Curso Scrum – S1: Scrum Master

43

1 2 3 4 5. Artefactos de Scrum Planificación del Sprint

6 7

 Sprint Backlog » Al comenzar un Sprint (Sprint Planning), se analizan las historias de usuario asignadas y se descomponen en tareas. » El “dueño” es el equipo de desarrollo. » Capacidad del Sprint × Tamaño del equipo * Duración * Dedicación × P.e. 3 personas * 2 semanas * 80% = 192 horas × Se recomienda asignar máximo el 80% del tiempo útil para absorver desviaciones

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

» Al refinar las historias, puede descubrirse que las funcionalidades asignadas sean más grandes de la capacidad. » Se puede añadir o eliminar contenido según se vea que el avance es superior o inferior al planificado.

44

1 2 3 4 5. Artefactos de Scrum Seguimiento del Sprint (1)

6

 Scrum Board (Kanban) » No es un artefacto oficial de Scrum pero sí de uso frecuente.

Requisito

V14 – Grup Oct. 2015

Sprint Backlog

Tareas del requisito

Curso Scrum – S1: Scrum Master

45

1 2 3 4 5. Artefactos de Scrum The Definition of Done (DoD)

6 7

 Definida por el equipo y conocida por el Product Owner

» Esta definición la usará cada miembro del equipo para dar por acabada cada historia de usuario » Ejemplo: × × × × × × ×

Código completado Test unitarios creados y superados Test integración creado y superado Documentado wiki (diseño y usuario) La interfaz seguirá los estándares … No se ha detectado ningún bug ···

DoD

V14 – Grup Oct. 2015

 No existe el rol de “pruebas”

» Cada miembro del equipo es responsable de dar como terminada una funcionalidad » El Product Owner da la validación final Curso Scrum – S1: Scrum Master

46

1 2 3 4 5. Artefactos de Scrum ¿Antes del Sprint Review? DoD y Story Test

6 7

 Story Test » Validación funcional » Responsable: P.O.

 Definition of Done » Validación técnica y metodológica » Responsable: Dev Team

 Transparencia

Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

» Ambos deben ser conocidos por el PO para entender el avance sobre el producto

47

1 2 3 4 5. Artefactos de Scrum Seguimiento del Sprint (2)

6 7

 Recta de “burn down”

V14 – Grup Oct. 2015

» ¿Avanzamos al ritmo planificado? (iteración o release) » Siempre se refiere a analizar el avance futuro (en el examen)

Curso Scrum – S1: Scrum Master

48

1 2 3 4 5. Artefactos de Scrum Kanban independiente de Scrum

6 7

WIP limit = 16

Entrada

3

2

6

3

2

Analisis

Dev Ready

Desarrollo

Build Ready

Test

Doing

Done

Doing

Release Ready

Done

Proyecto 1 (WIP: 25% = 4 ) Proyecto 2 (WIP: 50% = 8) V14 – Grup Oct. 2015

Imprevistos (WIP: 25% = 4)

Curso Scrum – S1: Scrum Master

49

1 2 3 4 5. Artefactos de Scrum Scrum + Kanban = Scrumban

6 7

 Combinar Scrum y Kanban » Muchos proyectos de mantenimiento son pequeños y arrítmicos » No se mantiene un Product Backlog » Se acumulan las peticiones y se realiza un Sprint Planning conjunto para todos los proyectos

V14 – Grup Oct. 2015

Sprint 2 semanas. WIP limit = 16

Sprint Planning

Curso Scrum – S1: Scrum Master

50

1 2 3 4 5. Artefactos de Scrum Seguimiento del Proyecto (1)

6 7

 Release / Project Burndown Original

800

Añadido

700 600 500 400 300

700

50 500

200

300

100

150

0

Trabajo eliminado

50 30 50

50

-100

50

-200

V14 – Grup Oct. 2015

Trabajo pendiente

150

V1 15/10 30/10 #1

#2

15/11 #3

30/11 #4

15/12

30/12

#5

#6

Curso Scrum – S1: Scrum Master

51

1 2 3 4 5. Artefactos de Scrum Seguimiento del Proyecto (2)

6 7

 Ranged Release Burndown

V14 – Grup Oct. 2015

» ¿Qué pasa si continuamos añadiendo funcionalidad al mismo ritmo?

Curso Scrum – S1: Scrum Master

52

1 2 3 4 5. Artefactos de Scrum Seguimiento del Proyecto (3)

6 7

 Velocity Chart

V14 – Grup Oct. 2015

» Observar cual es la “velocidad” estimada

Curso Scrum – S1: Scrum Master

53

Gestión de proyectos SCRUM – Clase 1 Metodologías ágiles vs tradicionales Fundamentos de Scrum Roles de Scrum Eventos de Scrum Artefactos de Scrum Escalando Agile Agilidad disciplinada: DAD Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

1 2 3 4 5 6 7

54

1 2 3 4 5 6. Escalando Agile Estructuración de un “equipo de equipos”

7

 Component teams

Ingeniería de sistemas tradicional (interfaces) Conocimientos/trabajo en una “capa” Análisis en tareas y asignación a equipos ¿Incremento integrado al fin de sprint?

 Feature teams

Web / móvil

A

Lógica de negocio Back-end / servicios

A

» Conocimientos/trabajo en todas las “capas” » Descomposición en tareas de desarrollo dentro del sprint » Suelen integrar durante el sprint, minimizando los conflictos

B

B

× Estrategia de asignación de funcionalidades × Coordinación de tareas × Integración frecuente (C.I. del equipo, integra. nocturnas entre equipos)

Curso Scrum – S2: Product Owner y Developer

V14 – Grup Oct. 2015

» » » »

55

1 2 3 4 5. Agilidad en la departamento de IT

6

Coordinación multiequipo - Herramientas  Coordinación de equipos basada en reuniones presenciales Reuniones muy breves y pautadas, p.e. junto a un tablero Kanban Se producen menos errores y cuellos de botella por falta de coordinación Se reduce la documentación menos valiosa y burocracia Pueden acudir otros roles relevantes como Service Manager o IT Operations Scrum of scrums (p.e. semanal)

Coordinación departamento CIO

Svc Mgr

Front Office Daily Standups

SM

SM

IT OPS

Back Office SM

SM

SM

Infraestructura V14 – Grup Oct. 2015

» » » »

SM

Curso Agile IT Management - Sesión 01 - Agilidad en la empresa

56

7

V14 – Grup Oct. 2015

1 2 3 4 5 6. Escalando Agile Nexus – Scrum escalado

https://www.scrum.org/Resources/What-is-Scaled-Scrum

Curso Scrum – S1: Scrum Master

57

1 2 3 4 5 6. Escalando Agile LeSS – Scrum escalado

7

V14 – Grup Oct. 2015

http://less.works

Curso Scrum – S1: Scrum Master

58

Curso Scrum – S1: Scrum Master

59

V14 – Grup Oct. 2015

7

https://labs.spotify.com/author/hkniberg

1 2 3 4 5 6. Escalando Agile Spotify – Responsabilidades distribuidas

Curso Scrum – S1: Scrum Master

60

V14 – Grup Oct. 2015

7

http://www.scaledagileframework.com

1 2 3 4 5 6. Escalando Agile SAFe – Jerarquía tradicional (funcional y técnica)

en la departamento de IT 11 2 3 4 5. 5 Agilidad 6. Escalando Agile Coordinación Agile Portfolio multiequipo Management - Herramientas (3)

 Release Radar

76

Capacidad del periodo 8 personas * 40h * 2 semanas = 640h

Epic / Tarea Tamaño = p.e. 20h .. 100h Color = tipo de tarea Marca = prioridad 2 sem 4 sem 6 sem

8 sem

Curso Agile IT Management - Sesión 01 - Agilidad en la empresa

V14 – Grup Oct. 2015

Un perfil puede estar en varios sectores a la vez. Contribuye en horas a la capacidad del periodo

61

1 2 3 4 5. Agilidad en la departamento de IT

6

Reuniones

Ops Dev1 Dev2 V14 – Grup Oct. 2015

SCRUM OF SCRUMS SCRUM OF SCRUMS

DAILY DAILY DAILY

Stories – Tareas Técnica

SPRINT PLAN

SPRINT PLAN SPRINT PLAN

PLANNING GENERAL

Epics – Prioridades – Dependencias

Coordinación multiequipo – Herramientas (2)

Herramientas

Curso Agile IT Management - Sesión 01 - Agilidad en la empresa

62

Gestión de proyectos SCRUM – Clase 1 Metodologías ágiles vs tradicionales Fundamentos de Scrum Roles de Scrum Eventos de Scrum Artefactos de Scrum Escalando Agile Agilidad disciplinada: DAD Curso Scrum – S1: Scrum Master

V14 – Grup Oct. 2015

1 2 3 4 5 6 7

63

V14 – Grup Oct. 2015

1 2 3 4 5 6 7. Agilidad disciplinada: DAD Actividades del Sprint (segun DAD)

Curso Scrum – S1: Scrum Master

64

V14 – Grup Oct. 2015

1 2 3 4 5 6 7. Agilidad disciplinada: DAD Actividades del día (segun DAD)

Curso Scrum – S1: Scrum Master

65

V14 – Grup Oct. 2015

1 2 3 4 5 6 7. Agilidad disciplinada: DAD Tipos de actividades de desarrollo (según “DAD”)

Curso Scrum – S1: Scrum Master

66

67 V14 – Grup Oct. 2015

Gestión de proyectos SCRUM – Clase 2 Definición del producto (requisitos ágiles)

2

Planificación y estimación de requisitos

3

Testing ágil: estrategia y técnicas

4

Bibliografía V14 – Grup Oct. 2015

1

Curso Scrum – S2: Product Owner y Developer

68

Gestión de proyectos SCRUM – Clase 2 Definición del producto (requisitos ágiles)

2

Planificación y estimación de requisitos

3

Testing ágil: estrategia y técnicas

4

Bibliografía V14 – Grup Oct. 2015

1

Curso Scrum – S2: Product Owner y Developer

69

1. Definición del producto (requisitos ágiles) Técnicas para desarrollar requisitos General

Modelado de uso

 Mapa conceptual

 Epic / User Story

 Diagrama de contexto

 Use Case Diagram / Spec

 Lista de funcionalidades

 Usage Scenario / Persona

2 3 4

Modelado de proceso

Interfaz de usuario

Modelo de dominio

No Funcionales

 Business Process

 UI Flow / Navigation

 Domain

 Constraint

 Conceptual model

 NFR

 UML Activity / State

map  UI Prototype (lo-fi/ hi-fi)

V14 – Grup Oct. 2015

 Data / Activity Flow

 UI Specification

Curso Scrum – S2: Product Owner y Developer

70

1. Definición del producto (requisitos ágiles) Una jerarquía de requisitos ágiles (1)  Descomposición funcional

Visión del proyecto 120h

Product backlog / roadmap (p.e. excel)

Orden de magnitud

400h

Portfolio Mgmt. / product inception (p.e.powerpoint)

2 3 4

Oferta comercial

Sprint backlog (p.e. excel y herramienta BD)

Sprint Backlog Work Kanban

Curso Scrum – S2: Product Owner y Developer

24h 4h

71

V14 – Grup Oct. 2015

40h

1. Definición del producto (requisitos ágiles) Una jerarquía de requisitos ágiles (2)

2 3 4

 Descomposición de epics “compuestos”

Requirements Requirements

Features uireme

US_1

Como quiero para

A. B. C. D.

Mantenimiento web del CV (A/B/M), Login candidato desde redes sociales, Acceso móvil al CV, Impresión PDF del CV...

A1. A2. A3. A4.

Un usuario puede crear su CV Un usuario puede editar su CV Un usuario puede tener múltiples CV Un usuario puede activar y desactivar sus CV...

Descomposición de características propias

Descomposición de historias de la característica V14 – Grup Oct. 2015

Gestión de CV (web).

User User Epics

Módulo “general” de características transversales

Curso Scrum – S2: Product Owner y Developer

72

1. Definición del producto (requisitos ágiles) Una jerarquía de requisitos ágiles (4)

2 3 4

 Historia de usuario (User Stories) » Formato: Como quiero para » Deben proporcionar un valor al finalizar (¡no son una parte de un workflow!) » Estimadas a alto nivel y priorizadas durante el “Refinement” » Documentadas en wiki, maquetas, etc.

 Utilidades

Descripción de la funcionalidad y necesidad con perspectiva del usuario Fomentan la colaboración y no el intercambio de documentos Elemento de planificación orientado a funcionalidad (no a tarea) Elemento para retrasar el análisis al momento óptimo Curso Scrum – S2: Product Owner y Developer

V14 – Grup Oct. 2015

» » » »

73

1. Definición del producto (requisitos ágiles) Una jerarquía de requisitos ágiles (5)

2 3 4

 Posibles atributos de una historia de usuario » Título, descripción, beneficio esperado » Estimación o tamaño, en puntos o días ideales » Valor (MuSCoW, Kano, Alto-Medio-Bajo, Fibonacci, dinero…) » Métricas de éxito (usuarios/ejecuciones, reducción de tiempo…) » Dependencias técnicas o funcionales (de otras historias) » Riesgo técnico o funcional esperado » Estado: planificado para una release o sprint, en realización, hecha V14 – Grup Oct. 2015

» Petición: fecha, autor…

Curso Scrum – S2: Product Owner y Developer

74

1. Definición del producto (requisitos ágiles) Una jerarquía de requisitos ágiles (5)  Criterio de aceptación (Story Test) » Típicamente determinado en la reunión de Sprint Planning

2 3 4

Como cliente pago la compra con tarjeta 1. 2. 3. 4.

Carrito con 1..20 productos Clic en boton “pagar” ··· Recibo mail con confirmación…

 División en sub-historias » Al analizar la historia puede convenir dividirla en bloques menores

V14 – Grup Oct. 2015

Como cliente pago la compra con tarjeta

Como cliente registrado tengo un descuento según mi histórico Como cliente recibo una notificación de las compras

Curso Scrum – S2: Product Owner y Developer

75

2 3 4

Historias (I.N.V.E.S.T.)

Tareas (S.M.A.R.T.)

Independientes. Las historias han de ser lo más independientes posibles, tanto funcional como técnicamente. Facilita su planificación e implementació.

Specific (Específica). Se comprende su objetivo y alcance, para evitar solapamientos.

Negociables. El detalle de la historia debe añadirse cuando sea necesario, no debe “cerrarse” al principio.

Medible. Se conoce su alcance para determinar cuanto trabajo queda o si está completada correctamente.

Valiosas. Se ha de entender el valor individual que aporta cada historia al cliente.

Achivable (Realista). Se ha de poder realizar con un grado de riesgo limitado.

Estimables. Si una historia no es estimable es demasiado indefinida y arriesgada. No hace falta estimaciones detalladas, sólo orientativas.

Relevante. Se ha de entender que aporta cada tarea para completar la historia.

Small (pequeñas). Las buenas historias son pequeñas para “fluir” y ser refinadas sin gran coste. Testeables. Si una historia se puede testear es que se ha entendido entre Product Owner y equipo.

Time-boxed (Cuantificada). Se ha de entender el coste estimado de realización para saber cual es la mejor manera de abordarla (cuando, quien, como…)

Curso Scrum – S2: Product Owner y Developer

76

V14 – Grup Oct. 2015

1. Definición del producto (requisitos ágiles) Buenas prácticas para definir Historias y Tareas

1. Definición del producto (requisitos ágiles) 2 3 4 Definición de requisitos a partir de Story Mapping (1) Objetivos del usuario Se logran a través de

Tareas y actividades del usuario

User Senario

Funcionalidad de herramienta Curso Scrum – S2: Product Owner y Developer

V14 – Grup Oct. 2015

Soportadas por

User Story Map 77

1. Definición del producto (requisitos ágiles) 2 3 4 Definición de requisitos a partir de Story Mapping (2)  User Scenario » Ayuda a identificar los requisitos

 Story Maps Hacen visible el workflow o cadena de valor Muestran las relaciones entre historias grandes (y sus “hijas”) Ayudan a confirmar que el backlog está completo Proporcionan información útil para priorizar Ayudan planificar “rodajas” de funcionalidad completas y valiosas V14 – Grup Oct. 2015

» » » » »

Curso Scrum – S2: Product Owner y Developer

78

1. Objetivos y formato del mapa de historias Un formato para definir “personas”

2 3 4

Antonio, un Comprador Contexto • •

Acerca de Antonio

¿Quién es Antonio? ¿Por qué debería usar la solución?

Implicaciones

Características

•

¿Qué valorará Antonio?

•

Metas e impedimentos

•

•

Actividades relevantes

¿Cómo adaptaremos la solución a sus necesidades? V14 – Grup Oct. 2015

•

Curso Scrum – S2: Product Owner y Developer

79

1. Definición del producto (requisitos ágiles) 2 3 4 Definición de requisitos a partir de Story Mapping (3)

User Scenario Narración acerca de las necesidades del usuario  Como la “persona” alcanza sus objetivos  Contexto del usuario

V14 – Grup Oct. 2015

 Metas y preocupaciones del usuario

Curso Scrum – S2: Product Owner y Developer

80

1. Objetivos y formato del mapa de historias Elementos y estructura

2 3 4 Flujo narrativo

Objetivo Negocio Release

Rol2

Rol 1

Actividad

User activities Backbone

Tarea

User tasks Walking Skeleton

Subtareas

User Stories Release “MVP” User Stories Release V1 User Stories Release V2

Curso Scrum – S2: Product Owner y Developer

81

V14 – Grup Oct. 2015

Rol 1

V14 – Grup Oct. 2015

1. Definición del producto (requisitos ágiles) 2 3 4 Definición de requisitos a partir de Story Mapping (5)

Curso Scrum – S2: Product Owner y Developer

82

1. Objetivos y formato del mapa de historias 2 3 4 Aspectos a tratar desarrollando un map de historias 1. ¿Quién? Pensar en características y necesidades de diferentes roles y “personas”

2. ¿Qué? ¿Qué hace el usuario? ¿Cómo puede ayudar el sistema?

3. ¿Por qué? El porqué de tareas o funcionalidades puede destacar asunciones y encontrar mejores soluciones

6. ¡Mejores soluciones! ¿Podemos encontrar variantes de las tareas de usuario o funcionalidades más eficaces y eficientes?

Curso Scrum – S2: Product Owner y Developer

(la discusión de la funcionalidad puede incluir detalles técnicos, pero sólo los relevantes para el usuario)

83

V14 – Grup Oct. 2015

5. ¿Errores y trabajo sin el sistema? ¿Cómo podrán hacer el trabajo los usuarios si la funcionalidad, o todo el sistema, no responde?

4. ¿Cómo? ¿Cuál es la mejor opción técnica para satisfacer al usuario?

1. Objetivos y formato del mapa de historias 2 3 4 Story Mapping para evolucionar sistemas existentes Situación actual

Situación deseada

?

Dificultades

Plan de entregas

Fortalezas

» Minimizar el “output” » Maximizar el “outcome”

Nuevas actividades y tareas del usuario (El flujo narrativo suele permanecer bastante estable)

Curso Scrum – S2: Product Owner y Developer

Funcionalidades modificadas

Nuevas funcionalidades

84

V14 – Grup Oct. 2015

Dudas

1. Objetivos y formato del mapa de historias Temas: colecciones de historias

2 3 4

Temas de release

Temas de actividad y tarea

Temas de característica

Ayudan en el diálogo con los usuarios

Ayudan en el diálogo con los usuarios

Curso Scrum – S2: Product Owner y Developer

V14 – Grup Oct. 2015

Ayudan en el seguimiento de las versiones

85

1. Objetivos y formato del mapa de historias El ciclo de vida de la historia: las 5 C’s Card

Conversation

Confirmation

Construction

2 3 4

Consequences

Oportunidad

Evaluación

Story Test

HHHHHH HH HHHHHH E E E

H E E

Métricas DoR

DoD

Lista

¡Hecha!

E E

Release Plan Product Backlog

Maqueta

V14 – Grup Oct. 2015

what who why

Mapa de historias

Demo

¿Modelo de negocio?

Curso Scrum – S2: Product Owner y Developer

86

1. Objetivos y formato del mapa de historias 6 pasos para hacer el Story Mapping

2 3 4

¿Problemas actuales (métricas)? ¿Stakeholders, roles y personas?

Mapear el flujo amplio

Actividades y tareas actuales de los roles. Dificultades, problemas y dudas. Nuevas actividades, tareas y funcionalidades del sistema.

Explorar los detalles

Discutir prioridades, riesgos y mejoras en las funcionalidades. Hacer maquetas y explorar estrategias técnicas (arquitecturas, reutilización…)

Estrategia de releases

Identificar objetivos para releases (según estrategia de empresa o de usuarios). Refinar considerando el coste y los recursos.

Estrategia de aprendizaje

Considerar los riesgos y las métricas para validar la estrategia de releases como una serie de experimentos.

Estrategia de desarrollo

Identificar los sprints, equipo y aspectos técnicos. Minimizar los riesgos afrontando pronto su realización.

Curso Scrum – S2: Product Owner y Developer

V14 – Grup Oct. 2015

Enmarcar el problema

87

1. Objetivos y formato del mapa de historias Colaboración de roles

2 3 4

 Enfoque operativo e inclusivo

Valioso

» Equipo pequeño (3..5 personas) » Fomentan la colaboración, no las decisiones propias » El P.O. es un líder, no un experto de todos los dominios

Factible

Equipo de Descubrimiento del Producto P.O.

Expertos (SME)

UX

Negocio MKTG

ORG

FI/CO

IT

SW

Ingenieros

Clientes/usuarios V14 – Grup Oct. 2015

Equipo integrado

Equipos de soporte

Usable

BACK

TEST

OPS

Curso Agile IT Management - Sesión 01 - Agilidad en la empresa

88

1. Objetivos y formato del mapa de historias Requisitos no funcionales (NFR) y riesgos - 1

2 3 4

Requisitos técnicos Tipos de requisitos

Requisitos y cuando pensamos afrontarlos (en que release)

Curso Scrum – S2: Product Owner y Developer

V14 – Grup Oct. 2015

Historias de riesgos y soluciones propuestas

89

1. Definición del producto (requisitos ágiles) Requisitos no funcionales (NFR) y riesgos - 2

2 3 4

Sprint

Historias

Gestión de CV web

S1

T1: Construir entorno T2: Construir arquitectura básica

A. Mantenimiento web del CV (A/B/M)

S2

H1: Programar transacción 1 P1: Prueba 1000 users transacción H2: Programar listado 1

S3

H3: Programar formulario 1 ··· ···

· · ·

Compat.naveg. X

X X

A2. Un usuario puede editar su CV

B. Login candidato desde redes sociales

Gestión de empresas

X

V14 – Grup Oct. 2015

S4

A1. Un usuario puede crear su CV

Respuesta