Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Curso ScrumMaster

No description
by

Ed Lab

on 24 August 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Curso ScrumMaster

Entrada basada en supuestos del problema (no soy quien lo sufre)
-> existe error de entrada ( )

Se realiza una predicción de solución "bala de plata". (Acto de FE)

La solución se tiende a pensar uni - o bidimensional -> multidimensión

Desarrollo waterfall induce a
error acumulativo de proceso ( )

Medición al final del desarrollo ( + + )

Alto costo rediseño y corrección -> Proceso de desarrollo costoso e inducente a error

Predicción de tiempo irrelevante (Gantt) -> Alta varianza)

En :
El Origen de una Evolución
Eduardo Labarca
Fe vs Empirismo

Eduardo Labarca
?
Idea(Prob)
Requerimiento(Prob)
Solución
X
El modelo tradicional para diseño y desarrollo solución
Eduardo Labarca
t
+Info
+Preguntas
Entrada
cliente
investiga
Diseño
Solución!
Desarrollo
t
info
diseño
lab
0
t
t
todos al Lab!
+ Desarrollo
+
lab+1
t
y más Desarrollo
+
t
lab+n
Release
GANTT
t
eureka?
?
le sirve?
Supuestos e Implicancias modelo tradicional
E
Solución =
La Solución es:

................... !
diseño
t
=>
=>
P(X) =
x
X
X
Acto de FE
Caso 1: Problema Repetido o ¡Muy! Básico (ej.línea producción)



Caso 2: Problema Nuevo o Desconocido (ej.Innovación)
=> en TODOS son supuestos. Ausencia data empírica
diseño
t
= riesgo (t, $)
P(X) se encuentra en cluster?
P(X) -> 1
P(X) -> 0
X es multidimensional !!!
Asumiendo que
E
Solución =
X
Tecnología
Comercial
Funcionalidad
Integración
Proc.
Usabilidad (UX)
Adopción
Usuario
?
=> X(f)
Estimación de tiempo/ esfuerzo en modelo tradicional
... más aún en :
lab
t
GANTT
Alcance
Ppto
Tiempo
dev
=>
PREDICCIÓN:
Este equipo terminará este alcance en este
tiempo

Gauss
Pareto
Intuición / predicción
Desarrollo Tecnología
Simétrica
Mayor Prob. agrupada entorno a media
Baja Varianza
No Simétrica
Mayor Prob. no se agrupa
Alta Varianza!!!
Desarrollo Waterfall en t
Predicción de Tiempos y Esfuerzo
Asumamos -> buena predicción
predecir tiempo con carta Gantt tiene poco sentido, ya que la varianza es comparativa al dominio
80%
70%
90%
95%
Prob. = 47,8%
Finalizar a tiempo:
Si se considera además que la varianza es es equiv. a dominio
El modelo tradicional para diseño y desarrollo solución
CONCLUSIONES
¿Invertiría?
Baja probabilidad de predecir un buen diseño de solución

Proceso Control Empírico con
Aproximaciones Sucesivas

Proceso
Desarrollo o Creación
Entrada
Salida
RFP
Cluster
Solución
=>
lab
fte: http://pascal.gugenberger.net/thoughts/waterfall-accident.html

x
X
in
E
in
E
proc
E
proc
E
¿cómo mejoraría Ud.la probabilidad de éxito?
Sólo sé que
estoy aquí !
Punto de Muestreo - Lean Customer Development
Avance - Desarrollo Ágil
Generar Hipótesis X(f)
Visualización
Concepto

Experimentación
Test Hipótesis usando
MINIMUM
viable product
Pivotear
Morir
Continuar
Experimentando
Hipo-X(f)
Validado
Empírico
( Err -> 0 )
Pivotes
Desarrollo Ágil
punto de muestreo de X(f)
y corrección de desviación

in
E
proc
E
Disminuir + +
Alcance: debe ser acotado a lo justo para probar hipótesis

Ajustado
Producto-Mercado
MVP
HIPÓTESIS
X (f)
1
X (f)
2
X (f) -> X(f)
1
El cliente se involucra tempranamente y se hace parte del desarrollo

Desarrollo incremental reduce

La desviación y se corrige con entregables rápidos para testear con cliente

Se "prestó" $5MM al inicio para generar el producto y demoró de Sept. a Enero (4meses)

Con el producto actual se "prestó" $15MM para perfeccionar y nuevas características.

Crecimiento rápido a nuevas aplicaciones:
Prochile -> Australia, Canadá y Alemania

El modelo por control empírico y aprox. sucesiva
CONCLUSIONES
in
E
proc
E
ELO 308
Eduardo Labarca
Debe ingresar a
revisar zona
peligrosa
Revisa
estructuras
estén
en buen estado
Podrá ver lugares
que actualmente
no alcanza
Grandes
Mineras
Observacion remota
no expone a usuarios
Muy robusto,
pero que tanto?

$ vs. robustez?
Permite acceder
observar lugares
no accesibles
i1: Test cliente
con modelo 3D

i2: Prueba sólo con cámara y validación de las imágenes
i3: Prueba prototipo funcional: características supuestas + interfaz
i4: Test operado por cliente
i5: Entrega de equipo bajo acuerdo de colaboración
MINESPECTOR
....no se trata de Innovación - sino de Agilidad
Acquatico
Que cualquier niño pueda explorar y descubrir el océano
SUS EXPECTATIVAS
PARA ESTE CURSO
EQUIPO MULTIFUNCIONAL
Conversar y alinearse de acuerdo a conocimiento en SCRUM
Segunda dimensión: función de trabajo
Dividir en grupos multifuncionales (7 pers.)
Nombre Team, elegir PO y SM
Crear Backlog de estudio: que le gustaría obtener del curso individualmente y como equipo
Origen de SCRUM y Agile Manifesto
1993 - Jeff Sutherland desarrolló la metodología en Easel Co.

Inspiración: proy. SW siempre retrasándose y necesitando más recursos
-> "Debe existir una mejor forma"

1995 - se formalizó junto a Ken Schwaber

Proceso SCRUM se baso en diseno de procesos empíricos
Waterfall
Desarrollo Waterfall es tipo modelo de control de “proceso definido".
Se define plan al comienzo y se sigue en forma precisa hasta el final

Waterfall requiere minimizar las desviaciones o cambios en el plan para ser exitoso

En promedio 65% de los requerimientos cambian en desarrollo de software -> proyectos waterfall tienen una tasa mundial de éxito de 14%. (Jim Johnson, Standish Group, 2011)
Scrum
Basado en modelo de control de "proceso empírico", incorpora lazos cerrados de retrolaimetación para inspeccionar y adaptar.

Producto se construye en forma iterativa e incremental. En cada iteracion corta se logra funcionalidades 100% operativas. Se inspecciona resultado y se realizan los cambios.
Para inspeccionar y adaptar -> TRANSPARENCIA
Cuando aplicar SCRUM
Ogunnaike and Ray’s Process Control Requirements
AGIL requiere cambios mayores de organización, filosofía management y operaciones
Agile Manifesto
Individuos e interacciones
procesos y herramientas!

Software funcionando

documentación abundante!

Collaboration con cliente

negociación contrato!

Responder a cambios

seguir un plan!
sobre
sobre
sobre
sobre
Esto es, mientras que existe valor en los items a la derecha, nosotros valoramos más los items a la izquierda.
1.) Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.

2.) Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3.) Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al período de tiempo más corto posible.

4.) Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo
el proyecto.

5.) Los proyectos se desarrollan en torno a individuos
motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo.

6.) El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.

7.) El software funcionando es la medida principal de
progreso.

8.) Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.

9.) La inquietud continua hacia la excelencia técnica y al
buen diseño mejora la Agilidad.

10.) SIMPLIFICAR -el arte de maximizar la cantidad de trabajo no realizado - es esencial. (KISS)

11.) Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.

12.) A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivos, para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.
12 Principios - Agile Manifesto
• Equipos no estables o integrantes no asignados 100% a su equipo

• User stories deficientes, no hay clara definición de READY
(product owner deficiente)

• Abordando mucho en un Sprint y fallar en la entrega de software funcional (PIPE)

• Reunión Diaria no planteando y removiendo impedimientos

• No reparando bugs encontrados en Sprint, especialmente
bugs de integración

• Abordar muchas PBI en forma simultánea en un solo Sprint

• No tener un plan para interrupciones o emergencias

• No tener clara definición de DONE

• No realizar las mejoras identificadas en las retrospectivas

• Equipos sobrecargados (mal management, sin métricas de felicidad)
TOP 12 modos de fallar en SCRUM
Actividad 1:
Producción SCRUM

- Objetivo:
FABRICA DE AVIONES
Cada avión debe ser de ¼ de hoja carta
Cada integrante SOLO puede hacer 1 pliegue, y luego pasar el avión a otro integrante para el siguiente pliegue.
No deben tener punta
3 sprints


- Cada equipo se compromete con una producción
- CAda avión debe llevar el nombre del equipo
- Cada avión debe ser testeado por PO para volar 3 metros.
- Solo pueden ser testeados una vez; si falla, se descarta.
- Solo cuentan aviones que pasan test.
- WIP (aviones no terminados) se descartan después de cada Sprint.
• Cada equipo es responsable de auto-organizar y decidir como realizar el
trabajo, etc.
1 PERSONA = 1 PLIEGUE
¿QUÉ SUCEDIÓ?
SHU - HA - RI: aprender una técnica
SHU
: Scrum Master implementa proceso como está descrito en Scrum Guide. Retrospectivas van mejorando el desempeño.
HA:
El equipo produce software funcional, con todas las características testeadas y sin bugs al termino de cada sprint. PO cumple con READY y buenas PBI. El equipo tiene data en que ha doblado su velocidad y calidad. => hacia hiper-productividad
RI:
el Scrum Team funciona diferente. No parece SCRUM. Se logra hiper-productividad = sale live varias veces al día.
Ancestry.com - live 12 veces/día
Hubspot.com - live 170 a 270 veces/día
Framework SCRUM
ROLES
SCRUM MASTER
Facilitador
Experto en los procesos de Scrum
Coach del equipo y de PO para mejorar el desempeño
Remueve Impedimentos (cualquiera que este sea) que impidan un mejor desempeño
Proteje al equipo de interrupciones y de cualquier cosa que los saque del Sprint
Fomenta las buenas prácticas de ingeniería
Es dueño del proceso

RESPONSABLE DE MEJORAR PRODUCTIVIDAD Y DESEMPEÑO


Product Owner
Tiene la visión del producto
Logra motivar al equipo, a la empresa y a los clientes
Genera un Backlog que es "just enough, just in time"
Mitad de tiempo con clientes, ventas y marketing
Otra mitad trabajando cerca del equipo de desarrollo (clarificando especificaciones)
Entrega el set de características de producto que encanta al Cliente.....en el momento exacto y maximizando el valor de negocio
Responde a los cambios más rápido que los competidores

RESPONSABLE DE EL PRODUCTO TRIUNFE EN EL MERCADO
Equipo Desarrollo
Multi Funcional - integrantes pueden cubrir diferentes áreas
Auto Organizado - deciden como hacer el trabajo
Auto Gestionado - deciden cuanto trabajo pueden abordar en Sprint
Colaborativo - objetivo se logra en conjunto
Usualmente entre 3 a 9 integrantes máx.

RESPONSABLE DE EJECUTAR PBI Y LLEVARLAS A DONE
SCRUM MASTER
ESTRATEGIA INICIO
SCRUM MASTER
Entrenar a todos los integrantes en como tu haces SCRUM

Enfocar al equipo haciendo visible el Backlog

Acordar definicion de READY con PO y Team

Acordar definición de DONE

Asegurar que Backlog entre READY al Sprint Planning

Elimina rápidamente el mayor impedimento que tenga el equipo en el primer sprint

Asegura que sólo se expongan PBI que cumplen con DONE en el Sprint Review

Ejecutar buenas prácticas durante sprint

Medir felicidad del equipo

Fomentar comportamiento de
"ENJAMBRE"

ACTIVIDAD 2:
Estrategia: NO DEJAR A CLIENTE EN ESPERA

TOMAS
JAVI
ANDR
RODR
LAUR

TOMAS
JAVIERA
ANDRES
LAURA
RODRIGO
POLITICA:
no dejar nunca a un cliente en
espera
Ir de a una letra por nombre




ACTIVIDAD 2:
Estrategia: ENJAMBRE

TOMAS
JAVIERA


TOMAS
JAVIERA
ANDRES
LAURA
RODRIGO
POLITICA:
Limitar WIP = 1 cliente a la vez
Discusión que sucedió
Estrategia: ENJAMBRE

CRONOMETRAR
CRONOMETRAR
WEINBERG: pérdida por switching
EL ENJAMBRE SE PREOCUPA POR EL PRODUCTO COMPLETO
Efectividad Comunicación = clave éxito
Comm Waterfall
n(n-1)/2 para 120 pers = 7140
Comm SCRUM
n(n-1)/2 por equipo (5pers) =10
24 equipos(10) =240
+ alguna entre equipo
80% menos Comm
Definición de READY y DONE
BACKLOG
PASO 1

PARA "las empresas mineras de Chile"
QUIEN "tienen personas que corren riesgos en la faena"
EL "robot MINESPECTOR"
ES "un equipo de inspección remota"
A DIFERENCIA "de la inspección con personas"
PERMITE "no exponer a las personas"

La Idea
1.) Preparar y estimar los requerimientos del proyecto utilizando Planning Poker

2.) Determinar la Velocidad del Equipo

3.) Usando la tasa de gasto del equipo, calcular el presupuesto por iteración

4.) Agregar costos de capital

5.) Utilizando la definición de Done agregar costos pre y post iteración

6.) Agregar un margen de riesgo al total
Ejemplo para Calcular Presupuesto Proyecto en Agil
Waterfall vs Agile
Estimaciones
Fijos
Recur$o$
Tiempo
Requerimientos
Recur$o$
Tiempo
Features
Feature
Driven
Plan
Driven
Los requerimientos guian a estimados en plazos y recursos
Recursos y plazo definen que features podrán ser entregadas
Waterfall vs Agile
1.) Preparar y Estimar los requerimientos del proyecto usando Planning Poker
Crear el Backlog
Definir PBI's dentro del Release deseado
Estimar PBI de forma genérica (Planning Poker)
2.) Determinar Velocidad Equipo
Definir ciclos sprint (1-4sem)
Planificar Sprint 1 -> puntos PBI comprometidos = velocidad estimada inicial
(a medida que se vayan ejecutando se va modificando la velocidad con data real
3.) Utilizando la tasa de gasto del equipo, calcular el presupuesto por iteración
A partir de la velocidad estimada y del total de puntos de PBI para el release, calcular cantidad de ciclos (sprints) necesarios
Ej.: 1000 pts, veloc=50pts/sprint -> 20sprints

Calcular el gasto del equipo por ciclo:
convertir salario bruto por persona a equivalente por ciclo sprint
(Ej.: 1.800.000bruto ->400.000/sprint semanal)
sumar el costo total con todos los integrantes del equipo.

Multiplicar costo total equipo por ciclo x ciclos sprint
4.) Agregar otros costos capital, activos, etc
Se realiza una estimación general de costos siginificativos en equipos, insumos, herramentas, otros. Evitar detalles.
5.) Utilizando la definición de Done, agregar costos pre y post iteración

Si bien los equipos son multidisciplinarios, existen costos indirectos que se escapan; abogados, contables, logística, oficina, etc.
6.) Agregar un margen de riesgo al total

En base al riesgo y la incertidumbre del proyecto, es posible agregar un factor de riesgo
A medida que el equipo ya ha trabajado, conocerá su velocidad real y tendrá mejores estimaciones, por lo que el presupuesto será más preciso
SPRINT
Grooming - Qué y Cuándo ?
Estimación esfuerzo PBI: puntos o tiempo
Planificación Sprint
Antes - ready, velocidad, restricciones, disponibilidad equipo, objetivo del sprint
Durante -

SPRINT
Motivación equipo
Swarming
Dimensión de equipo

SPRINT
Burndown / Burnup
Kanban
Sprint Review
Retrospectiva y Kaizen
Scrum of Scrums

Q&A
Estimación
LEGO

EXAMEN FINAL

3
Sprint 1
Visión General
La necesidad de una nueva estrategia
Diseno de soluciones: fe vs empirismo
AWFUL IDEA = -1
WEAK IDEA = 1
SO-SO IDEA = 5
GOOD IDEA = 10
GREAT IDEA = 15
BRILLIANT IDEA = 20
-------- ---------
NO EXECUTION = $1
WEAK EXECUTION = $1000
SO-SO EXECUTION = $10,000
GOOD EXECUTION = $100,000
GREAT EXECUTION = $1,000,000
BRILLIANT EXECUTION = $10,000,000

To make a business, you need to multiply the two.
La ejecución lo es todo
requieres un ejecución brillante!!!
y un team que sepa ejecutar
(retención talento)

"Super Angel"
MVP y el algoritmo de búsqueda
Sprint 2
El framework de Scrum: Roles
La Agilidad
Call Center no Scrum!
Sprint 3
El framework de Scrum: Artefactos y Actividades
Framework SCRUM
Artefactos y Ceremonias
Artefactos
El Backlog




El Grooming
Artefactos
Sprint Backlog
Artefactos
Visualización y Transparencia
Burndown
KANBAN
Actividades: SPRINT PLANNING
Se define meta para proximo Sprint
Dev Team revisa items mayor prioridad
Dev Team se compromete con ciertos items (realista y ritmo sustentable)
Team descompne cada item en tareas TBD
Se le asigna un esfuerzo en puntos o tiempo
Actividades: DAILY MEETING
máximo de 15 minutos.

timebox, con tiempo predefinido y fijo, de pie (standup meeting) no extender

El Daily Scrum permite inspección y adaptación ciclo rápido (diario)

Cada miembro contesta: qué logró hacer durante el dia, qué trabajará al día siguiente y qué obstáculos le impiden avanzar
Actividades: REVIEW MEETING
Revisa trabajo DONE (finalizado) por el equipo de desarrollo.
Asiste scrum team, involucrados y stakeholders, entregar feedback .
En esta instancia se define si el ítem puede ser considerado como terminado (done) o no.
Si se rechaza, el ítem quedará nuevamente en el backlog.
Todo el feedback que se recoja de esta reunión alimentará el backlog con nuevos items, modificaciones o incluso algunos ítems pueden ser eliminados.
Actividades: RETORSPECTIVE MEETING
Mejorar la forma en que se lleva a cabo el desarrollo.
Expone todo lo que no está funcionando o que está impidiendo al equipo avanzar en la forma que se debe.
Scrum Master debe remover cualquier impedimento, para mejorar la productividad del equipo.
Permite ir adaptando el Scrum a las preferencias propias de cada empresa
Actividades: GROOMING
Corresponde al PO mantener actualizado el Backlog
Sprint 4
La columna vertebral de Scrum: EL SPRINT
Definición de Ready
y Definición de DONE
Definición de Ready

estado y cantidad de detalle que debe tener cada ítem de Backlog antes de Sprint Planning.
Preparación previa de los ítems, a fin de que la reunión sea fluida y se cuente con toda la información necesaria
Definición de DONE
Definición de DONE ?
Liberable
Testeado Unidad/Integracion + Lista para Test Aceptación + Implementación en Servidor
Test Aceptación Ok + Liberable + Documentado + NO aumenta deuda técnica (no corrompió el código?)
mínimo para definición de Done:
porción completamente funcional del producto (incluyendo diseño, desarrollo, integración, test y documentación, que proporcione valor al cliente)
NUNCA DEJAR QUE ALGO QUE NO CUMPLA CON “READY” ENTRE AL SPRINT, NI QUE ESCAPE ALGO QUE NO ESTÁ “DONE”.

EL SPRINT
1. Duración Corta

Transparencia, evita tiempo prolongado donde se pierda visibilidad
Motivación, pequeñas metas
Acota el Error
Planificación fácil
Feedback Rápido (iteración hypo)
Mejora ROI, permite entregables con valor al cliente en forma temprana
EL SPRINT
4. Incremento de Producto Entregable

Cada Sprint DEBE generar un PIPE o pequeña funcionalidad lista
se va a acumulando valor $ real
se optimiza el esfuerzo vs. resultado
EL SPRINT
2. Timeboxed

Propicia el cierre de tareas
Evita perfeccionismo inecesario
Hace visible el progreso, ir mostrando avances tangibles frecuente y constante (clientee, gerente, etc)
Limita el WIP
Mejora la predictibilidad (vs Gantt),
EL SPRINT
3. Objetivo no modificable

objetivo de un sprint es un contrato o compromiso inamovible entre el Product Owner y el Equipo de Desarrollo
El objetivo de un sprint resume un propósito claro y simple del negocio, que debe ser alcanzado durante el sprint
sí es posible clarificar o detallar dicho objetivo
Solo PO puede cancelar sprint
Sprint 5
Waterfall vs Agile
Cuando Usar Scrum
Swarming
Sprint 6 (hasta 16.40pm)
Planing Poker
Velocidad
Burnup- Burndown
(disminuir prob. generar grasa)
STARTUP tiene días y recursos contados

GRASA aumenta Prob. MUERTE

-> NO Grasa = +Prob SobreVivir
Visualización
Concepto
PASO 2

PASO 3 MVP

Grandes Mineras
Grandes
Mineras
Debe ingresar a
revisar zona
peligrosa
Debe ingresar a
revisar zona
peligrosa
PLANTAS
MANTENCION
CORREAS
Grandes
Mineras
Autonomo
autoguiado
Test
"Imagen
Remota"
Usarán
la imagen
en informe
PASO 4 AGREGAR VALOR

USD$100
5 días

Pivotear
Continuar
Experimentando
Ajustado
Producto-Mercado
Ajustado
Producto-Mercado
PASO 5 PRIORIZAR

NO INVIERTAS NI UN $ EN DESARROLLAR ALGO QUE NO TIENE EVIDENCIA EMPIRICA
Eduardo Labarca
...sólo invierte en conseguir la evidencia
$
$
$
$
$
UNIVERSO DE SOLUCIONES
X(f)
CURSO SCRUM
1 post-it = 1 idea
"El Porqué"
(WHY)
HOW
"EL CÓMO"
"EL CÓMO"
HOW
"EL CÓMO"
SCRUM
MARCO DE TRABAJO (FRAMEWORK) para
OFICIAL CERTIFICACION
PROBLEMAS COMPLEJOS
=> entrega máximo valor
productiva y creativamente
DEF:
ES:
ligero
fácil de entender
difícil de dominar
NO ES:
proceso o técnica
SCRUM
CONTROL PROCESO EMPÍRICO
OFICIAL CERTIFICACION
TRANSPARENCIA
información visible
definicón "DONE" común
INSPECCIÓN
ADAPTACIÓN
(toma de decisiones en base a experiencia)
de artefactos
progreso hacia objetivo
frecuente pero
sin interferir
corregir desviaciones
progreso hacia objetivo
frecuente pero
sin interferir
SPRINT PLANNING
DAILY SCRUM
SPRINT REVIEW
SPRINT RETROSPECTIVE
DEV TEAM
SM
auto-organizados
TODAS las habilidades necesarias para generar incremento
Unidad de cargo, no hay exepción
no hay sub-equipos (pruebas, qa, etc), no hay expeción
Responsabilidad en equipo como un TODO
capta interacciones con personas externas
=> "líder sirviente": RESPONSABLE QUE SCRUM se entienda y adopte
SCRUM
OFICIAL CERTIFICACION
EQUIPO SCRUM
(1x)Product Owner - (1x)Srum Master - Development Team
PO
autorganizado -> NO lo dirige nadie externo al equipo
multifuncionales -> TODAS las competencias para el trabajo
=> ENTREGA PRODUCTO ITERATIVA E INCREMENTAL
=> MAXIMIZA EL OBTENER FEEDBACK
responsable de (puede delegar)
del Product Backlog
priorizar PB => optimizar trabajo y valor creado
asegura PB claro y entendible
asegura que Equipo Desarrollo entiende cabalmente todo
=> RESPONSABLE MAXIMIZAR VALOR DE PRODUCTO Y DE TRABAJO DEL EQUIPO
=> TODA LA ORG RESPETA DECISION DEL PO
=> NADIE PUEDE PEDIR TRABAJAR EN OTRO ITEM
=> RESPONSABLE DE ENTREGAR
INCREMENTO PRODUCTO DONE
(a pesar de expertos en ciertas áreas)
mínimo 3
máximo 9
(s/PO-SM)
al PO
al DevTeam
a la Org
técnicas gestión PB
entender necesidad PBI claros
entender planificación del producto
asegurar PO conoce como priorizar
facilitar eventos Scrum
(si se requiere)
guiar hacia Auto-organizado y multifuncional
ayudar a crear productos con alto valor
eliminar impedimientos
facilitar eventos Scrum
guiar en organizaciones
liderar y guiar adopación
planificar implementación
enseñar a otros empleados
motivar cambios => increm. product.
Sinergia con otros SM para adopción
SCRUM
OFICIAL CERTIFICACION
EVENTOS SCRUM
TIME-BOX (duración máxima)
REGULARIDAD Y CONSISTENCIA
minimizar reuniones no definidas
=> SPRINT es TIMEBOX:
=> Otros eventos:
NO se puede alargar ni acortar
Acortar si se logra objetivo antes
Si falta algún evento se reduce inspección y adaptación
SCRUM
OFICIAL CERTIFICACION
EL SPRINT
TIME-BOX : 1 mes o menos. (evita riesgo/costo aumente)
OBJETIVO: crear INCREMENTO PRODUCTO "DONE" (potencialmente a producción)
SPRINT: Planning, Daily, "trabajo desarrollo", Review y Retrospective
=> un Sprint COMIENZA inmediatamente después de que finaliza el ANTERIOR
EL SPRINT
SPRINT PLANNING
SPRINT GOAL
SPRINT REVIEW
SPRINT RETROSPECTIVE
SCRUM
OFICIAL CERTIFICACION
PLANNING MEETING
TIME-BOX: 8 horas/mes
Scrum Master => Suceda y se entienda Propósito
PO ayuda a clarificar PBIs
SCRUM
OFICIAL CERTIFICACION
SPRINT GOAL
META a alcanzar con el INCREMENTO del Sprint
Guía para el equipo - Por Qué-
Si cambia cantidad de tareas, DevTeam puede negociar con PO...PERO objetivo SIEMPRE se mantiene
SCRUM
OFICIAL CERTIFICACION
REVIEW
TIME-BOX: 4 horas/mes
Inspección del INCREMENTO
Capturar Feedback para adaptar PB
Asiste Equipo Scrum y stakeholders invitados por PO
DevTeam explica trabajo DONE
PO explica que PBI se llevó a DONE y cual No.
Revisión y adaptación para actualizar PB
SCRUM
OFICIAL CERTIFICACION
RETROSPECTIVE
TIME-BOX : 3 horas/mes
Equipo Scrum se inspecciona a sí mismo -> Plan de Mejoras
Después de Sprint Review - Antes de Planif. próximo Sprint.
SM es responsable del proceso Scrum -> dirige esta reunión
¿Cómo fue último sprint (personas, relaciones, procesos, herramientas, etc)?
JAMÁS se cambia el objetivo del SPRINT
Alcance puede modificarse, previa negociación entre PO y DevTeam
DURANTE
CANCELAR
Sólo PO puede decidir cancelar, si Objetivo SPRINT -> Obsoleto
¿Qué puede ser entregado como INCREMENTO?
¿Cómo se hará el trabajo?
PO discute OBJETIVO SPRINT => qué PBI necesarios
Sólo DevTeam define cuantas PBI es capaz de lograr
INPUT:
PB, último Incremento, capacidad proy. y rendimiento DevTeam
Finalmente: El equipo Scrum acuerdo Objetivo Sprint.
DevTeam toma PBI, analiza y define => SPRINT BACKLOG
si prefieren pueden planificar sólo los primeros días
Dev Team puede renegociar PBIs (demasiado o muy pocas)
Dev Team puede invitar "asesores especialistas"
DAILY SCRUM
SCRUM
OFICIAL CERTIFICACION
DAILY SCRUM
TIME-BOX: 15 minutos
DevTeam sincronize actividades
Trabajo desde Daily pasado y hasta el sgte.
SM asegura que suceda y timebox - NO modera!
Sólo participa DevTeam
DevTeam dirige Daily.
CONSISTENCIA = mismo lugar - misma hora
Discusiones para detallar, replanificar o adaptar => inmediatamente después
BENEFICIOS
Mejora comunicación y sincronización
Elimina necesidad de otras reuniones
Identifica y elimina impedimentos
Promueve toma decisión rápida
Mejora nivel de conocmiento DevTeam
USUALMENTE HACE QUE SE MODIFIQUE EL PB
¿Cuales son los elementos más relevantes que salieron bien y posibles mejoras?
¿Crear plan para implementar mejora en próx Sprint.?
Full transcript