Curso taller: Día 2

Analista de negocios y parte probador.

El product owner es el punto central facultado de liderazgo del producto.

El product owner tiene que ver por lo menos en dos direcciones al mismo tiempo:◦ Negocio ◦ Equipo

El product owner también debe asegurarse de que se especifiquen los criterios para la aceptación de las características y de las pruebas que verifican que esos criterios se cumplan

Gestionar la economía

Participar en la planificación

Pulir el product backlog(Grooming)

Definir los criterios de aceptación y compruebe que se cumplen

Colaborar con el equipo de desarrollo

Colaborar con los grupos de interés

Habilidades de dominio◦ Es un visionario

◦ Sabe que no todo se puede anticipar

◦ Tiene experiencia en negocios y administración de dominio

Habilidades con la gente◦ Tiene una buena relación con las partes

interesadas

◦ Es negociador / un generador de consenso

◦ Es un gran motivador

◦ Es un buen comunicador

Toma de decisiones ◦ Está facultado para tomar decisiones

◦ Está dispuesto a tomar decisiones difíciles

◦ Toma una visión económica para equilibrar los problemas técnico / económicos

◦ Es decisivo

Rendición de cuentas◦ Acepta la responsabilidad por el producto

◦ Es comprometido y disponible

◦ Actúa como un miembro del equipo Scrum

Reuniones de Release Planning

Coloreando el Backlog

Midiendo PBIs y estimando el Product Backlog

Velocidad

Asignando Sprints

Seguimiento del progreso – El release Burndown

Planning Poker

Lanzamiento despues de multiples sprints

Lanzamiento despues de cada sprint

Lanzamiento después de cada característica(continuous deployment)

La planificación de lanzamiento no es un evento de una sola vez.

La planificación Lanzamiento inicial sigue lógicamente la conceptualización / planificación a nivel de producto.

El propósito de la planeación del producto es de imaginar lo que debe ser el producto, el objetivo de la planificación de liberación es para determinar el siguiente paso lógico hacia el logro de la meta de producto

Pueden ser revisados como parte de cada revisión de sprint o en el curso normal de la preparación y conducción de cada sprint posterior.

Cuando ocurre el Release Planning

Involucra la colaboración de los stakeholdersy el esquipo Scrum completo

La participación exacta de cada persona con el tiempo puede variar.

Las entradas del release planning incluyen salidas de planeación de producto (productplanning):◦ Visión del producto

◦ Product backlog de alto nivel

◦ Plan de trabajo del producto

◦ La velocidad del equipo o equipos que trabajará sobre la liberación.

Una actividad que se repite en la planificación de la liberación es confirmar las limitaciones de la liberación: ◦ alcance

◦ fecha

◦ presupuesto

Revisarlos para ver si es necesario realizar cualquier cambio, dado el avance obtenido.

Cada liberación debe tener un conjunto bien definido de características mínimas liberables (MFR).

Las MFR iniciales de una liberación podrían definirse durante conceptualización.

Actividad de Planeación de Liberación

Product Backlog Grooming: Creación, estimación y priorización más detallada de los elementos del product backlog. ◦ Ocurre en múltiples puntos en el tiempo:

Después de la planificación de productos, pero antes de la planificación de liberación inicial

Como parte de la actividad de planificación inicial de liberación

Durante cada sprint conforme sea necesario

La velocidad es la cantidad de trabajo realizado cada sprint

Se mide sumando los tamaños de los PBIs que se completan al final del sprint.

La velocidad se utiliza para dos propósitos importantes:◦ Planificación a nivel de Liberación◦ Planificación a nivel de Sprint

A efectos de planificación, la velocidad es más útil cuando se expresa como un rango, por ejemplo, "El equipo suele ser capaz de completar entre 25 y 30 puntos cada sprint."

En cada sprint el equipo trabaja en un conjunto de elementos de trabajo pendiente del producto

El equipo y el product owner no deciden en que ítem específico se va a trabajar hasta la planeación del sprint.

Usando la velocidad del equipo, podemos aproximar un conjunto de ítems del productbacklog para cada sprint agrupándolos de forma tal que la suma de tamaños sea lo mas cercana a la velocidad promedio del equipo.

Un grafico de burndown para una liberación con alcance fijo muestra la cantidad total de trabajo sin finalizar que queda por hacer después de cada sprint para alcanzar nuestro objetivo.

En este tipo de gráfico, los números de eje vertical son en las mismas unidades que utilizamos para el tamaño de nuestros elementos de product backlog(normalmente puntos de la historia o los días ideales). El eje horizontal representa los sprints

Es una técnica para el dimensionamiento PBIs

Es una técnica para el dimensionamiento PBIsque fue descrita por primera vez por James Grenning (Grenning 2002) y luego popularizado por Mike Cohn (Cohn 2006).

El equipo de desarrollo estima historias de forma individual (utilizando un mazo de cartas con números como uno, tres y cinco puntos sobre ellos) y luego compara los resultados colectivamente

Basada en el consenso

Opinión de los expertos

Intenso debate

Tamaño relativo

Agrupación precisa

Apalancamiento al estimar historia

El equipo completo de Scrum participa al realizar PlanningPoker. Durante la sesión, el product owner presenta, describe y aclara los PBIs.

El ScrumMaster ayuda al equipo para aplicar mejor el Planning Poker. El ScrumMaster también está constantemente buscando personas que, por su lenguaje corporal o por su silencio, parecen estar en desacuerdo y ayuda a hacerlos participar.

Y el equipo de desarrollo está generando colaborativamente las estimaciones.

Cada miembro del equipo de desarrollo está dotado de una serie de tarjetas de Planificación de Poker

Carta Interpretación

0 Indica que el ítem ya se ha completado o que es

tan pequeño que no tiene sentido siquiera darle

un número de tamaño.

1/2 Se utiliza para elementos de tamaño diminuto

1, 2, 3 Se utiliza para elementos de tamaño pequeños

5, 8, 13 Se utiliza para elementos medianos. Para

muchos equipos, un elemento de tipo 13 sería la

más grande que se programará en un sprint.

20, 40 Se utiliza para los elementos de tamaño grande

(por ejemplo, características o de nivel de

tema).

100 Una gran característica o una historia épica

∞ (infinito) Se utiliza para indicar que el elemento es tan

grande que ni siquiera tiene sentido poner un

número en él.

? Indica que un miembro del equipo no entiende

el elemento y está pidiendo al product owner

aclaraciones adicionales.

π(pi) o taza de café Break

1. El product owner selecciona un PBI que ser estimado y lee el elemento para el equipo.

2. Los miembros del equipo de desarrollo discuten el elemento y hacer preguntas aclaratorias para el dueño del producto, que responde a las preguntas.

3. Cada estimador selecciona de forma privada una tarjeta que representa su estimación.

4. Una vez que cada estimador ha hecho una selección privada, todas las estimaciones privadas se exponen simultáneamente a todos los estimadores.

5. Si todo el mundo selecciona a la misma tarjeta, tenemos consenso, y ese número se convierte en el consenso estimación de PBI.

6. Si las estimaciones no son las mismas, los miembros del equipo participan en un debate específico para exponer los supuestos y malentendidos. Normalmente empezamos preguntando a los estimadores más altos y más bajos para que expliquen o justifiquen sus estimaciones.

7. Después de la discusión, volvemos al paso 3 y se repite hasta que se llega a un consenso.