c reuniones

7/29/2019 c Reuniones

1/33

REUNIONES

(Ceremonias)


2/33


3/33

Low tech

High touch


4/33


5/33

Las reuniones durante el Sprint

El sprint es el latido del ciclo de Scrum.

La planificacin y la seguidilla de revisin y retrospectiva marcan respectivamente elcomienzo y fin del sprint.

La longitud del sprint se encuentra fija y jams se extiende.

La gran mayora de los equipos Scrum eligen una duracin de sprint de dos, tres o a

lo sumo cuatro semanas.

Durante el sprint el equipo lleva a cabo una reunin diaria.

Cada reunin en Scrum tiene una duracin mxima fijada a priori (conceptodenominado timeboxing en la jerga de Scrum). Para un sprint de cuatro semanas el

tiempo que suele dedicarse a la primer y segunda parte de la reunin planificacin,

as como tambin a la revisin y retrospectiva suele fijarse en cuatro horas cada una.


6/33

Definiendo la meta del Sprint

Lo importante es que est descrito en trminos de negocio. Eso significa en trminos en

los que la gente de fuera del equipo lo pueda entender. La meta de Sprint debera

responder a la pregunta fundamental Por qu hacemos este Sprint en vez de irnos

todos de vacaciones?. De hecho, una forma de obtener la meta del Dueo de Producto

es precisamente hacerle esa misma pregunta.

La meta del Sprint puede parece bastante tonta y artificial durante la planificacin de

Sprint, pero muchas veces resulta til a mediados de Sprint, cuando la gente comienza asentirse confusa acerca de lo que deberan estar haciendo. Si tienes bastante equipos

Scrum (como nosotros) trabajando en diferentes productos, es muy til poder listar todas

las metas de Sprint en una pgina Wiki (o donde sea) y colocarla en un sitio prominente

donde todo el mundo en la empresa (no solo la alta direccin) pueda saber qu est

haciendo la compaa - y por qu!


7/33

TIPS

Una longitud de 2 semanas para los sprints suele ser muy til para comenzar.

Luego de 3 sprints lo mejor es dejar que el equipo decida el ritmo con el que desea

trabajar. Los grupos necesitan 3 sprints para comenzar a entender los nuevos conceptos,

deshacerse de viejos hbitos y comenzar a moldearse como un verdadero equipo.

Nunca realice la planificacin de sprints los lunes a la maana. El equipo no est con

todas sus luces y suele ser el da en el que se producen la mayor cantidad de ausencias

por enfermedad.

Nunca realice revisiones o retrospectivas los viernes por la tarde. El equipo estcansado y pensando en el fin de semana. Por lo tanto es una buena idea considerar

comienzo y fin de los sprints entre martes y viernes.

Aquellos equipos que trabajan en sprints de dos semanas suelen pensar que es una

buena idea tener las reuniones de comienzo y fin de sprint en un slo da. En otras

palabras, comenzar el da con la revisin, luego la retrospectiva; este enfoque conlleva 2

problemas:

El equipo no considera que estas reuniones son parte del trabajoen los

hechos, son la parte que ms influye en el xito del resto del sprint!

Durante la ltima parte del da el equipo est mentalmente agotado


8/33

SPRINT PLANNING Cuando?

Quienes estn a cargo?

Que se hace?

Resultados esperados?


9/33

SPRINT PLANNING

2 partes

Estrategia: el que

Tctica: el como

El daily meeting es la replanificacin de la tctica

En Scrum tengo muchos puntos de control


10/33

Parte 1

La Parte 1 de la Planificacin del Sprint es en realidad un workshop de toma de

requerimientos detallado.

El Product Owner (PO) presenta la serie de funcionalidades que desea que sean

implementadas ;

y el equipo realiza las preguntas necesarias para comprender los requerimientos con

el detalle suficiente que le permita comprometerse a entregar dichas funcionalidades

al final del sprint.

El equipo decide por si mismo cunto puede entregar, considerando :

la duracin del sprint,

el tamao del equipo y las habilidades y disponibilidad de sus miembros,

la definicin de LISTO y

cualquier accin a tomar decidida durante la retrospectiva que precedi a esta

reunin.


11/33

Part One focuses on understanding what the Product Owner wants and why they are

needed. At the end of Part One the (always busy) Product Owner may leave although

they must be available (for example, by phone) during Part Two of the meeting.

In Part One, the Team and the Product Owner may also devise the Sprint Goal. This is a

summary statement of the Sprint objective, which ideally has a cohesive theme. TheSprint Goal also gives the Team scope-flexibility regarding what they may actually

deliver, because although they may have to remove some item (since the Sprint is

timeboxed), they should nevertheless commit to delivering something tangible and

done that is in the spirit of the Sprint Goal.

How big should the items be that are taken on in a Sprint? Each item should be split

small enough so that it is estimated to require considerably less than the whole Sprint.A common guideline is that an item is estimated small enough to complete within one

fourth or less of a Sprint by the whole Team.


12/33

Al finalizar esta primera parte, el equipo se compromete ante el Product Owner a

desarrollar aquello que consideran podr ser entregado testeado y funcionando al

finalizar el sprint.

El conjunto de los tems del backlog que han sido comprometidos se denominarproduct backlog seleccionado (o comprometido).


13/33

El Product Owner debe estar presente durante esta reunin para poder guiar al

equipo en la direccin correcta y responder preguntasque seguramente sern

muchas.

El ScrumMaster debe asegurarse que cualquier stakeholder cuya presencia sea

necesaria para que el equipo comprenda los requerimientos est en la reunin, al

menos telefnicamente.

Cualquier tem del backlog que se desea sea desarrollado durante el sprint que no

haya sido estimado con anterioridad ser estimado de manera inmediata durante la

reunin.

Al finalizar esta primera parte,el equipo se compromete ante el Product Owner a

desarrollar aquello que consideran podr ser entregado testeado y funcionando al

finalizar el sprint.

El conjunto de los tems del backlog que han sido comprometidos se denominar

product backlog seleccionado.


14/33

Parte 2

Durante esta sesin el equipo colabora de forma tal de crear un diseo a alto nivel de

los tems a los que se ha comprometido.

Un resultado de la reunin ser el backlog del sprint, o la lista de tareas que el equipo

debe ejecutar de manera colectiva para poder entregar en forma de funcionalidades

testeadas.

Esta serie de tareas se denomina backlog del sprint (sprint backlog) y suelerepresentarse en un tablero de tareas (taskboard) fsico.

Durante esta parte el equipo podra tener preguntas adicionales con respecto a los

requerimientos. El ScrumMaster debe asegurarse que el Product Owner y, si fuera

necesario, otros stakeholders se encuentren disponibles para poder responder estas

preguntas.


15/33

TIPS

El diseo, como todo lo dems en el desarrollo gil, es emergente.

La reunin est timeboxeada (ie. tiene un lmite pre-establecido de tiempo). Por

ende es normal que el equipo no arribe a un diseo completo durante esta sesin

y que descubra nuevas tareas durante el sprint. Esto no es un signo de alarma.

Simplemente tomarn un post-it, un marcador y crearn nuevas tareas cuando

sea necesario

La mejor seal de que esta parte est funcionando es cuando el equipo se

encuentre reunido alrededor de una pizarra discutiendo airadamente sobre la

mejor o incluso la manera correcta de implementar una funcionalidad.


16/33

Reunin diariaCuando?


Que se hace?



17/33

La reunin diaria (daily meeting) es uno de los tres puntos de inspeccin y

adaptacin en Scrum.

El equipo se rene para comunicar y sincronizar su trabajo. Dado que el equipotrabaja de manera colaborativa este momento es esencial para asegurar un

progreso continuo y evitar bloqueos.

Adems el equipo medir permanentemente su propio progreso en trminos del

objetivo del sprint (sprint goal).

La reunin diaria NO tiene como objetivo reportar progreso al ScrumMaster, Product

Owner o cualquier otro stakeholder.

El Product Owner podr participar de la misma siempre y cuando se mantenga en

posicin pasiva, hablando nicamente cuando se le realicen preguntas.


18/33

La daily meeting se hace frente al tablero

Es = resincronizarnosNO soluciona problemas, solo los detecta.Para solucionar los problemas el SM hace reuniones apartes

Quin hace las preguntas?

NADIE

El ScrumMaster NO hace las preguntas, el equipo habla solo.

Las personas deben auto-organizarse las tareas

Es lograr salir de lo que ME gusta

E ir a lo que ms le conviene al grupo

Las story NO tienen dueo

Porque eso llevara al multitaskingY no fomentara la colaboracin

Si hay alguna tarea que nadie latoma, el SM puede cambiarle el

color al post-it para llamar la

atencin de esa tarea


19/33

El ScrumMaster debe asegurarse, utilizando su habilidades como facilitador, quetodos los miembros del equipo se hayan comprometido a realizar cierto trabajo

en las prximas 24 horas y que este trabajo tenga como objetivo exclusivo ayudar

a que el equipo entregue el siguiente tem del backlog.

El ScrumMaster deber, a su vez, asegurarse que cualquier impedimento que

dificulte la tarea del equipo sea removido lo antes posible.

El ScrumMaster tiene tambin la responsabilidad de restringir la reunin a un

mximo de 15 minutos.

Qu hace el SM en la daily meeting?


20/33

think ofGIFTS:

Good Start, Improvement, Focus, Team, Status

To help start the day well

To support improvement

To reinforce focus on the right things

To reinforce the sense of team

To communicate what is going on

Objetivos de la daily meeting?


21/33

Daily meeting


22/33

Daily meeting


23/33

Revisin del Sprint

Cuando?


Que se hace?



24/33

Revisin del Sprint

Su principal objetivo es inspeccionar lo entregado por el equipo y obtener feedback de los

asistentes a la reunin para poder adaptar el plan para sprints subsiguientes.

Quin debe ser invitado a la reunin?

Lo ideal: todo el mundo.

De esta forma se ayuda al ScrumMaster y a la organizacin completa a entender que es

crucial maximizar el valor entregado por el equipo al concluir el sprint.

Las revisiones del sprint tienen muchas posibles consecuencias, incluyendo la

cancelacin del proyecto. En la mayora de las veces se autoriza al equipo a continuar

trabajando en un siguiente sprint y se decide el objetivo para el mismo.


25/33

Retrospectiva Cuando?Quienes estn a cargo?

Que se hace?



26/33

Retrospectiva

Elemento crucial de Scrum

Si no hacemos retrospectiva significa que solo nos enfocamos en el producto

Y estamos descuidando el proceso.Hacer retrospectiva es enfocarse tambin en la manera de hacer las cosas.

Luego de las retrospectiva debe haber compromiso de cambio,

Si no hay cambio, significa que la retrospectiva NO est funcionando, y se convierte solo

en un espacio para vomitar lo que no nos gusta y nada mas.

La Retrospectiva es RE-ADAPTACIN


27/33

La retrospectiva es la ltima reunin del sprint. Sigue inmediatamente despus de

la revisin y nunca debe ser omitida.

Mientras que la revisin est centrada en el producto, la retrospectiva se encuentra

enfocada en el procesola manera en la que el equipo Scrum trabaja de manera

conjunta, incluyendo habilidades tcnicas y prcticas y herramientas de desarrollo.

Si bien la revisin se encuentra abierta a quien desee asistir, la retrospectiva se

restringe a los miembros del equipo Scrumesto es el Product Owner, los

miembros del equipo de desarrollo y el ScrumMaster.

Cualquier persona ajena, incluyendo gerentes de cualquier nivel jerrquico, estn

excluidos, a menos que sean invitados por el equipo.


28/33

Partes principales de la R:

2- General Insights:por qu pas?

3- Prximos pasos: quhacemos?

1- Recoleccin de datos:qu pas?

A- Es un brainstorming, con los post-it se va

haciendo una especie de semforo.Importante: 1-nadie critica, 2-NO se analiza

B- se prioriza: se vota y reordena. De manera quequede evidente el dolor mas fuerte.

Propongo tareas, cambios concretos para el

prximo sprint,

Y SI asigno responsables.

Cuando tengo el dolor mas fuerte, se abre el

dilogo, comienzo a preguntar por qu (los 5 por

qu, la idea es que luego de preguntar 5 veces por

el origen de un problema, finalmente llegas a su

verdadera causa)


29/33

Feedback

1- Plantear que se quiere dar un feedback, pedir permiso

2- hacer referencias concretas, ejemplo: ayer diste una presentacin

3- explicar la consecuencia de eso que se hizo, el impacto que tuvo4- proponer hacer algo para cambiar/mejorar


30/33

Durante cada sprint el Product Owner organiza una o dos reuniones de las que debeparticipar todo el equipo Scrum y, si es necesario, otros stakeholders.

Estos se renen para estimar el costo de nuevos tems del backlog o recalcular el

tamao de tems de gran costo que debern ser subdivididos en otros ms pequeos,

de forma tal que puedan ser desarrollados en los prximos sprints.

Grooming/Refinamiento

Divide los items grandes

Analiza

Re-estima

Re-prioriza


31/33


32/33

TIPS

Los equipos necesitan dedicar entre un 5 a 10% de su tiempo durante el sprint

para poder preparar los sprints subsiguientes.

La reunin de estimacin descrita ms arriba es un buen ejemplo. Otros ejemplos

pueden ser workshops de redaccin de historias de usuario de planificacin de

release.


33/33

Links para ver:

http://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-

fuera-vos.html

http://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-

caras-y-4.html

http://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.html

http://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-

check.html
http://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.htmlhttp://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/08/dinamica-de-retrospectiva-north-check.htmlhttp://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.htmlhttp://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.htmlhttp://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.htmlhttp://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.htmlhttp://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.htmlhttp://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.htmlhttp://thomaswallet.blogspot.com.ar/2012/06/dinamica-de-retrospectiva-12358.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/12/dinamica-de-retrospectiva-3-caras-y-4.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.htmlhttp://thomaswallet.blogspot.com.ar/2011/10/dinamica-de-retrospectiva-si-fuera-vos.html

c reuniones

Documents