Presentación del Dia 2 de Introdcción a metodos agiles y scrum . Impartido en el Tecnológico de Alvarado campus Medellín.

1. Curso taller: Día 2

2. Analista de negocios y parte
probador.

3. 

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

4. 





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

5. 
Habilidades de dominio
◦ Es un visionario
◦ Sabe que no todo se puede anticipar
◦ Tiene experiencia en negocios y administración
de dominio

6. 
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

7. 
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

8. 
Rendición de cuentas
◦ Acepta la responsabilidad por el producto
◦ Es comprometido y disponible
◦ Actúa como un miembro del equipo Scrum

10. 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

11. 


Lanzamiento despues de multiples sprints
Lanzamiento despues de cada sprint
Lanzamiento después de cada
característica(continuous deployment)

12. 
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.

13. Cuando ocurre el Release Planning

14. 

Involucra la colaboración de los stakeholders
y el esquipo Scrum completo
La participación exacta de cada persona con
el tiempo puede variar.

15. 
Las entradas del release planning incluyen
salidas de planeación de producto (product
planning):
◦
◦
◦
◦
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.

16. 
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.

17. 

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.

18. Actividad de Planeación de Liberación

19. 
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

20. 
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."

22. 


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 product
backlog para cada sprint agrupándolos de
forma tal que la suma de tamaños sea lo mas
cercana a la velocidad promedio del equipo.

24. 

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

26. Es una técnica para el
dimensionamiento PBIs

27. 

Es una técnica para el dimensionamiento PBIs
que 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

28. 





Basada en el consenso
Opinión de los expertos
Intenso debate
Tamaño relativo
Agrupación precisa
Apalancamiento al estimar historia

29. 

El equipo completo de Scrum participa al realizar Planning
Poker. 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

30. Carta
0
1/2
1, 2, 3
5, 8, 13
20, 40
100
∞ (infinito)
?
π(pi) o taza de café
Interpretación
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.
Se utiliza para elementos de tamaño diminuto
Se utiliza para elementos de tamaño pequeños
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.
Se utiliza para los elementos de tamaño grande
(por ejemplo, características o de nivel de
tema).
Una gran característica o una historia épica
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.
Break

31. 1.
2.
3.
4.
5.
6.
7.
El product owner selecciona un PBI que ser estimado y lee el elemento
para el equipo.
Los miembros del equipo de desarrollo discuten el elemento y hacer
preguntas aclaratorias para el dueño del producto, que responde a las
preguntas.
Cada estimador selecciona de forma privada una tarjeta que
representa su estimación.
Una vez que cada estimador ha hecho una selección privada, todas las
estimaciones privadas se exponen simultáneamente a todos los
estimadores.
Si todo el mundo selecciona a la misma tarjeta, tenemos consenso, y
ese número se convierte en el consenso estimación de PBI.
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.
Después de la discusión, volvemos al paso 3 y se repite hasta que se
llega a un consenso.