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

Aceite Argentina - Scrum training

No description
by

Esteban Ramallo

on 5 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Aceite Argentina - Scrum training

Scrum!
Por qué Scrum? Por qué no Waterfall?
Estadísticas
31% de los proyectos de TI son
cancelados
53% de los proyectos de TI cuestan el
doble
de lo estimado
Apenas
16%
son completados en plazo y costo estimados
desarrollando soft de la misma manera...
¡¡¡40 (cuarenta) años!!!
El 64% de las funcionalidades se usa
nunca
o
muy rara vez
Yo creo que con Waterfall... estamos bien...
40 años
"Mejor" no le digamos nada al cliente
Te suena...?
Este bug seguro no lo ven...
Eso se prueba en producción...
Pidieron eso, si no tiene sentido... y bue...
No importa si hay una mejor forma... ellos quieren eso
Etapa
gigante
de relevamiento de requisitos
Una vez que empieza el diseño, el cliente no tiene idea de
nada
Lo próximo que ve el cliente es la
aplicación terminada
, lista para probar...
Expectativa
Realidad
¡¡¡Esto no es lo que yo quería!!!
Un Framework que no ayuda...
Documentación
exhaustiva
Muchos
procesos
Muchas
herramientas
Roles
estrambóticos
Resultado
Cliente irritado
Faltan funcionalidades
Las que están no convencen
Quiere cambios
Pero lo más importante:
Comunicación sólo al
principio
y al
final
pero
mucha
desmotivación
Esto genera mucha... mucha...
Tiene que haber otra forma...
Roles
Qué es scrum?
Ceremonias
Un poco de historia
Y entonces qué es?
Lean IT
Lean (orígenes)
Comenzó con Toyota en los años '30 (TPS)
Más tarde implementado en sistemas
Filosofía / disciplina de gestión de eficacia comprobada con el tiempo
Promueve remover todo tipo de
desperdicio
Tiene un histórico comprobado en la promoción de mejoría simultánea de
costo,

calidad,

velocidad
y
agilidad
7 principios Lean
Entender cómo el cliente percibe el
valor
Remover el
desperdicio
de las cadenas de valor end-to-end
Fluir
limpiamente de principio a fin
Construir lo que está
empujado por el cliente
, no construir para stock
Buscar la perfección a través de
mejora continua
Agile manifesto
Eliminar desperdicio
Amplificar aprendizaje
Dar poder al equipo
Fomentar integridad
Ver el todo
Retrasar compromiso
Entregar rápido
funcionalidad innecesaria
mala comunicación
defectos
cambio de tareas
funcionalidad incompleta
testing cuanto antes
feedback constante
base de conocimiento
basar decisiones en hechos
esperar al último momento responsable
dejar que la solución emerja
feedback rápido
maximizar ROI (return on investment)
escucharlo
dejarlo tomar decisiones
desafiarlo
mediante la aplicación de las buenas prácticas
ver la cadena end-to-end
aplicar principios en la cadena de valor
revisar el proceso continuamente
En marzo de
2001
un grupo de visionarios, convocados por Kent Beck, se junta para discutir sobre nuevas formas de desarrollar software y crean lo que se llama el manifiesto ágil, que exponemos a continuación
Individuos e interacciones

por sobre procesos y herramientas
Software funcionando
por sobre documentación exhaustiva
Colaboración con el cliente
por sobre negociación contractual
Responder al cambio
por sobre seguir un plan
Scrum es un proceso
ágil
Es un
framework
de desarrollo
iterativo
e
incremental
Centrado en dar el más
alto valor de negocio
en el
menor tiempo
Permite
rápida
y
repetidamente
inspeccionar el desarrollo
El negocio fija las prioridades
Los equipos se
auto-organizan
a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad
Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorandolo en otra iteración
Hasta ahora vimos...
Históricamente se desarrolló usando
waterfall
Estas metodologías son llamadas
"pesadas"
o
"heavyweight"
Estas metodologías traían muchos
problemas...
Para el
"usuario"
(nosotros desarrolladores),
Para el
"cliente"
, insatisfecho
Con esta motivación, surge
agile
, conocida como
"liviana"
o
"lightweight"
...después de
40 años
de no hacer
nada distinto
Product Owner (PO)
Scrum Master
El equipo
Define las
funcionalidades
del producto

Prioriza
de acuerdo al valor de negocio

Maneja
fechas
y
contenidos
de releases

Responsable por la
rentabilidad
del producto (ROI)

Acepta
o
rechaza
los resultados
Representa la
gestión
del proyecto

Responsable de promover los
valores y prácticas de Scrum

Remueve impedimentos

Se asegura de que el equipo es completamente
funcional
y
productivo

Permite la estrecha
cooperación
en todos los
roles
y
funciones

Escudo
del equipo de interferencias externas
Multidisciplinario
(dev, test, web dev, arch)

Chico
- Típicamente 5-9 personas

Prioriza
de acuerdo al valor de negocio

Auto-organizado

Con
autonomía
y
poder de decisión
"Mientras que existe valor en los items de la derecha, valoramos los items de la
izquierda
más"
Planning
Daily
Demo
Retrospectiva
Artefactos
Product backlog
Sprint backlog
Burndown chart
Lista de
requisitos
(llamados user stories) escritos por el PO
Priorizado
por Busines Value
Al comenzar el proyecto, el equipo
estima
el backlog
Debe incluir todas las
features
visibles al cliente
Debe tener cierto grado de detalle
Los items de mayor valor de negocio deben abrirse en items menores, que se puedan
estimar
y
probar
Es el artefacto de la
sprint planning
El equipo se compromete a entregar las stories
más prioritarias
del product backlog
Estas stories pasan a ser el sprint backlog
Son las
stories
que el equipo va a trabajar durante el siguiente
sprint
Muestra día tras día el
progreso
del sprint
La
unidad
la elige el equipo (story points, stories, tasks)
Siempre presente en el
pizarrón
Se recalcula generalmente en la daily
Permite
actuar
en consecuencia (tomar más stories o renegociar scope)
Objetivo: planificar la próxima iteración (
sprint
)
Con el
product backlog
, el equipo selecciona las stories que se compromete a terminar
Las stories se toman una a una, hasta que se "llena el sprint"
Las stories se estiman usando alguna técnica (como por ejemplo "
planning poker
")
Las stories se separan en
tareas
tangibles
Las tareas no deben llevar más de 1 día de trabajo
Cómo empieza todo?
Había una vez un cliente, que tuvo una idea
Buscó la mejor compañía para llevar a cabo su idea, y fue así como llegó hasta nosotros:
Tuvimos una
reunión
con el cliente para relevar su necesidad
En esta reunión, armamos una "lista de deseos" llamada
product backlog
El product backlog es exactamente eso. Una lista de lo que
el cliente quiere
, escrito de una manera particular: con
user stories
Una vez hecho esto, el product backlog se ordena por
valor de negocio
El cliente decide qué stories necesita más. Qué stories lo hacen
más feliz
. Dicho de otra forma,
qué lo hace más infeliz NO tener
As a
User
,
I want
to search by airline
so that
I only see flights operated by that airline
User story #1
As a
User
,
I want
to search by airport
so that
I only see flights for that airport
User story #2
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
Todas estas stories juntas forman lo que se llama el
product backlog
del sistema
En este caso particular, del sistema de
reservas de vuelos
Product backlog
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Business value: __
Estimation: __
Vamos a verlo con una historia que dice así...
El equipo estima este
backlog
en
tamaño
Se usan unidades genéricas, llamadas
story points
Esto mide el
tamaño total
del proyecto y
relativo
de cada story
En base a este análisis, se genera una
propuesta
para el cliente (costo, tiempo, gente)
Llegamos a un acuerdo
Y entonces empezamos
As a
User
,
I want
to search by airline
so that
I only see flights operated by that airline
User story #1
As a
User
,
I want
to search by airport
so that
I only see flights for that airport
User story #2
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
Product backlog
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
Business value: 20
Estimation: 8
Business value: 19
Estimation: 5
Business value: 18
Estimation: 8
Business value: 17
Estimation: 13
Business value: 16
Estimation: 21
Business value: 15
Estimation: 3
Business value: 14
Estimation: 1
Business value: 11
Estimation: 3
Business value: 10
Estimation: 5
Business value: 9
Estimation: 1
Business value: 13
Estimation: 5
Business value: 12
Estimation: 3
Business value: 6
Estimation: 13
Business value: 7
Estimation: 21
Business value: 8
Estimation: 2
Con el backlog estimado, tanto en valor de negocio como en tamaño...
Vamos a tener ciclos de desarrollo, llamados
sprints
El equipo toma las stories una a una, hasta "completar" un
sprint
Esta nueva lista de stories se llama
sprint backlog
Las stories se toman usando el business value como parámetro
Toda story dentro del sprint backlog tendrá mayor valor de negocio que la siguiente y menor que la anterior
As a
User
,
I want
to search by airline
so that
I only see flights operated by that airline
User story #1
As a
User
,
I want
to search by airport
so that
I only see flights for that airport
User story #2
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
Product backlog
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
Business value: 20
Estimation: 8
Business value: 19
Estimation: 5
Business value: 18
Estimation: 8
Business value: 17
Estimation: 13
Business value: 16
Estimation: 21
Business value: 15
Estimation: 3
Business value: 14
Estimation: 1
Business value: 11
Estimation: 3
Business value: 10
Estimation: 5
Business value: 9
Estimation: 1
Business value: 13
Estimation: 5
Business value: 12
Estimation: 3
Business value: 6
Estimation: 13
Business value: 7
Estimation: 21
Business value: 8
Estimation: 2
As a
User
,
I want
to search by airline
so that
I only see flights operated by that airline
User story #1
As a
User
,
I want
to search by airport
so that
I only see flights for that airport
User story #2
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
Sprint backlog
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
As a
[user]
, I want
[functionality]
so that
[business value]
User Story #...
Business value: 20
Estimation: 8
Business value: 19
Estimation: 5
Business value: 18
Estimation: 8
Business value: 17
Estimation: 13
Business value: 16
Estimation: 21
Business value: 15
Estimation: 3
Business value: 14
Estimation: 1
Business value: 11
Estimation: 3
Business value: 10
Estimation: 5
Business value: 9
Estimation: 1
Business value: 13
Estimation: 5
Business value: 12
Estimation: 3
Business value: 6
Estimation: 13
Business value: 7
Estimation: 21
Business value: 8
Estimation: 2
Este número representa el valor de negocio de la user story
Hay varios métodos para calcular este número
Sólo nos interesa que las user stories tengan un valor "desambiguable"
Este número representa el tamaño de la user story
También hay varios métodos para calcular este número
Nos interesa que para el equipo tenga sentido
User story #1
1 story point
User story #2
2 story points
User story #4
4 story points
User story #3
2 story points
Este proyecto tiene
4 stories
El tamaño total es de
9 story points
Podemos decir que la story #4 es
el doble de grande
que la story #2
La story #4 es a su vez
4 veces más grande
que la story #1
La story #1 es
1/9 del proyecto
La story #4 es
4/9 (casi la mitad) del proyecto
Proyecto 1
Orígenes
Después de esto, al final del proyecto, el cliente está feliz por el valor entregado por el equipo y ya es hora de festejar :D
Pero antes...
Terminemos de formalizar un poco los conceptos!
Es una reunión... sí,
diaria
:D
Duración de
15 minutos máximo
Se hace
parados
y
frente al pizarrón
No es una reunión de
status
No es una reunión de resolución de problemas
Es una reunión en la que cada miembro le cuenta al resto del equipo:
Qué hizo ayer
Qué va a hacer hoy
Si hay algún obstáculo en su camino
Es una reunión en la que se le muestra al cliente el trabajo del equipo
Al
final
de cada sprint
Informal
, sin diapositivas, se muestra el resultado
Todo el equipo
participa
Se invita a todo el mundo (stakeholders)
Al
final
de cada sprint
Se revisa entre
todo el equipo
Qué fue
bien
(para repetirlo)
Qué se podría
mejorar
(y cómo)
La duración depende del sprint y del tipo de retrospectiva (hay muchas técnicas)
El equipo se compromete a mejorar "x" cosas tangibles para el próximo sprint
Es, también, un momento de catársis grupal :)
Preguntas?
Full transcript