Upload
jose-maria-salvatierra
View
212
Download
6
Tags:
Embed Size (px)
DESCRIPTION
Infografía sobre el desarrollo ágil, scrum, lean y kanban para descubrirlo de un vistazo
Citation preview
Manifiesto Ágil
User Story
2
Desarrollos ágiles, SCRUM, lean y Kanban
de un vistazo
El ciclo de vida ágil
es iterativo e
incremental
SCRUM
Manifesto for Agile Software DevelopmentWe are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more
MoSCoW
INVEST
Para comprobar la
calidad de una user
story se puede usar la
técnica INVESTI Independent
N Negotiable
V Valuable
E Estimable
S Small
T Testable
Iteración
Func
iona
lid
ad1
Ciclo de Vida
Mensaje 1: #AgilidadA bierto al cambio
auto G estion del equipoI terativoL iderado por el product owner
Marzo 2014
3
Predictivo Adaptativo
El “product owner”
Asigna valor a las User Stories
Decide cuales pasan al product
backlog y cuales no
Los participantes (equipo,
product owner, usuarios…)
crean user stories
Autor de la infografía: JM Salvatierra
El “product owner” es aquella persona
• con una visión muy clara del producto que se quiere desarrollar,
• es capaz de transmitir esa visión al equipo de desarrollo y,
• además, está altamente disponible para transmitirla
• Acepta el producto software al finalizar cada iteración
El “SCRUM master” es
responsable de que se sigan las
prácticas SCRUM. Lidera el equipo
respetando el principio de
autogestión.
El “Equipo de desarrollo”
tiene las siguientes características
• Autogestionado
• Multifuncional
• No distribuido
• Tamaño optimo 5-9 personas
El “Product Backlog” es
el listado de User Stories que se
incorporará al proyecto.
Evoluciona continuamente
Está ordenado
Product Owner y Equipo
Mensaje 2: El que inventó el postitno sabe que gran avance aportó al mundo de la informática.@JoseMaria_SZ #Agilidad
M Must
S Should
C Could
W Won’t
Para asignar valor a las user
story se puede usar la técnica
MoSCoW y así agruparlas
según la prioridad
SCRUM
Es un “Framework”* popular que se
centra en la gestión de proyectos
ágiles.
*Framework significa que es un conjunto de
buenas practicas que necesitaran adaptarse
al proyectoUn SPRINT es una
iteración
Duración entre 2 – 4 semanas
Sprint release: Sprint especial en
la que el software se pone en el
entorno productivo
To do Done :o)OnGoing
El Sprint Backlog es el listado de User Stories
seleccionadas para ser implementadas en el
SPRINT
El Tablero Scrum se
usa para dar
seguimiento al Sprint
Backlog durante el
sprint
Daily Scrum
Sprint Review Meeting
Sprint Retrospective
WEEK XWEEK 2WEEK 1 L M X J VL M X J V L M X J V
El BurnDown chart representa dentro de un
sprint, la evolución en el tiempo del trabajo
pendiente (remanente) real frente al planificado
Reunión Diaria 15 minutos
Cada persona explica:
• Lo que hizo el día anterior
• Lo que va a hacer es este día
• Problemas
Final del sprint No más de 4 H
• Se presenta lo que se ha hecho
• EL PO verifica y obtiene input
para actualizar el backlog
Reunión al final del sprint
Duración: No mas de 4H
No se hace siempre
Se utiliza para la mejora de
procesos
Se recoge en una tabla
• Aspectos positivos
• Aspectos negativos
Sprint planning Meeting
Reunión al Inicio del Sprint
Duración: No más de 8 H
El PO presenta las user stories
Se seleccionan las US que se
implementarán en el sprint y se
confecciona el Sprint Backlog
“Stakeholders” son usuarios, otros PMs, etc cualquier persona
afectada por el proyecto, pueden proporcionar user stories
pero solo a través del product owner
SPRINT
Mensaje 3: Si sacas un café al empezar la Daily Scrum meeting, al terminar tiene que estar todavía caliente @JoseMaria_SZ #Agilidad
4Planificación Ágil
Puntos Historia
Los puntos historia sirven para estimar
las user story
Los PH estiman un compendio de
esfuerzo complejidad tamaño
Es una técnica subjetiva
Lo que importa son los valores relativos
de una historia frente a otra
Planning Póker
Una vez elegida el user story de referencia y el rango de valores,
se puede emplear la planning póker como técnica para estimar el
resto de user stories
Se hace en grupo y se valora por consenso
Velocidad
Es la cantidad de trabajo que un
equipo puede hacer en una iteración
El trabajo puede medirse en horas,
en puntos historia, u otro sistema
TECNICA 1
Selecciona la historia más pequeñas y
asignarle 1 punto historia. al resto se
le asignarán puntos historia en función
de su complejidad respecto a ésta.
TECNICA 2
Elige un rango (de 1 a 10 o Fibonacci)
Selecciona una historia media y dale
valor 5. al resto se le asignarán puntos
historia en función de su complejidad
respecto a ésta.
1
Presentación
de historia
de usuario
2 Elección de
la carta
Estimación
4 Consenso 3 Publicación
Velocidad Iteración: Por ejemplo las
suma de los puntos historia de la user
stories realizadas en un iteración seria
la velocidad de esa iteración
Velocidad media por sprint de un
Proyecto: sería la media de las
velocidades iteración para un
proyecto dado
Histórico de velocidad media del equipo: es el número de puntos historia que de media hace nuestro equipo por
itereación y/o proyecto. Sirve para, en base al histórico:
• Estimar para proyectos nuevos las iteraciones necesarias y por tanto el tiempo requerido para completar las
user stories
• Valorar el rendimiento del equipo
𝑡𝑖𝑒𝑚𝑝𝑜 =𝑃𝑢𝑛𝑡𝑜𝑠 𝐻𝑖𝑠𝑡𝑜𝑟𝑖𝑎
𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑
Estimación de tiempo
1. El equipo de desarrollo se
reúne y estudia las user
stories
2. Cada uno de manera secreta
estima los puntos de la user
story
3. Todos a la vez descubren la
estimación
4. Si hay consenso se toma el
valor consensuado, sino se
reinicia el proceso volviendo
a estudiar la user story
Los valores son inherentes a un equipo
concreto. No se pueden hacer
extrapolaciones directas a equipos
distintos
LEAN y KANBAN
Lean
Lean significa fabricación esbelta,
intenta evitar el efecto push.
La estrategia lean se base en 3 pilares:
• Construir sólo lo necesario
• Eliminar lo que no añade valor
• Parar si algo no va bien ( cero
defectos)
Principios lean
1 Eliminar desperdicios
2 Amplificar el aprendizaje
3 Decidir lo más tarde posible
4 Entregar lo más rápido posible
5 Capacitar y potenciar el equipo
6 Construir con calidad
7 Ver el todo
Lean y desarrollo ágil son cosas
distintas pero complementarias
Los 7 desperdicios lean software
1 Trabajo realizado parcialmente
2 Características extra en el software
3 Reaprendizaje
4 De mano en mano
5 Las pausas
6 Los cambios de tareas
7 Defectos
ordenes de trabajo entran tan pronto se
generan, provoca sobrecargas, stock,
tiempos de parada en los cuellos de
botella, incluso pude colapsar el flujo
To doSprint Backlog
Done :o)OnGoingWIP = 2
Tablero Kanban
El tablero ha de ser visible para todo
el equipo.
En relación a ágil, el tablero kanban
sería equivalente al tablero SCRUM
Tarjetas Kanban
Las tarjetas Kanban son las work
orders, las tareas.
En relación a ágil, las tarjetas
kanban serían las user stories
Proceso
El tablero se divide en columnas,
cada una representa un paso o
fase en el workflow para procesar
la work order.
En el caso ágil, se puede asimilar a
las columnas SCRUM
WIP
Cada fase tiene un WIP (work in
progress limit). Limita el número de
work orders que pueden estar en
dicha fase a la vez.
PULL
Kanban evita el efecto push limitando las
ordenes de trabajo que entran en el flujo
mediante los WIP
Una línea de producción organizada de
este modo, regulada no por las ordenes
de trabajo sino por la producción es PULL
Kanban
Es una forma visual de gestionar la
producción, de hecho kanban significa
tarjetas visuales.
Kanban es una técnica Lean
Kanban se base en 3 pilares:
• El flujo de las tareas ha de ser visible
• El trabajo en progreso está limitado
• Hay que medir los ciclos de trabajo
Flujo Kanban
• Las work orders avanzan en el
flujo de izquierda a derecha en
la medida que el WIP se lo
permite
• Se recomienda que el tamaño de
las work orders sea homogéneo
El flujo Kanban se mide mediante
los parámetros:
• Lead time es el tiempo total
que un ítem pasa en el tablero
• Cycle time es el tiempo de
trabajo efectivo sobre el ítem
PUSH
Una línea de
producción
PUSH es en
la que las
Más sobre ágil en:
http://desarollosagilesvistazo.blogspot.com.es/
Más sobre ágil en:
http://desarollosagilesvistazo.blogspot.com.es/
Mensaje 4: @JoseMaria_SZ#AgilidadAGILEAN = Agil + leanSCRUMBAN = SCRUM + kanban
SCRUMBAGIELEAN = SCRUM + kanban + agil + lean