Clase 02 Scrum

1

SCRUM

Universidad de los AndesDemián Gutierrez

Enero 2013

2

Esta presentación contiene en parte materialtomado de la presentación de

Xavier Albalalejo “La alternativa Ágil”

3

Modelos ágiles(SCRUM / Origenes, Desarrollo de Productos)

Japón, años 80

Takeuchi y Nonaka

basado en las mejores prácticas de las empresas con buenos resultados de

rapidez y flexibilidad en la producción de la época

Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Hewlet Packard

4

Modelos ágiles(SCRUM / Origenes, Software)

OOPSLA ’95 (conferencia)

Jeff Sutherland y Ken Schwaber

ScrumAlliance (2002)

Ken Schwaber y Mike Cohn

Scrum.org (2009)

Ken Schwaber

5

Modelos ágiles(SCRUM / Principios)

Es mejor tener equipos pequeños yauto-organizados:

Formados por miembros de diferentes disciplinas

Capaces de organizarse por si mismos(auto-organización)

Con una comunicación transparente

De esta forma, en general,se suelen obtener mejores resultados y

todos los miembros del equipo estánmás comprometidos y motivados

6

Modelos ágiles(SCRUM / Principios)

La palabra Scrum procede del vocabulario del rugby y significa melé; es decir, esa “figura” en la que los compañeros del equipo se

amontonan, forman una piña y empujan todos en la misma dirección

7

(3)roles

(3)artefactos

(1)proceso

(4)ceremonias

(reuniones)

Modelos ágiles(SCRUM)

8

¿roles?(¿quiénes?)

9

Los demás: Clientes,Ejecutivos, Usuarios, etc...no son más que pollos ;-)

Modelos Ágiles(SCRUM / Roles)

Product Owner(dueño del producto)

Team / Equipo(dueños del desarrollo)

Scrum Master(dueño facilitador del proceso)

cerdos

10

SCRUM(Roles)

ese cuento ha sidoinmortalizado demuchas formas

11

¿proceso?(¿cómo?)

12

Modelos Ágiles(SCRUM / Proceso)

Un Sprint(iteración, ciclo, etc)

? ?

Lazo de feedback

diario

Lazo de feedback cada 1-4 semanas

13


Varios Sprints

...? ?...? ?

Lazo de feedback

diario

Lazo de feedback

diario

Lazo de feedback

diario

Lazo de feedback semanal



14

15

¿artefactos?(¿qué?)

16

Modelos Ágiles(SCRUM / Artefactos)

tareas de < 16 horas (sólo del sprint)

requisitos “features” de la aplicación

(de todo el producto)

resultado / producto(entregas frecuentes)

definición de listo(Definition of Done)

3 artefactos

17

Modelos Ágiles(SCRUM / Artefactos)

artefactos, herramientasy otros radiadores de información

Scrum Burn DownTablero de Kanban

aunque oficialmente NO SON parte de Scrum(más adelante hablaremos de ellos)

18

¿ceremonias?(¿de qué forma?)

19

Modelos Ágiles(SCRUM / Ceremonias)

(4) retrospectiva¿cómo podemos

mejorar?

(1) sprint planning¿que tan complejas son las

historias?¿que historias van para este

sprint?

(2) daily scrum¿cómo vamos?

(3) sprint review/demo¿qué hemos

logrado?

20

¿requisitos?(¿qué debe hacer el producto?)

Historias de Usuarios(Modelos ágiles – XP, SCRUM)

Una historia de usuario es una narración que describe una funcionalidad del sistema que tiene valor para un usuario

Se recogen en unas sencillas tarjetas de forma esquemática y en un lenguaje claro y preciso

Aprobación de nuevos usuarios

Yo como administrador del foro quisiera poder aceptar o rechazar los nuevos usuarios registrados para así poder evitar que el foro se llene de

spammers

¿quién?¿qué?

¿por qué?

Historias de Usuarios(Modelos ágiles – XP, SCRUM)

Las historias de usuario sirven de “recordatorio” de la funcionalidad que es necesario implementar en el

sistema

Antes de implementar una funcionalidad en particular se produce una discusión con el usuario, se refina y extiende la información de la historia de usuario

Aprobación de nuevos usuarios

Yo como administrador del foro quisiera poder aceptar o rechazar los nuevos usuarios registrados para así poder evitar que el foro se llene de

spammers

23

Historias de Usuarios(SCRUM / Requisitos)

Es posible (y útil) también escribir un breve documento donde se define la visión general del sistema/producto

Esto ayuda a tener una visión global del producto que se está

desarrollando

24

¿cómo se ordenany gestionan los

requisitos?

25

Modelos Ágiles(SCRUM / Requisitos)

El product backlog tiene todos los

requisitos del producto

Se puede ver como una lista de todo lo

que el usuario/cliente desea del producto

(a wishlist)

26


Los requisitos del product backlog se priorizan y se asignan a los distintos sprints planificados, es decir, al

sprint backlog de cada sprint

¿Release Plan?

Próximo Sprint, historias con suficiente detalle y

estimadas

Siguientes Sprints, no mucho detalle,

estimaciones y plan tentativos

27

28


Una vez comenzado el sprint no se añaden nuevas historias de

usuario al sprint backlogEn general, no hay

cambios, ni en duración ni en objetivos

Sin embargo siempre es posible añadir nuevas historias de usuario al product backlog y/o cambiar las

prioridades de las historias existentes

El equipo es el dueño del sprint backlog

29

¿cómo se estimay planifica?

30

Modelos Ágiles(SCRUM / Planificación)

(1) sprint planning¿que tan complejas son las

historias?¿que historias van para este

sprint?

31


Nombre: Crear mensaje foro

Autor:

Fecha: 21/04/09

Descripción:

Permite crear un nuevo mensaje (hilo) en el foro de discusión.

Actores:

Usuario / Moderador

El usuario debe de estar autenticado en el sistema.

Flujo Normal:

Flujo Alternativo:

El mensaje ha sido almacenado en el sistema y fue publicado.

Pedro Pérez

Precondiciones:

1.- El actor pulsa sobre el botón para crear un nuevo mensaje.2.- El sistema muestra una caja de texto para introducir el título del mensaje y una zona de mayor tamaño para introducir el cuerpo del mensaje.3.- El actor introduce el título del mensaje y el cuerpo del mismo.4.- El sistema comprueba la validez de los datos y los almacena.5.- El moderador recibe una notificación de que hay un nuevo mensaje.6.- El moderador acepta y el sistema publica el mensaje si éste fue aceptado por el moderador.

4.A.- El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al actor de ello permitiéndole que los corrija.

6.B.- El moderador rechaza el mensaje, de modo que no es publicado sino devuelto al usuario.

Poscondiciones:

Antes de comenzar el sprint, de ser necesario, el product owner refinan las historias

de usuario, usando cualquier técnica que se

considere adecuada

32

Modelos Ágiles(SCRUM / Planificación)

¿Qué tal si jugamos poker?

33

¿cómo se ve todohasta ahora?

34


etcétera...

iteraciónsprint 1

iteraciónsprint 2

iteraciónsprint 3

no se comienza un sprint hasta que se termina el anterior

35

¿roles?

36

SCRUM(Roles)

cerdos(realmentecomprometidos)

pollos(involucrados)

37

SCRUM(Roles / Pollos)

Usuarios / Ejecutivos

Son los que usarán y eventualmente pagarán

el producto

38

SCRUM(Roles / Product Owner)

Product Owner:

Representa la voz del cliente y aporta la visión del negocio. Se encarga de escribir y mantener las historias de usuario (Backlog Grooming), les da prioridad y las ubica en el product

backlog.

Es el único con la autoridad para cancelar el proyecto (debe tener

esta autoridad)

39

Scrum Master

Es el dueño/facilitador del proceso

Tiene como principal papel el de dejar el

camino libre de obstáculos e

impedimentos para que el resto del equipo

consiga el objetivo del sprint

SCRUM(Roles / Scrum Master)

40

Scrum Master

Organiza reuniones, hace seguimiento del trabajo que se está

llevando a cabo, apoya en la planificación de los sprints / entregas,

etc


41

Scrum Master

NO ES un Jefe/Gerente/Líder de Proyecto en el sentido tradicional... es más bien un “Líder Servil”

En general no tiene poder de “forzar” al

equipo a hacer algo, pero puede resaltar las consecuencias de no seguir bien el proceso

Es un “profesor” de Scrum...


42

Equipo

Está compuesto por los roles tradicionales:

desarrolladores, probadores, etc.

Estima el esfuerzo de las historias a

desarrollar

Hace lo que sea necesario para

desarrolla el producto y cumplir con las

historias del sprint backlog

SCRUM(Roles / Equipo)

43

¿gestión, controly seguimiento?

44

Reunión Diaria:Es una figura fundamental en SCRUM.

Tiene que reunirse TODO el equipo y debe hacerse según ciertas reglas

Modelos Ágiles(Reunión Diaria)

Lazo de feedback

diarioLazo de feedback cada 1-4 semanas

45

La reunión es diaria y se hace siempre a una hora predefinida, normalmente por la mañana

Reunión Diaria:REGLAS:

Es importante que todos los miembros del equipo acudan puntuales


46

La reunión debe durar alrededor de 15 minutos


Modelos Ágiles(Gestión y Seguimiento / Reunión Diaria)

Se realiza de pie, para mantener el máximo de concentración y atención

Todos los roles son bienvenidos, pero sólo los cerdos pueden hablar

47

En la reunión se realizan las siguientes3 preguntas clave:

¿Qué has hecho desde ayer?

¿Qué tienes planeado hacer mañana?

¿Has encontrado algún problema para conseguir tu objetivo?



48

La transparencia es un aspecto muy importante en estas reuniones

Todos los miembros saben que están haciendo los demás, y los problemas deben ser sacados a la luz en cuanto se detectan

La idea es que los problemas se puedan detectar y resolver a tiempo



49

Modelos Ágiles(Scrum Burn Down)

EJE YTrabajo restante, horas, puntos de

función u otra unidad de medida

EJE XDía o fecha del sprint

generalmente, esto esresponsabilidad del Scrum Master

50

¿qué tal si jugamos un ratocon una hoja de cálculo?

51

Las siguientes hojas de excel fueron tomadas de:

http://agilesoftwaredevelopment.com/

http://www.youtube.com/watch?v=WqgZCiqiYAY

Un video explicativo en:

http://agilesoftwaredevelopment.com/

http://www.youtube.com/watch?v=WqgZCiqiYAY

52

Modelos Ágiles(Gestión y Seguimiento / Scrum Burn Down)

Sprint 3. Plug in the Real Weather

days in sprint / effort leftStory ID Story/task 0 1 2 3 4 5 6 7 8 9 10 11 12 13

63 74 68 64 56 49 41 31 29 32 32 32 32 3210 Fetch one day temperature data from the weather provider system

Make our server connect and authenticate to the provider system 4 16 12 8 3 3 3 3 3 3 3 3 3 3Read provider's data directory 8 7 7 7 4 0 0 0 0 0 0 0 0 0Parse the current temperature out of the data 6 6 4 4 4 1 1 1 1 1 1 1 1 1Push the temperature data to the client 16 16 16 16 16 16 8 2 0 0 0 0 0 0

11 Fetch rain, snow, etc details from the providerParse snow/rain data from the provider's data 4 4 4 4 4 4 4 0 0 0 0 0 0 0Push the snow/rain data to the client 4 4 4 4 4 4 4 4 4 0 0 0 0 0Redesign client screen a bit 3 3 3 3 3Refactor the server code 4 4 4 4 4

12 Fetch several days data from the providerParse the weather data in day packs 10 10 10 10 10 10 10 10 10 10 10 10 10 10Push several days data to the client 3 3 3 3 3 3 3 3 3 3 3 3 3 3

13 Auto-refresh featureMake the client ping server once per 4 hours 6 6 6 6 6 6 6 6 6 6 6 6 6 6Make the server update the client 2 2 2 2 2 2 2 2 2 2 2 2 2 2

Backlog state taken after day 9based on: http://agilesoftwaredevelopment.com/scrum/simple-sprint-backlog

0 1 2 3 4 5 6 7 8 9 10 11 12 13

0

10

20

30

40

50

60

70

80

63

7468

64

56

49

41

31 2932 32 32 32 32

Effort left in sprint

days in sprint

eff

ort

le

ft

53

Modelos Ágiles(Scrum Burn Down)

Weather on Mobile

ID Description Sprint # 1 2 3 4 5 6Effort needed for Release 1 as in the beginning of the sprint 90 70 34 0 0 0

1 Set up continuous integration system 5 0 0 0 0 02 Create compilable application skeleton 5 0 0 0 0 03 Display current temperature in a simplest possible way 13 0 0 0 0 04 Set up the web server for serving weather data 3 0 0 0 0 05 Implement stubby WeatherML support on the server side 13 0 0 0 0 0

Sprint 1 Make sample data go from server to device6 Graphics support on the client side 20 0 0 0 0 0

16 Make the graphics library draw some icon and sample temperature text - 13 0 0 0 017 Draw the real weather screen - 8 0 0 0 07 Implement support for several days 8 8 0 0 0 08 Implement support for rain, snow, etc. icons 2 2 0 0 0 09 City changing support - 5 0 0 0 0

Sprint 2 Minimal working version10 Fetch one day temperature data from the weather provider system ? 13 13 0 0 011 Fetch rain, snow, etc details from the provider 8 8 8 0 0 012 Fetch several days data from the provider 5 5 5 0 0 013 Auto-refresh feature 8 8 8 0 0 0

Sprint 3 Plug in the real weather dataRelease 1 Sellable version

14 Inject simulated ads from the test server 20 20 20 20 20 2015 Plug real ads in 20 20 20 20 20 2018 Change current city automatically according to the cell info 40 40 40 40 40 40

Sprint 4 Advertisements supportRelease 2 Ad-supported version

Effort in the whole backlog 170 150 114 80 80 80

Backlog state taken after the end of sprint 3 = after release 1http://agilesoftwaredevelopment.com/scrum/simple-product-backlog

1 2 3 4 5 6

0

10

20

30

40

50

60

70

80

90

100

90

70

34

0 0 0

Effort left until Release 1

Sprint #

Wo

rk l

eft

1 2 3 4 5 6

0

20

40

60

80

100

120

140

160

180170

150

114

80 80 80

Effort left in the backlog

Sprint #

Wo

rk l

eft

¿Release Plan?

54

Modelos Ágiles(Kanban / Task Boards)

se puede poner en una pared en la oficinay sirve para hacer el seguimientode las tareas del sprint en curso

también hay herramientas en línea:

Límites deTrabajo en Progreso

Work In Progress(WIP)

https://trello.com

https://trello.com/

55

http://www.mountaingoatsoftware.com/scrum/task-boards

Modelos Ágiles(Gestión y Seguimiento / Task Boards)


56http://www.mountaingoatsoftware.com/scrum/task-boards

Modelos Ágiles(Gestión y Seguimiento / Task Boards)


57

video recomendado(en ingles)

http://www.youtube.com/watch?v=Q5k7a9YEoUI

Hamid Shojaee

Scrum Master in Under 10 Minutes

http://www.youtube.com/watch?v=Q5k7a9YEoUI

58

http://lookforwardconsulting.com/2012/11/28/14-scrum-case-studies

algunoscasos de estudio

http://lookforwardconsulting.com/2012/11/28/14-scrum-case-studies

59

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

http://www.infoq.com/minibooks/kanban-scrum-minibook

Henrik Kniberg disponible en varios idiomas (español incluido)

descarga gratuita en:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

http://www.infoq.com/minibooks/kanban-scrum-minibook

60

Gracias

¡Gracias!

Technology

Clase 02 Scrum