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