UnaUna IntroducciónIntroducción a Scruma Scrum

Jorge Hernán Abad Londoño

jorge.abad@gmail.comAgosto 2009

AgendaAgenda

� Metodologías ágiles

� Historias de usuario� Historias de usuario

� Scrum

� El juego de la estimación

METODOLOGÍAS METODOLOGÍAS ÁGILESÁGILES

El Manifesto El Manifesto ÁgilÁgil –– unaunadeclaracióndeclaración de de valoresvalores

Procesos y

herramientas

Procesos y

herramientas

Individuos e

interacciones

Individuos e

interaccionessobre

herramientasherramientasinteraccionesinteraccionessobre

Documentación

exhaustiva

Documentación

exhaustiva

Software que

funciona

Software que

funcionasobre

Negociación de

contratos

Negociación de

contratos

Colaboración

con el cliente

Colaboración

con el clientesobre

Seguimiento

de un plan

Seguimiento

de un plan

Responder

ante el cambio

Responder

ante el cambiosobre

Fuente: www.agilemanifesto.org

contratoscontratoscon el clientecon el cliente

Algunos principios y valores ágilesAlgunos principios y valores ágiles

� La prioridad mayor es la satisfacción del cliente haciendo entregas continuas de software valioso para él

Los cambios son bienvenidos siempre� Los cambios son bienvenidos siempre

� La medida principal de progreso es el software funcionando

� El gestor es un facilitador no un controlador

� Equipos auto-organizados y multidisciplinares

� Inspeccionar y adaptar

� Mejora continua� Mejora continua

� Respeto, claridad y comunicación

� Ritmo sostenible

� La arquitectura y diseño emergen

Ágil no es hacer lo que se quieraÁgil no es hacer lo que se quiera

� … ni tampoco programación heroica

La magia no existeLa magia no existe� Ken Schwaber: “En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”

� Dan visibilidad y transparencia desde el principio, aunque no resuelven todos los problemas.

� No ser extremista, usar lo que te funcione

� Se recomienda primero usar todo, luego hacer � Se recomienda primero usar todo, luego hacer modificaciones. Cuidado con “Scrum but…”

HISTORIA DE HISTORIA DE USUARIOS USUARIOS

Fuente Wikipedia

Historias de UsuarioHistorias de Usuario� Una historia de usuario es una representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del o dos frases utilizando el lenguaje común del usuario. Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requerimientos (acompañadas de las discusiones con los usuarios y las pruebas de validación). Cada historia de usuario debe ser limitada, esta debería poderse escribir sobre una limitada, esta debería poderse escribir sobre una nota adhesiva pequeña. Dentro de la metodología XP las historias de usuario deben ser escritas por los clientes.

Historias de UsuarioHistorias de Usuario

� Las historias de usuario son una forma rápida de administrar los requerimientos rápida de administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rápidamente a los permiten responder rápidamente a los requerimientos cambiantes.

CaracterísticasCaracterísticas� Independientes unas de otras: De ser necesario, combinar las historias

dependientes o buscar otra forma de dividir las historias de manera que resulten independientes.

� Negociables: La historia en si misma no lo suficientemente explícita como para considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación.

� Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos más que para el desarrollador.

� Estimables: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Esto permite estimar el tiempo total del proyecto.total del proyecto.

� Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones sobre la planificación de un desarrollo iterativo. Generalmente se recomienda la consolidación de historias muy cortas en una sola historia.

� Verificables: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables. Cuando sea posible, la verificación debe automatizarse, de manera que pueda ser verificada en cada entrega del proyecto.

CaracterísticasCaracterísticas

� Si bien el estilo puede ser libre, la historia de usuario debe responder a tres de usuario debe responder a tres preguntas: ¿Quién se beneficia?, ¿qué se quiere? y ¿cuál es el beneficio? Por ello, algunos autores[1] recomiendan redactar las historias de usuario según el formato:

� Como (rol) quiero (algo) para poder (beneficio).

BeneficiosBeneficios� Al ser muy corta esta representa requisitos del modelo de negocio que pueden implementarse rápidamente (días o semanas)rápidamente (días o semanas)

� Necesitan poco mantenimiento� Mantienen una relación cercana con el cliente� Permite dividir los proyectos en pequeñas entregas

� Permite estimar fácilmente el esfuerzo de � Permite estimar fácilmente el esfuerzo de desarrollo

� Es ideal para proyectos con requerimientos volátiles o no muy claros

LimitacionesLimitaciones� Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones haciendo difícil utilizarlas como base para un contratoun contrato

� Se requiere un contacto permanente con el cliente durante el proyecto lo cual puede ser difícil o costoso

� Podría resultar difícil escalar a proyectos grandes� Requiere desarrolladores muy competentes � Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones haciendo difícil utilizarlas como base para un contratoun contrato

� Se requiere un contacto permanente con el cliente durante el proyecto lo cual puede ser difícil o costoso

� Podría resultar difícil escalar a proyectos grandes� Requiere desarrolladores muy competentes

SCRUMSCRUM

EstamosEstamos perdiendoperdiendo la la carreracarrera de de relevosrelevos

“En enfoque de ‘carrera de relevos’ en el

desarrollo de productos ... puede entrar en desarrollo de productos ... puede entrar en

conflicto con los objetivos de máxima

velocidad y flexibilidad. En su lugar, un

enfoque holístico o estilo ‘rugby’ - donde un

equipo intenta ir a la distancia como una

unidad, pasando la pelota hacia adelante y

hacia atrás -pueden servir mejor a los

Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review,January 1986.

hacia atrás -pueden servir mejor a los

actuales requisitos competitivos".

• Scrum es un proceso ágil que nos permite centrarnos

en ofrecer el más alto valor de negocio en el menor

tiempo.

Scrum en 100 palabras

tiempo.• Nos permite rápidamente y en repetidas ocasiones

inspeccionar software real de trabajo (cada dos semanas

o un mes).

• El negocio fija las prioridades. Los equipos se auto-

organizan a fin de determinar la mejor manera de

entregar las funcionalidades de más alta prioridad.entregar las funcionalidades de más alta prioridad.

• Cada dos semanas o un mes, cualquiera puede ver el

software real funcionando y decidir si liberarlo o seguir

mejorandolo en otro sprint.

� Scrum es una metodología para la gestión de proyectos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo The New New Product Development

SCRUMSCRUM

artículo The New New Product Development Game[Harvard Business Review Ene-Feb 1986] en el que ponen de manifiesto que:◦ El mercado competitivo de los productos tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad. ◦ Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas. importante en el volumen de negocio de las empresas. ◦ El mercado exige ciclos de desarrollo más cortos.

� El artículo compara al desarrollo tradicional de ciclo de vida formado por fases separadas y equipos especializados con las carreras de

SCRUMSCRUM

equipos especializados con las carreras de relevos, donde un equipo pasa el testigo al siguiente hasta finalizar el desarrollo del producto. Siguiendo el símil deportivo, se compara al nuevo modelo de desarrollo, basado en el solapamiento de las fases y en un único equipo multi-disciplinar, con la evolución del equipo multi-disciplinar, con la evolución del juego del rugby; y de él se toma el término scrum.

SCRUMSCRUM

� Nonaka y Takeuchi extraen las bases de scrum de las prácticas que observan en las empresas con buenos resultados de rapidez y flexibilidad en la producción:

SCRUMSCRUM

prácticas que observan en las empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard; y son:◦ Inestabilidad consustancial al entorno de desarrollo. ◦ Equipos auto-organizados. ◦ Solapamiento de las fases del desarrollo. ◦ Solapamiento de las fases del desarrollo. ◦ Multi-aprendizaje. ◦ Control sutil. ◦ Transferencia de aprendizaje a nivel organizacional.

SCRUMSCRUM

� Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.determinados sistemas de software.

� Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.

� La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:◦ Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados. ◦ Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.

◦ Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento.

◦ Reuniones:

� Planificación del sprint, Revisión diaria, Revisión del sprint.◦ Sprint

Orígenes de ScrumOrígenes de Scrum� Jeff Sutherland◦ Scrums iniciales en Easel Corp en 1993

◦ IDX 500 personas haciendo Scrum

� Ken Schwaber◦ ADM

◦ Se presenta Scrum en OOPSLA 96 con Sutherland

◦ Autor de tres libros sobre Scrum

� Mike Beedle◦ Patrones Scrum en PLOPD4◦ Patrones Scrum en PLOPD4

� Ken Schwaber and Mike Cohn◦ Fundaron conjuntamente la Scrum Alliance en 2002, inicialmente dentro de la Agile Alliance

Scrum ha Scrum ha sidosido utilizadoutilizado porpor::•Microsoft•Yahoo•Google

•Intuit•Nielsen Media•First American Real Estate•Google

•Electronic Arts•High Moon Studios•Lockheed Martin•Philips•Siemens

•First American Real Estate•BMC Software•Ipswitch•John Deere•Lexis Nexis•Sabre•Siemens

•Nokia•Capital One•BBC•Intuit

•Sabre•Salesforce.com•Time Warner•Turner Broadcasting•Oce

Scrum ha Scrum ha sidosido utilizadoutilizado parapara::� Software comercial

� Desarrollos internos

Desarrollos bajo Contrato

• Desarrollo de video juegos

• Sistemas críticos de soporte vital, aprobados por laFDA

� Desarrollos bajo Contrato

� Proyectos Fixed-price

� Aplicaciones Financieras

� Aplicaciones certificadas ISO 9001

� Sistemas Embebidos

vital, aprobados por laFDA

• Software de control satelital

• Sitios Web

• Software para Handheld

• Teléfonos portátiles

• Aplicaciones de Network switching

� Sistemas con requisitos 7x24 y 99.999% de disponibilidad

� Joint Strike Fighter

switching

• Aplicaciones de ISV

• Algunas de las más grandes aplicaciones en uso

CaracterísticasCaracterísticas� Es una de las metodologías ágiles� Equipos auto-organizados� Equipos auto-organizados

� El producto avanza en una serie de “Sprints" de dos semanas a un mes de duración

� Los requisitos son capturados como elementos de una lista de “Product Backlog"

� No hay prácticas de ingeniería prescritas� No hay prácticas de ingeniería prescritas

� Utiliza normas generativas para crear un entorno ágil para la entrega de proyectos

� Uno de los “procesos ágiles”

NivelNivel de de ruidoruido de un de un proyectoproyecto

Lejos de

Complejo

AnarquíaR

eq

uis

ito

sLejos de Acuerdo

Fuente: Strategic Management and Organizational Dynamics by Ralph

Simple

Tecnología

Re

qu

isito

s

Cerca deAcuerdo

Ce

rca

de

Ce

rte

za

Le

jos d

eC

ert

eza

Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

ScrumScrum

Sprint

24 horas

Return

Sprint

2-4 semanasObjetivo del Sprint

Sprint

BacklogIncremento del producto

potencialmente entregable

Cancel

Gift wrap

Product

Backlog

Poniendo todo juntoPoniendo todo junto

Imagen disponible en

www.mountaingoatsoftware.com/scrum

SprintsSprints

� En Scrum los proyectos avanzan en una serie de “Sprints”de “Sprints”◦ Análogo a las iteraciones en XP

� La duración típica es 2–4 semanas o alo sumo un mes calendario

� La duración constante conduce a un mejor ritmoritmo

� El product es diseñado, codificado y testeado durante el Sprint

Desarrollo secuencial vs. Desarrollo secuencial vs. superpuestosuperpuesto

Requisitos Diseño Código Test

En lugar de hacer todo

de una cosa a la vez ... ...los equipos Scrum hacen un poco de todo todo el tiempo

Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

todo el tiempo

No hay No hay cambioscambios en un sprinten un sprint

Cambios

� Planee la duración del sprint en torno a cuánto tiempousted puede comprometerse a mantener los cambiosfuera del sprint

Scrum FrameworkScrum Framework

•Product owner

•ScrumMaster

Roles

•ScrumMaster

•Team

•Sprint planning

•Sprint review

•Sprint retrospective

•Daily scrum meeting

Reuniones

•Product backlog

•Sprint backlog

•Burndown charts

Artefactos

Scrum frameworkScrum framework

•Product owner

•ScrumMaster

Roles

•Sprint planning

•Sprint review

•Sprint retrospective

•Daily scrum meeting

Reuniones

•ScrumMaster

•Team

•Product backlog

•Sprint backlog

•Burndown charts

Artefactos

Product OwnerProduct Owner

� Define las funcionalidades del producto

� Decide sobre las fechas y contenidos de los releases

� Es responsable por la rentabilidad del producto (ROI)

� Prioriza funcionalidades de acuerdo al valor del mercado/negocio

� Ajusta funcionalidades y prioridades en cada iteración� Ajusta funcionalidades y prioridades en cada iteraciónsi es necesario

� Acepta o rechaza los resultados del trabajo del equipo

El ScrumMasterEl ScrumMaster

� Representa a la gestión del proyecto

� Responsable de promover los valores y prácticas � Responsable de promover los valores y prácticas de Scrum

� Remueve impedimentos

� Se asegura de que el equipo es completamente funcional y productivo

� Permite la estrecha cooperación en todos los � Permite la estrecha cooperación en todos los roles y funciones

� Escudo del equipo de interferencias externas

El TeamEl Team� Típicamente de 5 a 9 personas

� Multi-funcional:Multi-funcional:◦ Programadores, testers, analistas, diseñadores, etc.

� Los miembros deben ser full-time◦ Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)

� Los equipos son auto-organizativos◦ Idealmente, no existen títulos pero a veces se utilizan de acuerdo a la organizaciónla organización

� Solo puede haber cambio de miembros entre los sprints

•Product owner

•ScrumMaster

Roles

Scrum FrameworkScrum Framework

•ScrumMaster

•Team

•Sprint planning

•Sprint review

•Sprint retrospective

•Daily scrum meeting

Reuniones

•Product backlog

•Sprint backlog

•Burndown charts

Artefactos•Daily scrum meeting

Sprint Planning meeting

Priorización

• Analizar y evaluar el Product ObjetivoObjetivo

Capacidaddel EquipoCapacidaddel Equipo

Product Product • Analizar y evaluar el Product

Backlog

• Seleccionar el objetivo del Sprint

Planificación

• Decidir como alcanzar el objetivo

del Sprint (diseño)

• Crear el Sprint Backlog (tareas)

Objetivodel SprintObjetivo

del Sprint

SprintSprint

Condiciones del

Negocio

Condiciones del

Negocio

Product BacklogProduct Backlog

ProductoProducto • Crear el Sprint Backlog (tareas)

en base a los temas del Product

Backlog (user stories / features)

• Estimar Sprint Backlog en horas

Sprint

Backlog

Sprint

Backlog

TecnologíaTecnología

ProductoActual

ProductoActual

Planificación del SprintPlanificación del Sprint� El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar

� Se crea el Sprint Backlog� Se crea el Sprint Backlog◦ Se identifican tareas y cada una es estimada (1-16 horas)

◦ Realizado colaborativamente, no solo por el ScrumMaster

� El diseño de Alto Nivel es considerado

COMO planificadorde vacaciones, YOCOMO planificadorde vacaciones, YO

Codificar la capa intermedia (8 hs)COMO planificadorde vacaciones, YOQUIERO ver fotosde los hoteles.

COMO planificadorde vacaciones, YOQUIERO ver fotosde los hoteles.

Codificar la capa intermedia (8 hs)

Codificar la interfaz de usuario (4)

Escribir los test fixtures (4)

Codificar la clase foo (6)

Actualizar test de performance (4)

Daily ScrumDaily Scrum

� Parámetros◦ Diaria◦ Diaria

◦ Dura 15 minutos

◦ Parados

� No para la solución de problemas◦ Todo el mundo está invitado◦ Todo el mundo está invitado

◦ Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar

◦ Ayuda a evitar otras reuniones innecesarias

TodosTodos respondenresponden 3 3 preguntaspreguntas

¿Qué hiciste ayer?¿Qué hiciste ayer?11

¿Qué vas a hacer hoy?¿Qué vas a hacer hoy?22

¿Hay obstáculos en tu camino?¿Hay obstáculos en tu camino?33

� No es dar un status report al Scrum Master� Se trata de compromisos delante de pares

¿Hay obstáculos en tu camino?¿Hay obstáculos en tu camino?

Sprint reviewSprint review� El equipo presenta lo realizado durante el sprint

� Normalmente adopta la forma de una demo de las nuevas características o la arquitecturasubyacente

� Informal

◦ Regla de 2 hs preparación

◦ No usar diapositivas◦ No usar diapositivas

� Todo el equipo participa

� Se invita a todo el mundo

Sprint retrospectiveSprint retrospective� Periódicamente, se echa un vistazo a lo que funciona y lo que no

� Normalmente 15 a 30 minutos

� Se realiza luego de cada sprint

� Todo el equipo participa

◦ ScrumMaster

◦ Product owner◦ Product owner

◦ Equipo

◦ Posiblemente clientes y otros

Start / Stop / ContinueStart / Stop / Continue

� Todo el equipo se reúne y discute lo que les gustaría:gustaría:

Comenzar a hacerComenzar a hacer

Dejar de hacerDejar de hacer

Esto es sólo una

Continuar haciendoContinuar haciendoEsto es sólo una de las muchas maneras de hacer una

retrospectiva.

•Product owner

•ScrumMaster

Roles

Scrum frameworkScrum framework

•ScrumMaster

•Team

•Sprint planning

•Sprint review

•Sprint retrospective

•Daily scrum meeting

Reuniones

•Product backlog

•Sprint backlog

•Burndown charts

Artefactos

Product BacklogProduct Backlog

� Los requisitos

� Una lista de todos los trabajos � Una lista de todos los trabajos deseados en el proyecto

� Idealmente cada tema tiene valor para el usuarios o el cliente

� Priorizada por el Product OwnerOwner

� Repriorizada al comienzo de cada Sprint

Este es el

product backlog

Este es el

product backlog

EjemploEjemplo de Product Backlogde Product BacklogBacklog item Estimación

Permitir que un invitado a hacer una reserva. 3Permitir que un invitado a hacer una reserva. 3

Como invitado, quiero cancelar una reserva. 5

Como invitado, quiero cambiar las fechas de

una reserva.3

Como un empleado de hotel, puedo ejecutar

informes de los ingresos por habitación 8informes de los ingresos por habitación

disponible

8

Mejorar el manejo de excepciones 8

... 30

... 50

EjemploEjemplo de Product Backlogde Product Backlog

El objetivo del SprintEl objetivo del Sprint� Una breve declaración de cual será el foco del trabajo durante el sprint trabajo durante el sprint

Aplicación con B.Datos

Ciencias Biológicas

Funciones de apoyo técnico

necesarios para estudios de

genética de poblaciones.

Hacer que la aplicación se

ejecute en SQL Server, además

de Oracle. Servicios Financieros

Soportar más indicadores

técnicos que la empresa ABC en

tiempo real y streaming de datos.

de Oracle.

GestiónGestión del Sprint Backlogdel Sprint Backlog� Los individuos eligen las tareas � El trabajo nunca es asignado� La estimación del trabajo restante es actualizada� La estimación del trabajo restante es actualizadadiariamente

� Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog

� El trabajo para el Sprint emerge� Si el trabajo no está claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo y Backlog con una mayor cantidad de tiempo y subdividirla luego.

� Actualizar el trabajo restante a medida de que más se conoce

EjemploEjemplo de Sprint Backlogde Sprint Backlog

Tareas L M M J V

Codificar UI

Codificar negocio

Testear negocio

Escribir ayuda online

Escribir la clase foo

8

16

8

12

8

4

12

16

8

4

11

8

8

8

8

10

16

8Escribir la clase foo 8 8 8

4

8

Agregar error logging

8

8

EjemploEjemplo de Sprint Backlogde Sprint Backlog

SeguimientoSeguimiento� Es recomendable, que el propietario del producto emplee una hoja de cálculo, alguna herramienta similar, o el soporte de una intranet, para guardar en similar, o el soporte de una intranet, para guardar en formato digital la pila del producto.

� Pero no es aconsejable emplearla como base para trabajar sobre ella en la reunión proyectándola sobre la pantalla de la sala.

� Es mucho mejor trabajar y manipular elementos � Es mucho mejor trabajar y manipular elementos físicos; y usar una pizarra y fichas removibles (adhesivas, con chinchetas o magnéticas).

Tablero de trabajoTablero de trabajo

Un área superior donde el Scrum Manager coloca al principio de lareunión la capacidad real del sprint a 3, 4 y 5 semanas (A); y al final (D),las notas con: el objetivo establecido, duración del sprint,funcionalidades de la pila del producto comprometidas, hora fijada paralas reuniones diarias y fecha prevista para la reunión de revisión delsprint.

B.- Una franja para ordenar los elementos de la pila del producto de mayor a menor prioridad.

C.- Una franja paralela para descomponer cada elemento de la pila del producto en las correspondientes tareas de la pila del sprint.

PruductoPruducto

SprintSprint

Objetivo del sprintObjetivo del sprint

Otra forma de ver el tablero de Otra forma de ver el tablero de mandomando

Otra forma de ver el tablero de Otra forma de ver el tablero de mandomando

RecordemosRecordemos

Un Sprint Un Sprint BurndownBurndown ChartChartH

ou

rs

Tareas

Codificar UI

Codificar Negocio

Testear Negocio

Escribir ayuda online

L

8

16

8

12

M M J V

4

12

16

7

11

8

10

16 8H

ou

rs

40

30

Escribir ayuda online 12

50

Ho

urs

20

10

0Mon Tue Wed Thu Fri

EscalabilidadEscalabilidad� Normalmente los equipos son de 7 ± 2 personas

◦ La escalabilidad proviene de equipos de equipos

� Factores a tener cuenta

◦ Tipo de aplicación

◦ Tamaño del equipo

◦ Dispersión del equipo◦ Dispersión del equipo

◦ Duración del proyecto

� Scrum se ha utilizado en múltiples proyectos de más de 500 personas

Expansión a través de Scrum de Expansión a través de Scrum de scrumsscrums

Scrum de scrums de scrumsScrum de scrums de scrums

Scrum of Scrums / MetaScrum of Scrums / Meta--ScrumScrumS

cru

mS

cru

m

EL JUEGO DE LA EL JUEGO DE LA ESTIMACIÓNESTIMACIÓN

PokerPoker GameGame� Planificación de póquer es una variación del método Delphi.

� Es simple, se burla y los resultados de estim

� Planificación de póquer se utiliza para estimar el esfuerzo o el tamaño relativo de las tareas en el desarrollo de software de manera fiable.

� Los miembros del equipo del proyecto se reúnen y en unas pocas rondas mediante el Poker Game llegan en unas pocas rondas mediante el Poker Game llegan a un consenso sobre el tamaño de cada tema o tarea.

La baraja de CartasLa baraja de Cartas� Cada juevo de cartas incluye los números 0, (0,5), 1, 2, 3, 5, 8, 13, 20, 40, 100, y, a veces, un café tarjeta. 100, y, a veces, un café tarjeta.

� Cada miembro del equipo necesita una baraja de cartas

La La reuniónreunión de de planificaciónplanificación (1)(1)

� Al comienzo de la planificación de póquer, cada estimador se le da un mazo de cartas.cada estimador se le da un mazo de cartas.

� Para cada Historia de Usuario o tema que se va a estimar, un moderador lee la descripción.

� El moderador suele ser el propietario del producto o una analista. Sin embargo, el moderador puede ser cualquier persona, ya moderador puede ser cualquier persona, ya que no hay privilegio especial asociado con el papel.

La La reuniónreunión de de planificaciónplanificación (2)(2)� El Dueño del producto (Product Owner) responde todas las preguntas que tienen los estimadores.

� Después de todas las preguntas cada estimador � Después de todas las preguntas cada estimador selecciona una carta de forma secreta e individual.

� Las tarjetas no se muestran hasta que todos hayan hecho su estimación. Luego todos muestran al mismo tiempo la carta elegida

� El grupo puede discutir la historia y sus estimaciones durante unos minutos más. Principalmente se indaga a las personas que están lejanas de la media que a las personas que están lejanas de la media que explique su posición.

� Tras el debate se hace otra ronda de estimacion en privado.

La La reuniónreunión de de planificaciónplanificación (3)(3)

� Valores altos de tiempo implican ◦ Baja granularidad◦ Baja granularidad

◦ Alta complejidad

◦ � se recomienda en lo posible dividir en tareas más pequeñas.

� Si sale (?) Implica que no se tiene idea de que se esta hablandoque se esta hablando

� Si sale la taza de café, indica que la persona esta casada.

ResultadosResultados

� En muchos casos, las estimaciones convergen en la segunda ronda. En caso convergen en la segunda ronda. En caso contrario se debe repetir el proceso.

� El objetivo es converger a una única estimación.

Donde seguir?Donde seguir?

� www.mountaingoatsoftware.com/scrum

� www.scrumalliance.org� www.scrumalliance.org

� www.controlchaos.com

� scrumdevelopment@yahoogroups.com

UnaUna listalista de de lecturaslecturas sobresobre ScrumScrum� Agile and Iterative Development: A Manager’s Guide by Craig Larman

� Agile Estimating and Planning by Mike Cohn

� Agile Project Management with Scrum by Ken Schwaber

� Agile Retrospectives by Esther Derby and Diana Larsen

� Agile Software Development Ecosystems by Jim Highsmith

� Agile Software Development with Scrum by Ken Schwaber and Mike Beedle

� Scrum and The Enterprise by Ken Schwaber

� User Stories Applied for Agile Software Development by Mike Cohn

� Artículos semanales en www.scrumalliance.org

AvisoAviso de Copyrightde Copyright� Usted es libre de:

◦ Compartir- copiar, distribuir y trasmitir el trabajo

◦ Modificar- adaptar el trabajo

� Bajo las siguientes condiciones◦ Atribución. Ud. debe atribuir el trabajo en la manera especificada

por el autor o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo).

� Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales

� Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor.

� Para más información ver http://creativecommons.org/licenses/by/3.0/

Información de ContactoInformación de Contacto

Presentado por: Mike Cohn

mike@mountaingoatsoftware.com

Presentado por: Mike Cohn

mike@mountaingoatsoftware.comm

www.mountaingoatsoftware.com

(720) 890-6110 (office)

m

www.mountaingoatsoftware.com

(720) 890-6110 (office)

Tomado de:Tomado de:

� Una introducción a Scrum - Ernesto Grafeuille. Grafeuille.