_SCRUM-Resumen Libro (ESP)

8/2/2019 _SCRUM-Resumen Libro (ESP)

1/65

SCRUM


2/65

ndice de contenido

1 - Introduccin ........................................................................................................................................3

1.1 - Que es Scrum? ...................................................................................................................... ....3

1.2 - Por qu fracasan los proyectos? ................................................................................................4

1.3 - Que aporta Scrum al equipo? ............................................................................................... ....5

1.4 - Que aporta Scrum a la empresa? ..............................................................................................5

1.5 - Quin usa Scrum? .....................................................................................................................6

1.6 - Qu NO es Scrum? ...................................................................................................................6

1.7 - Problemas para Scrum ................................................................................................................7

1.8 - Para qu estudiar este curso? ....................................................................................................7

2

1 Introduccin


3/65

1 Introduccin

Se van a ver envueltos en el estudio del complejo mundo de la gestin de proyectos y de

las metodologas de produccin.

La mayora de las veces, por desconocimiento o por desinters, la gestin se suele sentir

como el proceso de papeleo que se debe de realizar en un proyecto sea cual fuere su

naturaleza, mientras que la metodologa puede parecer ese ritual que intenta hacernos ms

rentables de cara a la empresa.

Veremos que puede ser un arte y una filosofa de vida, e incluso como podemos

divertirnos con esto.

1.1 Que es Scrum?

La palabra Scrum es un trmino utilizado en rugby para restablecer la unin despus de

una interrupcin. El alma de ese significado tiene mucho que ver con lo que a partir de

estos momentos vamos a comenzar a aprender.

Scrum es una metodologa para la gestin gil de proyectos.

Apenas hemos comenzado y ya estamos hablando de cosas que nos pueden resultar poco

familiares: gestin de proyecto y gestin gil.

La gestin de proyectos trata la organizacin y administracin los recursos involucrados

en un proyecto, concepto que se estudia clsicamente como un esfuerzo temporal y

progresivo (a veces tambin nico) para la creacin de un producto o servicio. Esa

organizacin y administracin se lleva a cabo normalmente por el jefe de proyecto, que es

el responsable ltimo ante la empresa (que suele ser el hbitat natural de los proyectos) de

que se acaba en el tiempo acordado, con los costes definidos previamente y con la idea de

producto o servicio que se haba planteado. Esta gestin se puede complicar tanto como se

quiera, imponiendo complicadas medidas para la concesin de presupuestos, las

especificaciones formales de los requerimientos del cliente ... que es lo que se ha venido

conociendo como gestin clsica de proyectos.

3


4/65

La gestin gil de proyectos intenta evitar todo ese engorro y enfocarse a la gente que

participa en el proyecto y a los resultados.

Scrum es joven: nace en 1986 propuesto por Hirotaka Takeuchi e Ikujiro Nonaka debido a

los nuevos requerimientos del mercado y a los contantes cambios. A pesar de su tierna

edad Scrum ha cosechado infinidad de seguidores debido a su enorme potencial que iran

descubriendo a lo largo de este curso.

Se suele identificar la gestin gil de proyectos, y Scrum en particular con el desarrollo de

software; aunque es cierto que se ha expandido su uso especialmente en este sector es

importante decir que Scrum es una metodologa de gestin de proyectos en general, y que

por sus bondades es sinceramente til en los proyectos tecnolgicos, por que permite

adaptarse a cambios incesantes.

Scrum es libre: puedes utilizar Scrum cuando y donde te plazca, sin pagar cuotas y sin

miedo de la presencia de la Polica-Scrum por tu inexactitud en su aplicacin, puedes

escribir sobre l ya sea bien o mal y usar todo o parte. Existe una organizacin que expide

certificaciones de Scrum (http://www.scrumalliance.org/). Ahora tambin debes de saber

que si no ests familiarizado con la gestin gil o simplemente con la gestin de proyectos

se recomienda el seguimiento bastante estricto esta metodologa.

1.2 Por qu fracasan los proyectos?

La verdad es que la mayora de los proyectos fracasan y las razones principales suelen ser:

Las estimaciones que se hacen no son correctas.

Nadie puede predecir los impedimentos que surgirn en un proyecto.

Los objetivos no estn claros y definidos desde el comienzo.

Se realizan cambios constantemente que afectan al proyecto.

El trabajador no sabe como llevar a cabo lo que le piden.

El cliente no tiene realmente claro lo que quiere.

4


5/65

Todo esto hace que:

No se cumplan los compromisos.

No haya visibilidad (visin general clara) del proyecto.

Toda la responsabilidad caiga exclusivamente sobre el jefe de proyecto.

1.3 Que aporta Scrum al equipo?

Para que el proyecto triunfe y evitar todo lo anterior Scrum nos ofrece una serie de

ventajas:

Funciona bien con requisitos indefinidos y cambiantes. Funciona bien con los impedimentos.

Permite obtener el mximo rendimiento por el mismo esfuerzo.

Permite controlar productos o servicios muy complejos.

Incrementa la sensacin de urgencia e inmediatez, evitando el sndrome de

estudiante o quedarse dormido en los laureles.

1.4 Que aporta Scrum a la empresa?

El beneficio que puede obtener una empresa/directivo/comercial del uso de Scrum es

inmenso e impagable. Scrum puede aportar lo que todo empresario suea:

Poder prometer un buen producto en fecha y costes (y cumplir con ello).

Poder tener una visibilidad diaria del progreso del proyecto.

Poder tener una plantilla con productividad y moral alta.

Poder reducir la carga de la gestin del proyecto.

Mejorar el retorno de la inversin (ROI Return Of Investiment).

5


6/65

1.5 Quin usa Scrum?

Actualmente existen aproximadamente unos 300.000 equipos usando Scrum cada da en

empresas de xito y en proyectos sumamente importantes.

Algunos ejemplos:

1.6 QuNO es Scrum?

Scrum no es una varita mgica ni la piedra filosofal.

No se crea que por el simple hecho de usar Scrum su vida ser ms alegre y sus proyectos

grandes xitos. Scrum es simplemente una forma eficaz de organizar el trabajo y mejorar

las comunicaciones y relaciones del equipo, al mismo tiempo es eficaz para el

cumplimiento de objetivos. Es rpido y divertido.

6


7/65

1.7 Problemas para Scrum

Algunas de las trabas con la que te puedes encontrar a la hora de implantar Scrum son:

Compaeros obstruccionistas o malintencionados.

Corporaciones desorganizadas.

Entornos de excesiva burocracia.

Falta de autoridad.

Direccin no comprometida con los objetivos y/o medios.

Clientes conflictivos.

1.8 Para questudiar este curso?

Con respecto a Scrum:

Comprender Scrum.

Conocer los roles y procesos.

Aprender cmo implementar Scrum.

En el mbito personal:

Coger ideas para mejorar nuestro trabajo diario.

Aprovecharnos de las experiencias de los dems.

Detectar los aspectos de mejora

Tener otro punto de vista de los proyectos y los problemas

7


8/65

REFERENCIAS

Desarrollo gil de software

http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software

Scrum en la wikipedia

http://es.wikipedia.org/wiki/Scrum

Scrum Alliance

http://www.scrumalliance.org/

Introduccin a Scrum

http://www.chuidiang.com/ood/metodologia/scrum.php

Portal de gestin de proyectos

http://www.navegapolis.net/

8
http://es.wikipedia.org/wiki/Desarrollo_?gil_de_softwarehttp://es.wikipedia.org/wiki/Scrumhttp://www.scrumalliance.org/http://www.chuidiang.com/ood/metodologia/scrum.phphttp://www.navegapolis.net/http://es.wikipedia.org/wiki/Scrumhttp://www.scrumalliance.org/http://www.chuidiang.com/ood/metodologia/scrum.phphttp://www.navegapolis.net/http://es.creativecommons.org/http://es.wikipedia.org/wiki/Desarrollo_?gil_de_software


9/65

ndice de contenido

2 - Gestin de proyectos ...........................................................................................................................3

2.1 - Qu es un proyecto? ..................................................................................................................3

2.2 - Entorno de los proyectos ............................................................................................................4

2.3 - Para qu gestionar proyectos? ...................................................................................................4

2.4 - La realidad de la gestin de proyectos ............................................................................ ........ ...4

2.5 - El xito de los proyectos .................................................................................................... ........5

2.6 - Por qu se fracasa? ................................................................................................................. ..5

2.7 - La idea popular de la gestin de proyectos .................................................................... ........ ....6

2

2 Gestin de proyectos


10/65

2 Gestin de proyectos

Como vimos en el captulo anterior debemos de seguir una serie de controles para el xito

de un proyecto. Esos controles nos permitirn tener una visibilidad completa del proyecto

y organizar los recursos y las actividades.

Como se coment en la introduccin la gestin de proyectos clsica puede llegar a

complicar esta tarea de sobremanera, sin embargo Scrum nos permite realizar esta labor

de una manera mucho ms grata.

En este captulo veremos someramente algunos conceptos necesarios de gestin de

proyectos, pero ajustndonos a los que nos sern de utilidad para Scrum

2.1 Ques un proyecto?

Intuitivamente podemos comprender un proyecto como una serie de actividades

interrelacionadas, con una fechas de inicio y fin claramente determinadas y que emplean

una serie de recursos para lograr un objetivo definido.

Las actividades son las tareas que debemos de realizar para conseguir el objetivo

deseado. Por ejemplo para pintar una pared las actividades podran ser: proteger

mobiliario, ventanas y suelos, dar una primera

capa y dar una segunda capa. Para cada actividad

debemos de tener en cuenta el tiempo y la

prioridad.

Los recursos son los elementos necesarios para

poder llevar a cabo cada una de las tareas. En el

ejemplo anterior podran ser: rodillo, cubeta y pintura. Segn el autor y la metodologa se

incluyen aqu los recursos humanos necesarios.

3


11/65

2.2 Entorno de los proyectos

Las organizaciones de hoy en da no fabrican productos, si no que desarrollan proyectos.

Pero a qu es debido esto?

El entorno es dinmico.

Los mercados son cambiantes.

Se necesita adaptacin constante.

Se piden reacciones rpidas.

Se trabaja con crecimiento exponencial.

La competencia es creciente.

Suelen existir varias lneas de negocio abiertas.

La omnipresente necesidad de recortar costes y gastos.

Se debe poseer un visin global del trabajo en curso.

2.1 Para qugestionar proyectos?

La importancia de la gestin de proyectos radica en lo siguiente:

Dar una respuesta rpida.

Maximizar la capacidad de la organizacin.

Coordinar recursos internos y externos.

Extraer informacin de una visin global.

Aprender lecciones de experiencias pasadas

para la mejora continua.

2.2 La realidad de la gestin de proyectos

Extraamente lo que se ve en la mayora de las empresas y proyectos es:

Nombramiento accidental de jefes de proyecto. No suele ser vocacional ni estar

formado convenientemente.

Ausencia de metodologa definida y homognea.

4


12/65


13/65

Cambios: los cambios no suelen ser bien aceptados.

Planificacin: una mala planificacin puede arruinar un proyecto.

Metodologa: debe de existir un modo de trabajo comn o entendido.

Visibilidad: tener una visin general clara y real del estado actual del proyecto nos

permitir tomar las acciones pertinentes en caso de ser necesario.

2.5 La idea popular de la gestin de proyectos

La gestin de proyectos se suele ver como:

Papeleo y burocracia. Parlisis por el anlisis

Los presupuestos siempre se exceden, las planificaciones son para inclumplirlas

Auditora, control y acusacin de los que no cumplen

En el siguiente captulo veremos como Scrum puede cambiar ese concepto gracias a su

sencillez y dinamismo.

6


14/65

ndice de contenido

3 - Scrum: roles y procesos ......................................................................................................................3

3.1 - Scrum de un vistazo ................................................................................................................ ...3

3.2 - Conceptos clave de Scrum .................................................................................................... .....4

3.3 - Roles en Scrum .................................................................................................................... ......5

3.4 - Artefactos ............................................................................................................................... ....7

2

3 Scrum: roles y procesos


15/65

3 Scrum: roles y procesos

3.1 Scrum de un vistazo

El siguiente grfico resume todo el proceso de Scrum:

Aunque lo iremos viendo en el transcurso del curso ms detalladamente los procesos o

artefactos que intervienen en Scrum son:

Pila de producto: es una lista ordenada por prioridad de caractersticas o hitos

que se quieren alcanzar en el proyecto. Por ejemplo: hacer una publicacin sobre

los datos de la empresa en 2007.

Pila de Sprint: veremos que cuando aplicamos Scrum creamos intervalos de

tiempo de entre 2 y 4 semanas. En ese tiempo se tiene que acabar el trabajo que

tengamos en la pila de sprint, que es tomar de la pila de producto ordenadamente

los hitos que creemos que podemos hacer en esas 2-4 semanas y descomponerlo

en tareas de un mximo de 2 das, para cada tarea anotaremos el tiempo que

creemos que vamos a tardar en completarla. Por ejemplo: referido al elemento de

la pila de producto antes mencionado tendramos 1.- hacer un boceto (8 horas), 2.-

redactar el contenido I (2 das), redactar el contenido II (2 das), 3.- solicitar

presupuestos (6 horas), 4.- evaluar las muestras (4 horas).

3


16/65

Scrum diario: cada da el equipo debe reunirse para informar de los avances del

da anterior y de las tareas que va a acometer ese da. Tambin se expondrn aqu

los problemas que hayan surgido. Reunin de un mximo de 15 minutos (recordar

que esto es una metodologa gil).

Producto: al final del tiempo del sprint debemos de tener algo tangible, aunque

sea poco. Algo que se pueda ensear para hacer una demo/presentacin.

3.2 Conceptos clave de Scrum

Se propone la siguiente lista que se debe tener presente sobre Scrum. Puede que haya

trmino que todava no hemos tratado, pero esta tabla ser una referencia que

consultaremos con frecuencia.

1. NO es una varita mgica.

2. Scrum es sencillo, que no quiere decir fcil. Es sencillo de comprender y empezar

a utilizar pero es duro cumplir todo lo que nos requiere.

3. Se necesita la implicacin del cliente. La relacin con el cliente es mucho ms

estrecha y estar al tanto en cada momento de la evolucin del proyecto, de los

problemas, podr realizar cuantos cambios desee y solucionar las dudas que

puedan surgir.

4. El producto final es la medida del progreso.

5. En Scrum mediremos lo que nos queda, no lo que llevamos hecho. Nuestro

objetivo es acabar el sprint a tiempo, con los hitos que nos hemos marcado y con

un producto final que se puede ensear; si miramos atrs ser para lamentarnos o

alabarnos.

6. El equipo es autosuficiente, se autogestiona, se autodisciplina y responde del

proyecto. En Scrum se olvida un poco la idea de jefe: bueno para el empleado y

bueno para el responsable. Lo importante es la gente.

7. Scrum es incremental e iterativo. Un sprint tras otro y nuevos hitos que cumplir.

8. Hay un control diario (Scrum diario). Esto es el corazn de Scrum.

4


17/65

9. Slo el equipo puede manipular la pila del sprint. Nadie ajeno al equipo puede

llevar a cabo esta tarea. NUNCA se interrumpe un sprint.

10. Slo el dueo del producto maneja la pila del producto. l es el que paga y el

nico que realmente sabe lo que quiere.

11. Los sprints tienen una duracin fija. Una vez que el equipo defina cuanto dura el

sprint (un nmero de das entre 14 y 28) y se sienta cmodo con l no se debe

variar esa cantidad.

12. Retrospectivas. Tan slo echaremos la vista atrs una vez acabado el sprint para

detectar problemas y errores que han sucedido.

13. Es importante definir que significa que una tarea o hito est terminado. Ej: la

ropa estar lavada cuando la hayamos puesto en la lavadora con un programa

adecuado, se haya secado, est planchado y en su armario correspondiente.

14. Y por encima de todo ... TIME BOXED. Todo tiene que estar estimado

temporalmente y debemos ajustarnos a esas estimaciones. Se suele usar reloj

contador, tipo reloj de cocina.

A muchas personas esto le parecen las reglas de un juego, y en parte es as, ya que Scrum

sigue la mxima de queLa diversin es productiva.

3.3 Roles en Scrum

Aunque originalmente siempre se habla de roles en Scrum de lo que se pretende hablar

con este trmino es de responsabilidades ms que de papeles.

Existen tres roles principales en Scrum:

Dueo de producto

Recopila las especificaciones del producto.

Gestiona la visin.

Prioriza y gestiona la pila del producto.

Acepta las entregas/demo/presentacin.

5


18/65

Gestiona el roadmap.

Es el responsable econmico.

ScrumMaster o ScrumManager

Es el perro pastor de Scrum.

Es un miembro del equipo.

Trabaja con el dueo del producto.

Es el que elimina los impedimentos.

Debe de mantener el proceso en marcha.

Es el puente de la organizacin con Scrum.

Mejora la vida del equipo, promociona la creatividad y la autogestin.

Es el entrenador de Scrum del equipo.

Equipo

Estiman el esfuerzo necesario y el tamao de la pila de Sprint.

Tienen que estar comprometidos con la

entrega de un producto comercializable.

Reportan su progreso (junto al

ScrumMaster)

Debe de ser autnomo, autogestionado

pero responsable ante el dueo del

producto

7 3 personas

Implicacin.

Cuando leemos literatura de Scrum solemos ver referencias a gallinas y cerdos. Estos

personajes se utilizan como metfora del compromiso adquirido en el proyecto. Esto

proviene de una pequea historia en la que un cerdo y una gallina deciden abrir un

restaurante y la gallina propone llamarle Huevos y jamn, el cerdo lo rechaza

explicando que mientras l estar realmente comprometido la gallina solo estar

implicada. Es muy importante que todo el equipo est comprometido con la entrega, para

tener todos la misma responsabilidad y tirar unos de otros.

6


19/65

3.4 Artefactos

Los artefactos son los documentos no convencionales que deben de formar parte del

proceso de Scrum.

Pila de producto

Contiene todas las funcionalidades a desarrollar

Deben de estar priorizadas y

estimadas temporalmente

Pila de Sprint

Es un subconjunto de la pila de

producto

Seleccin de funcionalidades que se

realizarn en el siguiente sprint

Se subdividen en tareas (max. 16

horas 2 das)

Deben de realizar un producto

potencialmente usado

Scrum se basa en la sencillez y en la agilidad. Es por eso que en muchos sitios veran que

los equipos que usan Scrum utilizan post-its, no deben despreciar esta potente

herramienta con la que se consigue una eficacia difcilmente alcanzable de otra forma.

Los post-its se pueden utilizar sin depender de la tecnologa (aunque nos quedemos sin

luz podemos seguir trabajando), permiten clarificar las prioridades de las tareas,

fortalecen la coherencia del equipos, se pueden desplazar fcilmente y son muy

impactantes visualmente.

Cmo usarlos? Muy fcil, para la pila de producto se debe de escribir en el post-it la

caracterstica o funcionalidad de la que se quiere dotar al proyecto. La prioridad la

obtendremos desplazando hacia arriba el post-it, de manera que el primero por arriba ser

el ms importante. Para la pila de Sprint aadiremos en la parte superior del post-it una

estimacin en horas. Si esa estimacin es superior a 16 horas debemos de descomponer

ese post-it en tareas para que no haya ninguna de ms de 16 horas.

7


20/65

REFERENCIAS

Resumen de Scrum de Juan Palacio (Castellano)

www.navegapolis.net/files/presentaciones/scrum_general_10.pdf

El modelo Scrum por Juan Palacio (Castellano)

http://www.navegapolis.net/content/view/466/91/

Experiencias de un proyecto que usa Scrum (Castellano)

http://eskasiunblog.blogspot.com/search/label/SCRUM

Podcast sobre Scrum (Ingls)

http://se-radio.net/podcast/2007-06/episode-60-roman-pichler-scrum

Plantilla Scrum para Excel


Implementing Scrum (Ingls)

http://www.implementingscrum.com/es/

Implementing Scrum (Castellano)

http://www.implementingscrum.com/es/

Libro: Scrum and XP from the trenches (Ingls)

http://vetepensandolo.files.wordpress.com/2008/01/scrumandxpfromthetrenchesonline07-

31.pdf

Video de un curso de Scrum en las oficinas de Google (Ingls)

http://es.youtube.com/watch?v=IyNPeTn8fpo

8
http://www.navegapolis.net/files/presentaciones/scrum_general_10.pdfhttp://www.navegapolis.net/content/view/466/91/http://eskasiunblog.blogspot.com/search/label/SCRUMhttp://se-radio.net/podcast/2007-06/episode-60-roman-pichler-scrumhttp://www.navegapolis.net/content/view/268/60/http://www.implementingscrum.com/es/http://www.implementingscrum.com/es/http://vetepensandolo.files.wordpress.com/2008/01/scrumandxpfromthetrenchesonline07-31.pdfhttp://vetepensandolo.files.wordpress.com/2008/01/scrumandxpfromthetrenchesonline07-31.pdfhttp://es.youtube.com/watch?v=IyNPeTn8fpohttp://www.navegapolis.net/content/view/466/91/http://eskasiunblog.blogspot.com/search/label/SCRUMhttp://se-radio.net/podcast/2007-06/episode-60-roman-pichler-scrumhttp://www.navegapolis.net/content/view/268/60/http://www.implementingscrum.com/es/http://www.implementingscrum.com/es/http://vetepensandolo.files.wordpress.com/2008/01/scrumandxpfromthetrenchesonline07-31.pdfhttp://vetepensandolo.files.wordpress.com/2008/01/scrumandxpfromthetrenchesonline07-31.pdfhttp://es.youtube.com/watch?v=IyNPeTn8fpohttp://es.creativecommons.org/http://www.navegapolis.net/files/presentaciones/scrum_general_10.pdf


21/65

ndice de contenido

4 - Scrum: control y visibilidad ....................................................................................................... ........3

4.1 - Grfico Burndown: definicin y creacin ..................................................................................3

4.2 - El tabln Scrum ........................................................................................................ ......... ........5

2

4 Scrum: control y visibilidad


22/65

4 Scrum: control y visibilidad

4.1 Grfico Burndown: definicin y creacin

El grfico Burdown es una de las herramientas visuales ms potentes con las que cuenta

el mtodo Scrum. Con l podremos ver rpidamente si se estn cumpliendo los plazos del

sprint o si por el contrario nos estamos retrasando.

Es muy fcil de construir y de mantener. Para empezar a hacer un grfico Burndown solo

tenemos que saber el nmero de das del sprint y el nmero de horas que suman todas las

tareas que entran en el sprint. Colocamos en la vertical las horas y en la horizontal los

das.

Ahora unimos los extremos, es decir desde el valor ms alto de las horas implicadas en el

sprint hasta el ltimo da del sprint. Nos resultar algo parecido a esto:

En la figura superior vemos la lnea antes mencionada, esa lnea es en realidad la

pendiente de Scrum. Qu es la pendiente? Sencillamente el nmero de horas mnimas

de trabajo que debemos de quemar al da (de ah lo de Burndown) para terminar el sprint

en el tiempo proyectado. Se calcula dividiendo el nmero de horas entre el nmero de

das. En este caso: 800/18 = 44'44 horas/da entre todo el equipo.

3


23/65

A partir de ah lo que debemos de hacer es actualizar ese grfico todos los das, bien al

terminar la jornada, o bien al da siguiente, antes del Scrum diario. Para actualizarlo cada

miembro del equipo nos debe de informar (al ScrumMaster) cuanto tiempo de tareas ha

realizado, ese nmero de horas las restaremos del trabajo pendiente y situaremos el punto

que corresponda en la interseccin de las horas restantes con el da del sprint.

El trabajo restante el primer da ser igual al trabajo total del sprint (no se ha realizado

nada), pero los das sucesivos tendremos que tomar como referencia el trabajo restante del

da anterior para hacer la operacin antes descrita.

As, en la parte inferior del grfico de la pgina anterior vemos dos situacin claras:

En rojo: el grfico que resulta de ir uniendo los puntos est por encima de la recta

estimada. Eso implica que vamos retrasados (nos ha llevado ms tiempo realizar las

tareas de lo que habamos previsto, esto hay que tenerlo en cuenta par al prxima

planificacin de sprint para que no vuelva a ocurrir; nos podemos equivocar pero las

equivocaciones deben de servir para mejorar) y habr que tomar medidas. Recuerda

que slo el equipo puede tocar la pila de sprint y puede quitar tareas si ve que no es

posible realizarlas en el sprint, quizs por una estimacin previa incorrecta; aunque

esto se debe de evitar en la medida de lo posible, ya que tambin demos de recordar

que el equipo es responsable de su trabajo y de entregar todas las tareas definidas

para el sprint a tiempo.

En verde: el grfico resultante de la unin de puntos se encuentra por debajo de la

lnea prevista. El sprint va por buen camino e incluso hemos ido ms rpido de lo que

habamos previsto. Podramos hacer incluso alguna tarea extra. Os imaginacin que

impresin se llevara el dueo del producto cuando entreguemos ms de lo esperado?

Con el tiempo aprenderemos a estimar mejor el tiempo que nos lleva realizar cada una de

las tareas y es deseable y lgico que tendamos a seguir la lnea recta que nos habamos

propuesto al principio, aunque lo bueno de Scrum es que si surgen inconvenientes o

imprevisto tendremos la capacidad de reaccin suficiente.

Un de los aspectos important

simos del gr

fico Burndown es que se centra en el trabajoque restante, siempre miramos hacia adelante.

4


24/65

Nos podemos ayudar de una hoja de clculo para llevar la gestin de Scrum en nuestro

proyecto. Si es asnos resultar ms fcil llevar la cuenta de las horas previstas y las horas

reales. Esto es, cuando comenzamos el sprint estimamos cuantas horas tardaremos en

realizar una tarea y realizamos nuestros clculos de cuantas tareas haremos durante el

sprint en base a esa estimacin. Sin embargo muchas veces, y sobre todo al principio

nuestras estimaciones no sern todo lo acertadas que debieran; para ello habilitamos la

posibilidad de registrar al lado del tiempo estimado el tiempo real, de modo que nos sirva

de ayuda y aprendizaje para futuros sprints y mejorar nuestras estimaciones.

4.2 El tabln Scrum

El tabln Scrum es la herramienta de la que dispone el equipo para gestionar las tareas,

comprobar el estado del proyecto, tener un histrico de lo que ha ido pasando y aportar

sencillez a todo este necesario proceso.

Todo lo descrito anteriormente se realiza y cabe en una cartulina grande que se cuelgue en

la pared o en un tablero.

Como lo hacemos? Como todo en Scrum es sencillo, que no fcil (hay que usarlo todos

los das y actualizarlo constantemente).

Usaremos una cartulina o papel de tamao aproximado 1m x 0'5m en forma apaisada. En

conveniente pegarlo en la pared o ponerlo en un tablero ya que tendremos que trabajar con

l.

Con un rotulador tenemos que hacer lo siguiente:

Separar el tercio derecho del tablero con una lnea vertical, esa zona es la reservada al

grfico Burndown, a las tareas imprevistas y a las tareas de reserva.

5


25/65

Los otros dos tercios del tablero los dividiremos en tres franjas verticales iguales usando

dos rectas verticales. Esta ser la zona de gestin de tareas, en la cual utilizaremos los

post-its que ya comenzamos a ver en el tema anterior.

En la parte superior del tablero podemos dibujar un lnea recta de modo que se nos forme

una zona de ttulos. Ah podremos poner Pendientes, En Curso y Finalizadas,

refirindonos al estado de las tareas que se realizarn en el sprint.

Ahora debes de colocar los post-its con las tareas de las que hemos hablado en el tema

anterior en la columna de pendientes. Recuerda que si una tarea dura ms de 2 das debes

de subdividirla en tareas ms pequeas (como los post-its amarillos que se ven en el

dibujo, que realmente son subtareas de los blancos).

Los post-its los debes de colocar por orden de importancia decreciente, los ms

importantes arriba, y ser estricto a la hora de seguir el orden, NO SE DEBE realizarlos de

manera desordenada.

Cuando empieces a hacer una tarea debes de mover el post-it correspondiente a la

columna En Curso y cuando se haya completado totalmente la tarea moverla a la columna

de Finalizada; y comenzar con la siguiente. Recuerda comprobar los tiempos estimados y

escribir los reales para que te sirvan de referencia en el futuro.

Un ejemplo tpico de algo que no deberamos de hacer es el siguiente:

6

Scrum&XP from the trenches


26/65

Se ve claramente que el equipo no ha seguido el orden de prioridad establecido por ellos

mismos. Eso lleva a la desorganizacin y a ser menos productivos.

Hablbamos antes que en el tercio derecho del panel se reserva al grfico BurnDown as

como a las tareas imprevistas y a las tareas de reserva.

Las tareas imprevistas son aquellas que por desconocimiento, error de previsin o

interferencias exteriores es necesario realizarlas y que no estaban previstas. Se realizarn

y se pondrn en una zona identificada como tareas imprevistas. Si las tareas imprevistas

supusieran demasiadas horas como para reconsiderar todo el sprint () se debe convocar al

equipo y slo el equipo tiene la potestad para terminar el sprint y configurar uno nuevo.

Este es un ejemplo tpico en el que las tareas imprevistas impiden la marcha del sprint.

7


27/65

Las tareas de reserva son aquellas que se escogen y que deben de ser realizadas en caso

de que el equipo termine precipitadamente las tareas del sprint. Esto es tpico cuando la

duracin real de las tareas es menor que la estimada. El sprint NUNCA termina antes de

tiempo, se siguen realizando ms tareas hasta que se cumple la fecha de final de sprint. Lo

mismo sucede al contrario, si vamos retrasados en la realizacin de las tareas nunca

modificaremos la fecha de fin de sprint, tendremos que montar un producto

potencialmente comercializable con lo que tengamos en ese momento.

8


28/65

En este ejemplo vemos un tablero de scrum sencillo para realizar tareas personales y

acadmicas. Existen dos grficos y dos zonas pues se trata de dos proyectos distintos.

9


29/65

REFERENCIAS

Plantilla de hoja de cculo para Scrum


10
http://es.wikipedia.org/wiki/Desarrollo_?gil_de_softwarehttp://es.creativecommons.org/http://es.wikipedia.org/wiki/Desarrollo_?gil_de_software


30/65

ndice de contenido

5 - Scrum: Metodologas giles ........................................................................................................ .......35.1 - El manifiesto gil ...................................................................................................................... .3

5.2 - Principios: producto, cliente y equipo. ......................................................................... ......... ....3

5.2.1 - Cliente ................................................................................................................ ........ .......35.2.2 - Producto .................................................................................................................. ......... .35.2.3 - Equipo ................................................................................................................ ........ .......3

5.3 - Un ejemplo de empresa gil. ......................................................................................................4

5.4 - Productos giles. ................................................................................................................... .....4

5.5 - Contrato tradicional vs. contrato gil. ........................................................................................5

5.6 - Complejidad ............................................................................................................................ ...6

5.7 - Otros aspectos de Scrum ............................................................................................................6

5.7.1 - Scrum y el valor ......................................................................................................... .......65.7.2 - Scrum y el retorno de inversin ............................................................................... ........ .7

2

5 Scrum: Metodologas giles


31/65

5 Scrum: Metodologas giles

5.1 El manifiesto gil

En el ao 2001 un grupo de crticos con los metodologas clsicas de gestin de

proyectos se reunieron y sentaron las bases de las metodologas giles, lo que se conoce

como manifiesto gil, que podemos resumir como:

Darms importancia a la interaccin entre personas frente a procesos y

herramientas.

Darms importancia a productos que funcionan frente a documentacin

extensiva.

Incentivar la colaboracin con el cliente frente a la negociacin del contrato

Responder al cambio frente a seguir el plan.

5.2 Principios: producto, cliente y equipo.

5.2.1 Cliente

Nuestra mayor prioridad es satisfacer al cliente a travs de la entrega

temprana y continua de productos con valor.

Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Esto es una

ventaja competitiva de los procesos giles.

Los responsables de negocio y los trabajadores deben trabajar juntos

diariamente a lo largo del proyecto.

5.2.2 Producto

El producto que funciona es la principal medida del

progreso.

Entregamos productos frecuentemente.

La simplicidad es esencial

Los procesos giles promueven el desarrollo sostenible

La atencin continua a la excelencia tcnica y los buenos

diseos mejoran la agilidad

5.2.3 Equipo

Construimos proyectos con profesionales motivados.

Conversacin cara a cara.

3


32/65

Las mejores propuestas, requisitos y diseos surgen de equipos que se auto-

organizan.

A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo.

5.3 Un ejemplo de empresa gil.

Un ejemplo que se suele emplear mucho para dar a entender que es una empresa gil es

Toyota

El Toyota Prius fue desarrollado siguiendo los principios giles.

15 meses en lugar de los tpicos 4 aos

Concepto de coche totalmente nuevo, que no encajaba en ninguna lnea de

produccin y que integraba nuevas tecnologas.

Se utiliz un modelo de fases solapadas en las que simultneamente se trabaj

en diseo, investigacin, ingeniera, produccin ...

Uchiyamada pidi a su equipo que cuestionase cada norma del desarrollo de

coches.

5.4 Productos giles.

4


33/65

iPod es un producto tpicamente gil:

6 versiones en 6 aos

Cada versin aade valor a la anterior.

Los productos giles tienen tiempos giles: google, youtube, flickr, skype ... empresasque se crean, crecen y triunfan a nivel global en perodos de 2 a 5 aos.

Estamos viviendo tiempos exponenciales ... tiempos giles.

5.5 Contrato tradicional vs. contrato gil.

Contrato tradicional:

Precio nico, compromiso de tiempo de entrega.

Se realiza un estudio: doblamos coste y tiempo.

Presentamos oferta igualmente: cuando nos lo adjudiquen negociaremos.

Cliente no tiene autoridad para aprobar ampliaciones de presupuesto o

plazo.

Cliente aade decenas de cambios no especificados.

Trabajamos noches y fines de semana sin cobrar para, finalmente, no

cumplir las expectativas.

Contrato gil

Contratamos proveedores para uno o dos sprints: bajo coste y bajo

riesgo. Entregas parciales e iterativas de productos potencialmente

usables/comercializables.

Tiempo fijado y precio fijado

El cliente puede aadir todos los cambios que quiera. Se priorizan unas

caractersticas frente a otras. Se entregarn cuantas ms caractersticas

mejor, priorizando las que ms valor aporten al cliente.

Evaluamos las entregas. Los que no sirven son despedidos y buscamos

otros. Los que funcionan son seleccionados para contratos ms largos y

con mayor transcendencia.

Continuamos evaluando cada sprint (30 das).

5


34/65

5.6 Complejidad

5.7 Otros aspectos de Scrum

5.7.1 Scrum y el valor

6


35/65

5.7.2 Scrum y el retorno de inversin

7


36/65

ndice de contenido

6 - Scrum: Retrospectivas ................................................................................................................... .....3

6.1 - Qu son y para qu sirven? .......................................................................................................3

6.2 - La gente importa .................................................................................................................... ....4

2

6 Scrum: Retrospectivas


37/65

6 Scrum: Retrospectivas

6.1 Quson y para qusirven?

Al final del sprint es necesario, antes de comenzar el siguiente, hacer una revisin de las

cosas que hemos hecho bien y de las que hemos hecho mal. A eso se le llama reuni n de

retrospectiva.

Las retrospectivas son necesarias por que el aprendizaje se produce cuando las

expectativas no se cumplen, y al principio de usar Scrum es bastante frecuente. Gracias a

la retrospectiva conoceremos los errores y los problemas.

Se podrn responder preguntar como:

Qu ha ido bien? Por qu?

Qu ha ido mal? Por qu?

Al igual que todo en Scrum es necesario priorizar en la retrospectiva prestando atencin

principal y en primer lugar a las cosas ms prioritarias, tanto buenas como malas.

Todo el conocimiento y experiencia que extraigamos de la retrospectivas debe de ser

almacenado, para obtener guas de mejores prcticas, lecciones aprendidas, pila de

impedimentos encontrados, ascomo patrones de resolucin de problemas.

No debemos de prescindir de este paso de Scrum, no debemos de ser como el leador ...

3


38/65

Con este ejemplo se pretende escenificar que aunque nos parezca que las retrospectivas no

aportan nada a nuestro proyecto, ya que no es un momento en el que estemos realizando

trabajo prctico del que se obtengan resultados inmediatos, es necesario que el equipo se

conozca mejor, identificando sus fortalezas y debilidades. El leador necesita cortar

madera pero para eso es necesario que se encargue de su herramienta para obtener

mejores resultados.

Como hacemos una retrospectiva?

Es una reunin que debe durar entre 1 y 2 horas

Foco principal: localizar reas de mejora para el equipo

Debemos de incluir los nuevos objetivos que vayan saliendo en pilas.

Nos debe de servir para comparar con otros sprints.

Es recomendable hacerlo en una ubicacin distinta a la del trabajo, para

abstraernos de la sensacin de productividad y relajacin. No pretendemos echar

las culpas a nadie, si no intentar mejorar entre todos.

Lo ms importante de todo es asegurarse de que se realizan.

6.2 La gente importa

Como hemos dicho desde el comienzo, en las metodologas giles la gente es importante.

Con esto queremos decir que un equipo motivado y feliz ser ms productivo para la

empresa, al mismo tiempo que ms enriquecedor individualmente.

Es por eso que podemos usar la retrospectiva para conocer el nivel de satisfaccin de los

miembros del equipo. Es necesario hablar de esto en la reunin y buscar posibles

soluciones y aplicarlas de la forma ms divertida y fructfera que se nos ocurra.

Un artefacto que puede ayudar en este campo es el sismgrafo emocional. El sismgrafo

emocional es un calendario en el que cada miembro del equipo anota su estado, se puede

incluir un comentario muy breve que indica la naturaleza del estado negativo en caso de

que sea necesario.

4


39/65

Si an as no le ves la utilidad a esta reunin quizs te convenza la metfora del iceberg,

en el que se ve que los accidentes son una pequea parte de las cosas que pueden afectar

negativamente en el proyecto y pueden verse fcilmente, los problemas son ms difciles

de ver pero son ms numerosos y pueden aflorar en cualquier momento (es mejor estar

preparado), pero los errores estn por todos lados, son incontables y muy complicados de

vaticinar.

5


40/65

REFERENCIAS

Post sobre retrospectiva:

geeks.ms

Otro ms:

softqanetwork.com

6
http://www.google.com/url?sa=t&ct=res&cd=1&url=http://geeks.ms/blogs/rcorral/archive/2006/11/24/las-reglas-de-scrum-y-iv-el-sprint-review-meeting.aspx&ei=dM6xR8miC4Wm0wTk0YHVCw&usg=AFQjCNEbBhLsL3q0_FpVHD9AQA40EKHIKw&sig2=PGIqG5knVW7YDcOdPCL6Oghttp://www.google.com/url?sa=t&ct=res&cd=10&url=http://softqanetwork.com/blog/?p=124&ei=dM6xR8miC4Wm0wTk0YHVCw&usg=AFQjCNGCoHVcgg4WZB3QYlN7F2yQJ09BdA&sig2=S3PKaW3iTFuwWH-huS6-CAhttp://es.creativecommons.org/http://www.google.com/url?sa=t&ct=res&cd=1&url=http://geeks.ms/blogs/rcorral/archive/2006/11/24/las-reglas-de-scrum-y-iv-el-sprint-review-meeting.aspx&ei=dM6xR8miC4Wm0wTk0YHVCw&usg=AFQjCNEbBhLsL3q0_FpVHD9AQA40EKHIKw&sig2=PGIqG5knVW7YDcOdPCL6Oghttp://www.google.com/url?sa=t&ct=res&cd=10&url=http://softqanetwork.com/blog/?p=124&ei=dM6xR8miC4Wm0wTk0YHVCw&usg=AFQjCNGCoHVcgg4WZB3QYlN7F2yQJ09BdA&sig2=S3PKaW3iTFuwWH-huS6-CA


41/65

ndice de contenido

7 - Scrum: Planificacin, pila del producto y estimacin. .......................................................................3

7.1 - Citas ........................................................................................................................................... .3

7.2 - Objetivos de la planificacin. .....................................................................................................3

7.3 - Planificacin en Scrum ..................................................................................................... ........ .3

7.4 - Historias de usuario ................................................................................................................... .4

7.5 - Priorizacin ................................................................................................................................6

7.6 - Estimacin ..................................................................................................................................6

7.7 - Velocidad ....................................................................................................................................7

7.8 - Planificacin del producto. .........................................................................................................8

7.9 - Planificacin de Sprint. ..............................................................................................................8

7.10 - Reuniones de estimacin. .........................................................................................................8

2

7 Scrum: Planificacin, pila del producto y estimacin.


42/65

7 Scrum: Planificacin, pila del producto y estimacin.

7.1 Citas Un buen plan ejecutado contundentemente hoy, es mejor que un plan perfecto

ejecutado dentro de un mes (o lo ptimo es enemigo de lo mejor) George

Patton.

Cuando preparo una batalla, encuentro que los planes son intiles, pero la

planificacin es indispensable (o plan your work, and work your plan) Dwight

Eisenhower

7.2 Objetivos de la planificacin.

La planificacin nos permite definir las actividades que es necesario acometer.

Incluye procesos, enfoques, herramientas y mtodos.

Los recursos influyen en la planificacin

Hay que tener en cuenta las dependencias.

Durante la planificacin se realiza la asignacin de responsabilidades.

7.3 Planificacin en Scrum

Las herramientas que se utilizan en Scrum para planificar ya las conocen, se trata de la

Pila de Producto y de Sprint:

Tareas priorizadas

Tareas especficas

Tareas cuantificables

Tareas alcanzables

Tareas razonables

Tareas con tiempo definido

Tareas independientes

Tareas negociables

3


43/65

Tareas que aportan valor

Tareas estimables

Tareas pequeas

Tareas comprobables

Se detallan y definen exhaustivamente las tareas prioritarias (primeras en

realizarse)

Debemos de diferenciar correctamente entre las caractersticas del producto entre:

obligatorias, recomendables, posibles y deseables.

Hay que tener en cuenta la historia de usuario (que quiere el cliente y porqu).

Granularidad elevada (descomposicin en tareas pequeas).

Adems de las planificaciones de Pila de Producto (la ms general) y Pila de Sprint (la

ms especfica) podemos definir la Pila de Venta (Pila de Comercializacin o Release)

que es en la que definimos las caractersticas o tareas que deben de completarse para sacar

una versin o modelo del producto a la venta. Este caso es como el del caso iPod:

debemos de aadir las siguientes mejora para la siguiente versin que se vender del

producto.

7.4 Historias de usuario

Una historia de usuario es un pequeo texto en el que describimos algo que hara

un usuario con nuestro producto.

Se trata de una buena forma de enumerar las caractersticas a alcanzar.

Una historia debera de contener un mtodo de prueba y un objetivo de la

caracterstica. (Ej: El comprador del libro podr borrar anotaciones hechas a lpiz

sin que quede marca ya que deseamos que el libro tenga una vida til muy larga,

se probar con varios tipos de lpices, incluidos de colores y con varios tipos de

gomas de borrar, comprobando que no quedan marcas)

4


44/65

Se enuncian de la forma: como (rol), me gustara (funcionalidad) para (valor).

Las historias deben de caber en una ficha o post-it

Ejemplo:

Catlogo de requisitos clsico:

El producto debe tener motor de gasolina

El producto debe de tener 4 ruedas

El producto debe constar de asiento para el conductor

El producto debe de contar con una carrocera metlica

El producto debe de tener volante

El producto debe circular por terreno campestre

Historias de usuario:

Como responsable de jardinera, quiero poder cortar el csped de forma rpida y

fcil

Como responsable de jardinera, quisiera que esta tarea fuera lo ms cmoda

posible

Como veis las formas anteriores son modelos de especificar el producto que se quiere

conseguir, sin embargo parece que la segunda, al informar de quin nos hace la peticin y

porqu nos la hace, ofrece informacin adicional. Con l catlogo podramos realizar un

producto que dista de lo que el cliente quiere:

5


45/65

7.5 Priorizacin

Sucede que partiendo de las historias de usuario rellenamos post-its que definirn las

tareas que ms tarde conformarn la Pila de Sprint. Pero una vez terminado lo nico que

tendremos es un montn de trabajo por realizar sin orden alguno, nos toca ahora decir que

haremos primero, por ser ms importante y prioritario.

Esta tarea es sencilla para una persona sola, pero cuando se trata de un equipo que se tiene

que poner de acuerdo puede resultar complejo. Existen formas de priorizar las tareas entre

todos, las fundamentales :

Consenso: se trata de ir enunciando las tareas e irlas jerarquizando entre todos. Votacin: Cada uno vota por un nmero reducido de tareas que considera ms

importantes. Ganarn las tareas que ms votos reciban, Iremos repitiendo el

proceso hasta haber ordenado todas las tareas.

1000 a repartir: o cualquier otra cantidad o moneda. Se trata de una especie de

puja, en la que cada todos los miembros del equipo disponen de la misma cantidad

y pueden ir dando dinero como consideren a las tareas que ms importante le

parezca a cada una, las que ms dinero hayan recaudado sern la s ms

importantes; al igual que en caso anterior se repite hasta que todas estn

priorizadas.

7.6 Estimacin

Desde le comienzo de este curso hemos venido diciendo que en Scrum toda tarea debe de

estar estimada en tiempo. Pero que es eso de la estimacin realmente?

Una estimacin es un clculo que hacemos a priori de cuanto vamos a tardar en hacer una

tarea. Pero cmo se hace eso? Pues bien, antes de responder a esta pregunta quizs nos

debiramos de plantear otra QU ES EL TIEMPO? No se trata de una pregunta

metafsica ni cientfica, tratamos de decir que es el tiempo para Scrum. Si decimos que

tardaremos en hacer una tarea 6 horas, por un lado querr decir que si empezamos a las 8

de la maana la habremos terminado a las 2 del medioda, pero por otro lado quiere decir

6


46/65

que terminar a las 14.00 si me dedico exclusivamente a ello, no se me interrumpe con

otras solicitudes, no tengo que ir a reuniones, no se cambian los requisitos en ese tiempo

... (por eso decamos que hace falta respaldo de la gerencia de la empresa).

Adems debemos de tener en cuenta que nadie es 100% de potencia el 100% del tiempo,

para Scrum se suele aceptar que el rendimiento medio ronda entre el 60% y el 80% del

tiempo Por qu? Por que necesitamos ir al servicio, llamar a un familiar, beber cuando

tenemos sed ... somos humanos. Con lo cual es probable que esa tarea que yo pensaba que

iba a hacer en 6 horas quizs me lleve 7.

Pero de dnde sacamos esto? hay alguna gua o tabla de conversiones? La verdad es que

no, cada uno se debe de conocer a s mismo y el equipo debe de trabajar unido para

conocerse mejor paulatinamente.

Lo que si que es fundamental en la estimacin, y que ya vimos anteriormente es

DESCOMPONER LAS TAREAS GRANDES, de modo que no haya tareas que duren

ms de 2 jornadas. Eso nos permite tener la sensacin de premura y no ir relegando la

tarea para una realizacin posterior.

7.7 Velocidad

La velocidad es la cantidad de trabajo que el equipo es capaz de completar en un sprint.

Es un punto clave para completar la planificacin.

Es necesaria una retrospectiva para evaluar la velocidad del equipo.

Debemos de contemplar en la velocidad aspectos como vacaciones, dedicacin ...

Paulatinamente, la estimacin y la realidad convergen.

Si la duracin del sprint es variable es ms complicado estimar la velocidad.

Al final se puede interpretar como una cifra que mide el rendimiento de un equipo.

7


47/65

7.8 Planificacin del producto.

Debe durar alrededor de unas 4 horas.

Nos dotar de visin a largo plazo Roadmap

Es una planificacin estratgica: total de sprints

A mayor cercana mayor detalle

Antes tareas que se realizarn en sprints lejanos solo trataremos los conceptos, no

los detalles (ya llegaremos ahy ya habr tiempo de profundizar, centrmonos en

lo que vamos a hacer en 10 das, no en 10 meses)

Se utilizan mtodos de recopilacin: entrevistas, Brainstormings.

La forma de medir es por funcionalidad terminada.

No hace falta que esta planificacin est al 100% completa para comenzar el

proyecto.

7.9 Planificacin de Sprint.

Su duracin debe ser entorno a 4 horas.

El equipo selecciona cuanta tarta puede comer (que cantidad de trabajo pueden

realizar) en un Sprint.

Descomponer cada historia en tareas (1 16 horas idealmente)

Preparar el tabln Scrum para ese Sprint

Definir que significa terminado para cada una de las tareas (incluir pruebas,

documentacin, archivo de facturas ...)

Es el momento de resolver las dudas con el due

o del producto.

7.10 Reuniones de estimacin.

Durarn idealmente entre 1 y 2 horas

Se realizar en la planificacin del sprint y adicionalmente tantas como sea

necesario / deseable / posible para estimar cada una de las tareas rigurosamente.

Se revisarn las tareas realizadas, pendientes, recursos ...

8


48/65

ndice de contenido

8 - Scrum: Equipos y reuniones. ..............................................................................................................3

8.1 - Citas ............................................................................................................................................3

8.2 - Directrices .............................................................................................................................. ....3

8.3 - Independencia y confianza .........................................................................................................3

8.4 - Reuniones efectivas ....................................................................................................................4

8.5 - Scrum diario ...............................................................................................................................4

8.6 - Reglas del Scrum diario .............................................................................................................5

8.7 - Problemas y soluciones ..............................................................................................................5

8.8 - Fracasos ......................................................................................................................................5

2

8 Scrum: Equipos y reuniones.


49/65

8 Scrum: Equipos y reuniones.

8.1 Citas Dee Hock Fundador y CEO emrito de VISA

Los principios y propsitos simples y claros conducen a un comportamiento

complejo e inteligente

Las reglas y procedimientos complejos conducen al comportamiento simple

estpido

Ricardo Semler

Trata a los trabajadores como a nios y se comportarn como tales. Dales

responsabilidad y se comportarn como adultos responsables

8.2 Directrices

Regla gil fundamental: UNE AL EQUIPO!

Debemos de proporcionarles un espacio propio

Esto a veces es un problema en algunas organizaciones

Mustrales lo que puede hacer Scrum

Comienza poco a poco

Crea equipos multi-funcionales (nada de ttulos ni rangos)

Mantn al dueo del producto cerca del Scrum Master y lejos del equipo

8.3 Independencia y confianza

El equipo se debe de auto-organizar

El equipo escoge el trabajo que realizar

Cada miembro determina en qu debe trabajar

Durante el Sprint, mantener a la gestin fuera del camino del equipo

Si no se confa en el equipo que esperamos que ocurra?

Se debe de permitir el fallo, como nica forma de aprender y mejorar, puede que

no se cumplan las expectativas

La productividad NO ES FUNCIN DEL TIEMPO

3


50/65

8.4 Reuniones efectivas

Reuniones Scrum: salvo el Scrum diario son reuniones muy largas (pero una vez

al mes)

Determina la meta de la reunin.

Identifica claramente a los implicados.

Enva siempre una orden del da.

Establece una duracin objetivo de la reunin y s implacable.

Dirige las reuniones: establece reglas, revisa el contexto, acta como

moderador. Como moderador, s imparcial. No juzgues, adopta el punto de

vista de tu interlocutor.

Mantn la reunin centrada en el objetivo.

Toma notas. Obtn compromisos concretos de tus interlocutores.

Llegado el deadline, cierra la reunin con un resumen de todos los puntos

de accin que se han determinado.

Enva un acta de la reunin

8.5 Scrum diario Sobre el Scrum diario:

En el mismo sitio, a la misma hora

Puede asistir quin quiera, pero solo participa el equipo

Se debe hacer de pie (para evitar que se alargue)

Se deben de resolver 3 preguntas:

Que he hecho desde ayer?

Que voy a hacer hoy? Que impedimentos han surgido?

No se contesta / no se discute / no se interrumpe

Slo habla una persona cada vez

Debe durar entre 5 y 15 minutos

Se debe de hacer TODOS LOS DAS

Se pueden usar rituales como que el que llega tarde empieza o paga prenda, o

que se marca el fin de la reunin con alguna frase o gesto (si te diviertes sers

ms productivo)

4


51/65

Debe de haber sincronizacin. Actualizamos los tablones

El Scrum diario aporta una visibilidad total del proyecto.

8.6 Reglas del Scrum diario

Slo habla uno, se cede la palabra por turnos

Se habla al equipo

No se acusa ni se echan culpas

No nos dirigimos unos a otros como Tu o Yo

Nada de insultos ni discusiones

Slo pregunta el Scrum Master

8.7 Problemas y soluciones

Algunos problemas

Se interrumpe al que habla

Se crean dobles conversaciones

Divagacin

Interrupciones de la reunin

... y algunas soluciones

Ser severamente estricto

Atenerse a las tres preguntas

Slo habla el que tenga determinado objeto en las manos: martillo, lpiz,

peluche ...

El que llega tarde paga una multa / hace el payaso / paga el caf ...

8.8 Fracasos

Aunque Scrum es una metodologa ampliamente extendida y aceptada pueden darse

situaciones en las que no se muestren sus ventajas

5


52/65

Cuales suelen ser las causas ms comunes?

Falta de competencia

Podemos formar a la persona en conflicto

Podemos reasignar competencias para que se puedan alcanzar

Falta de confianza

Ayuda de coaching

Falta de compromiso

TeamBuilding

Dejar que intervenga el equipo

6


53/65

ndice de contenido

9 - Scrum: Sprints y desarrollo de proyectos ....................................................................................... ....3

9.1 - El compromiso del equipo ..........................................................................................................3

9.2 - Durante el sprint .........................................................................................................................3

9.3 - Demo o presentacin ..................................................................................................................4

9.4 - Tipos de Sprint ...........................................................................................................................4

2

9 Scrum: Sprints y desarrollo de proyectos


54/65

9 Scrum: Sprints y desarrollo de proyectos

9.1 El compromiso del equipo

El equipo debe estar seriamente comprometido y motivado. Como se ha visto hasta el

momento le hemos dado al equipo libertad, y por tanto tienen una responsabilidad para

autogestionarse y cumplir sus plazos. La directiva debe de estar implicada y respetar la

libertad del equipo en todos los aspectos que se han visto.

Nuestro compromiso como equipo implica:

Pensamos que podemos lograr el objetivo.

Haremos lo posible por lograrlo, y comunicaremos cuanto antes si pensamos que

no vamos a conseguirlo.

Podemos completar la mayora de las historias seleccionadas.

Entregaremos al final del Sprint

Si no llegamos, eliminaremos primero las tareas de menos prioridad.

Si vamos rpidos, aadiremos las siguientes tareas de ms prioridad.

Mostraremos nuestro progreso a diario (tabln y scrum diario)

Cada historia que entreguemos estarcompleta

Todo lo anteriormente dicho no quiere decir que prometamos cumplir el objetivo ni que

prometamos entregar todas las funcionalidades del sprint.

9.2 Durante el sprint

El dueo del producto y Scrum Master trabajan en la pila de producto, intentarn

definir prximas historias.

El sprint debe de terminar con una demostracin o presentacin.

El equipo debe de hacer la demo, es su compromiso, no del Scrum Master.

Y si la demo no funciona? Hemos dicho que permitimos aprender de los

fallos, la prxima vez lo tendrn en cuenta.

3


55/65

Existe la posibilidad de terminar anormalmente el sprint, aunque siempre ser

preferible sustituir historias antes que realizar una cancelacin del sprint.

Durante el sprint el equipo est a tope, al 100%, concentrado al mximo,

agobiado por cumplir los tiempo. No se debe molestar al equipo durante un

sprint.

9.3 Demo o presentacin

Todo sprint debe de acabar con una demo o presentacin de los avances, e intentar que lo

que se entregue sea potencialmente comercializable.

En una demo:

El Equipo muestra lo que se ha avanzado al Dueo del producto. Esto vale para

conocer si lo que estamos haciendo es lo que quera el cliente.

Slo se muestran las historias completadas.

Un producto usable no es un documento o un esquema, es algo que se pueda

usar, aunque sea rudimentariamente.

Si el dueo del producto requiere modificaciones sern nuevos elementos de la

pila de producto, se har en prximos sprints, dependiendo de su importancia.

No se puede estar siempre en sprint, si no lo que hacemos es jogging.

Obligatoriamente se debe rebajar el ritmo entre sprints. Hay que tomarse

descansos.

9.4 Tipos de Sprint

4


56/65

ndice de contenido

10 - Scrum: Implementando y escalando Scrum ........................................................................... ......... .3

10.1 - Escalando Scrum ......................................................................................................................3

10.2 - Distribucin de carga vs. Portfolio ...........................................................................................3

10.3 - Equipos distribuidos .................................................................................................................4

10.4 - Scrum: si o no ............................................................................................................... ......... ..4

10.5 - Cambios ....................................................................................................................................5

10.6 - Nueva relacin de cliente ................................................................................................. ........5

10.7 - Contrato Scrum ................................................................................................................... .....5

10.8 - Nueva organizacin: Organizacin gil vs. Organizacin Tradicional ...................................6

10.9 - Reglas inquebrantables .............................................................................................................6

10.10 - Miedo escnico ......................................................................................................................7

10.11 - Epifanas giles ......................................................................................................................7

2

10 Scrum: Implementando y escalando Scrum


57/65

10 Scrum: Implementando y escalando Scrum

10.1 Escalando Scrum

La posibilidad de escalar es la opcin de que si aumenta la complejidad o envergadura del

proyecto podremos aumentar nuestros recursos, con el aumento de compenetracin que

ello conlleva para poder llevar a cabo el proyecto.

Scrum no escala haciendo equipos ms grandes, sino haciendo ms equipos.

La sincronizacin entre equipos se complica: Scrum de Scrums, tablones de

dependencias cruzadas.

Se puede invitar a miembros de otros equipos a las retrospectivas, que ayuda a la

transmisin del conocimiento a lo largo de la organizacin.

Debemos de hacer los Scrums diarios a horas no solapadas, de forma que el dueo

del producto y otros miembros puedan presenciar distintos scrums diarios para

conocer el estado de cada equipo.

10.2 Distribucin de carga vs. Portfolio

Cada equipo tiene un potencial de carga mensual

Conforme vamos asignando horas a proyectos, vamos restando capacidad al

equipo

Podemos y debemos saber que equipos estn saturados y cuales tienen capacidad

disponible.

Cada proyecto tendr

una serie de horas asignadas a distintos equipos

3


58/65

Podemos y debemos saber que proyectos tienen suficientes recursos y cuales

necesitan apoyo.

10.3 Equipos distribuidos

No debemos de crear equipos en funcin de las situaciones geogrficas de los

miembros. Con Scrum se puede trabajar a distancia.

Podemos usar Scrum de Scrums y designar un Scrum Master Jefe

Los scrum diarios pueden hacerse por videoconferencia, mensajera instantnea ...

La pila de producto, burndown, tabln de scrum y el resto de artefactos pueden ser

emulados a trav

s de herramientas on-line

10.4 Scrum: si o no

SI:

Por regla general siempre.

Es sencillo, pero muy duro. La recompensa merece la pena

Para implementar Scrum: comprender que hace que Scrum funcione y que lo hace

productivo. Esas reflexiones son muy positivas.

Cuando NO:

Cuando el entorno es poco flexible

En equipos muy grandes

Si no hay apoyo de la gerencia

Si no hay recursos para formacin o para la incorporacin de Scrum Masters

Cuando no existe posibilidad de implicacin del cliente

Cuando no hay transparencia o no existe seguridad

Si no existe una infraestructura para comunicarse y colaborar

Proyectos de manufactura o similares, o donde no haya complejidad.

Tal y como vimos al principio Scrum no es una varita mgica.

4


59/65

10.5 Cambios

El dueo del producto est acostumbrado a desvincularse del proyecto y exigir

responsabilidades al Jefe de Proyecto, con Scrum es ahora l el responsable de

gestionar la pila de producto.

Los jefes de proyecto no estn acostumbrados a no planificar todo su proyecto

desde el principio y al principio (las circunstancias son cambiantes, el plan del

comienzo puede que ya no valga. Hay que ir replanificando los planes)

Los trabajadores no estn acostumbrados a controlar a sus compaeros, reportar

diariamente el progreso y mostrar / negociar el producto con el dueo del

producto. A la gente no le gusta cambiar de sitio de trabajo.

10.6 Nueva relacin de cliente

Al usar Scrum las cosas cambian, y entre ellas la relacin con el cliente. Hay que

plantearse si el cliente est preparado para Scrum:

Las entregas son frecuentes, quizs demasiado para el cliente, existe un trabajo de

aprobacin, solicitud de cambios, asistencia a reuniones por parte del cliente que

es posible que no quiera / pueda asumir.

El cliente debe de estar ms involucrado, en responsabilidad y en frecuencia,

cuando se aplica Scrum.

Es una nueva relacin, puesto que supone un gran esfuerzo por parte del cliente y

de la organizacin, pero como ya se ha visto anteriormente, el resultado merece la

pena.

10.7 Contrato Scrum

Tambin es conocido como ScrumSourcing y los aspectos ms importantes son:

Tiempo prefijado y presupuesto prefijado. Fixed Time Fixed Money

El cliente puede cancelar el contrato en cualquier momento por un 20% del

importe pendiente.

5


60/65

El cliente puede prorrogar el contrato

El cliente puede cambiar cualquier caracterstica del producto por otra de tamao

o estimacin similar.

10.8 Nueva organizacin: Organizacingil vs. Organizacin Tradicional

TRADICIONAL GIL

Centralizada Distribuida

Perspectiva nica Perspectiva diversa

Anlisis previo a la accin Aprender haciendo

Racional Redundante

Basada en la certeza Basada en el cambio

Concepto de estrategia Accin local

Autoritaria Participativa

Jerrquica Plana

10.9 Reglas inquebrantables

Cuando se habla de Scrum no gusta decir que hay cosas que no se pueden hacer. Scrum es

libre y su aplicacin tambin, si te funciona alguna modificacin sala!

Pero hay algunos detalles que se deben evitar a toda costa, pues se ha comprobado que

son altamente perjudiciales para el rendimiento y funcionamiento de Scrum:

NADIE puede adjudicar nuevos trabajos al equipo durante el Sprint

Interfiere en la auto-organizacin

Afecta a la solucin final

TODO debe de realizarse en el tiempo determinado, NADA de un poco ms,

dentro de un rato, en el siguiente sprint ...

A veces estos aspectos conllevan un cambio de mentalidad y filosofa en el trabajo,

requiere tiempo y debemos de drselo.

6


61/65

10.10 Miedo escnico

Mucha gente se asusta cuando le hablan de la implantacin de Scrum, pero por qu?

pues sencillamente porque siempre hay resistencia ante los cambios y porque Scrum tiene

fama (y con razn) de ser duro. Es duro por que eres t el que te controlas y tienes que

rendir cuentas ante tus compaeros.

A veces los cambios pueden ser importantes:

Formar parte de un equipo conlleva ms responsabilidad

Comenzamos a trabajar sin un documento de especificaciones y restricciones.

Como parte del equipo debemos de estimar y organizar

Se necesita una infraestructura para Scrum: salas de reunin, comunicaciones ...

Debemos de realizar los Scrums diarios, eso es, todos los das.

Debemos de tener visibilidad amplia y clara de todo el proyecto

Debe de haber coordinacin entre Scrums si es necesario

Los sprints son de duracin fija y no se adaptan a nuestros antojos

No se puede interrumpir al equipo, ni siquiera los jefes.

El equipo debe de presentar una demo al cliente

Es obligatorio documentar lo que se hace y probarlo todo.

10.11 Epifanasgiles

El dueo del producto y el equipo se dan cuenta que pueden trabajar sin que todos

los requisitos estn claramente definidos. Para qu saber con claridad lo que

haremos dentro de 10 meses? Centrmonos en lo que vamos a hacer este mes.

El dueo de producto se da cuenta, a travs de las demos, de que el equipo

entregar algo usable ytil en fecha.

Los miembros del equipo se dan cuenta de que alguien les ayudar cuando haya

problemas (el Scrum Master)

El gerente siente el trabajo en equipo, la energa y enfoque que rebosa en una sala

de Scrum

7


62/65

El dueo del producto y el gerente se dan cuenta que no tienen que decirle al

equipo lo que debe hacer.

El equipo se da cuenta que nadie va a decirles lo que deben hacer. Deben decidir

ellos mismos lo que hacer y como hacerlo.

Los miembros del equipo dejan de trabajar como curritos y comienzan a pensar

como empleados altamente cualificados e independientes capaces de asumir

responsabilidades y proyectos => ms motivacin y ms valoracin por parte de

jefes y compaeros => FELICIDAD

Ese es el objetivo de Scrum, ser feliz, divertirse en el trabajo siendo

responsable, cumpliendo los objetivos y con libertad.

8


63/65

ndice de contenido

11 - Scrum: Herramientas y referencias ...................................................................................................3

11.1 - Recursos ....................................................................................................................................3

11.2 - Herramientas .................................................................................................................... ........3

2

11 Scrum: Herramientas y referencias


64/65

11 Scrum: Herramientas y referencias

11.1 Recursos

Agile Software Development with SCRUM, Ken Schwaber, Mike Beedle

Agile Project Management with SCRUM, Ken Schwaber

Scrum and XP from the trenches

Flexibilidad con Scrum, Juan Palacio.

http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf

User Stories Applied, Mike Cohn

The Zen of Scrum, Scrum Alliance.

http://www.scrumalliance.org/system/resource/file/75/csm_v5.pdf

Peopleware, Tom DeMarco & Timothy Lister

www.implementingscrum.com

agilemanifesto.org

ScrumAlliance.org

www.controlchaos.com

www.agileadvice.com

www.infoq.com

Blogs en castellano

www.navegapolis.net

geeks.ms/blogs/rcorral/default.aspx

www.presionblogosferica.com

11.2 Herramientas

De pago:

VersionOne

Scrum for TeamSystem

ScrumWorks

Trichord (Kanban)

3
http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdfhttp://www.scrumalliance.org/system/resource/file/75/csm_v5.pdfhttp://www.implementingscrum.com/http://www.controlchaos.com/http://www.agileadvice.com/http://www.infoq.com/http://www.navegapolis.net/http://www.presionblogosferica.com/http://www.scrumalliance.org/system/resource/file/75/csm_v5.pdfhttp://www.implementingscrum.com/http://www.controlchaos.com/http://www.agileadvice.com/http://www.infoq.com/http://www.navegapolis.net/http://www.presionblogosferica.com/http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf


65/65

ProjectCards

Jira

Abiertas / gratuitas

Xplanner

PPTS

Xpweb

Trac

Subversion

Gnats

_SCRUM-Resumen Libro (ESP)

Documents

Transcript of _SCRUM-Resumen Libro (ESP)