Scrum y Kanban, métodos ágiles para el desarrollo de software

Metodologías Ágiles:
Scrum y Kanban
Óliver Centeno Álvarez
[2012, Pronoide S.L.]

2
Contenidos
I. ¿Por qué Métodos Ágiles?
II. ¿Qué son Métodos Ágiles?
III. Algunas Técnicas Ágiles
IV. Scrum
V. Kanban
VI. Claves del Éxito

3
Contenidos
IV. Scrum
V. Kanban

4
¿Por qué Métodos Ágiles?
 Los Proyectos fallan
 No se entregan a tiempo
 No cumplen con los objetivos
 Cuestan más de lo estimado
 ¿De quién es la culpa?
 Hay demasiada documentación
 Hay muchos cambios
 La tecnología no es adecuada
 Los desarrolladores no son expertos
 La metodología falla (carrera de relevos)
 …

5
Principio Básicos de los Proyectos
 El Triángulo de Hierro
 Coste
 Tiempo
 Alcance
 Productividad
 Calidad
Coste
TiempoAlcance
Calidad y
Productividad

6
 El Software no son tuercas
 El software es complejo
 Siempre tendremos incertidumbre
 Siempre tendremos cambios
COMPLEJO
inestables
Req
conocidos
conocida Tecnología desc

7
 La magia no existe
 Productividad <> Más horas
 Mejora continua (Ishikawa)
 Mejora del proceso para ser más productivo
 Luchar contra el cambio no es efectivo
 Gestión del cambio  Burocracia
 Burocracia  Insatisfacción
 La incertidumbre disminuye con el tiempo
 Decide en el último momento responsable

8
 Realidad en los proyectos
 31-24% se cancelan
 53-44% son problemáticos
 16-32% tienen éxito
 Realidad en el software
 64% funcionalidades no se utilizan
 16% rara vez se utilizan
 20% se utilizan
 Gestión de proyecto inadecuada
 Ignorar los principios

9
 Modelo de desarrollo en cascada (Métrica v3)
 Realizar de manera exhaustiva: Análisis, Diseño,
Implementación, Pruebas, Despliegue, Mantenimiento
 ¿Qué valor aportan estos proyectos?
 ¿En qué coste incurren?
 Al 90% del proyecto el valor aportado puede ser casi nulo

10
 Modelo de desarrollo incremental (RUP)
 Realizar entregas periódicas que aportan valor
 Aportan valor desde la primera iteración
 Y siguen aportándolo de manera periódica
 Pero esto no es ágil…

11
 Modelo de desarrollo ágil
 No solo realizar entregas periódicas
 Sino priorizar las que aportan más valor
 El valor aportado al principio es mayor
 El valor aportado al final es menor

12
 Modelo de desarrollo ágil
 Esto nos da la oportunidad de añadir más valor en
subsiguientes iteraciones
 Y así poder continuar con el proyecto

13
¿Cómo transmito esto a mi cliente?
 Dilema del Prisionero (J. Forbes Nash)
 Teoría de Juegos

14
 Cuadrante de la Estupidez (C.M. Cipolla)
Proveedor
Cliente

15
 Compromiso Ágil
 Colaboración con el cliente, CONFIANZA
 Entregas progresivas (iterativo e incremental)
 Evitar el oportunismo
 Riesgo y beneficio compartidos
 Participación del cliente en el alcance
 Min = Estimación + factor foco (reuniones, plan,…)
 Target = Min + buffer (10%-30% según cliente)
 Max = Target + beneficios esperado
Target MaxMin
Beneficio Compartido Coste Compartido

17
 ¿Y los cambios?
 Los errores/bugs los asume el proveedor
 Las aclaraciones dependen del cliente
 Razonable: se puede asumir
 Conflictivo: …
 Los añadidos los asume el cliente
 Reestimación
 Mantenimiento <> Evolutivo

18
En Resumen…
 Los métodos ágiles buscan aportar el mayor valor
posible lo antes posible
 Dejando abierta la posibilidad de aumentar el valor
 Como efecto colateral permiten adaptarse a los
cambios
 Y responder al feedback del cliente
 La cancelación del proyecto sigue aportando valor
 Es especialmente útil en proyectos con una duración
y/o un coste fijos que buscan aportar el máximo valor
 No funcionan tan bien cuando se quiere seguir un
plan

19
Contenidos
IV. Scrum
V. Kanban

20
Manifiesto Ágil
 2001, Kent Beck et. Al.
“Estamos poniendo al descubierto mejores
métodos para desarrollar software,
haciéndolo y ayudando a otros a que lo
hagan ”

21
Manifiesto Ágil
 Valorar más:
 Individuos y su interacción
 Software que funciona
 Colaborar con el cliente
 Respuesta al cambio
 Por encima de:
 Procesos y herramientas
 Documentación
 Ceñirse a contratos
 Seguir un plan

22
Manifiesto Ágil
 Individuos y su interacción
 Los procesos ayudan al trabajo
 Las herramientas mejoran la eficiencia
 Pero sin personas con conocimientos y actitud
adecuados no se consiguen resultados
 Software que funciona
 Es difícil tener un documento con todos los
requisitos al inicio del proyecto
 Los prototipos generan un feedback enriquecedor
 El exceso de documentación genera mucho
trabajo que no aporta valor directo al producto

23
Manifiesto Ágil
 Colaborar con el Cliente
 Las necesidades del cliente cambian
 Un contrato no aporta valor al producto
 El cliente debe ser un miembro más del equipo
que colabora en el equipo de trabajo
 Respuesta al Cambio
 Los proyectos tienen cambios
 Asegurar un plan es difícil
 Anticipación y adaptación al cambio

24
¿Qué son todos esos conceptos?
 Desarrollo Lean y Ágil
 Frameworks y principios que usamos como guías
 Scrum
 Cómo aplicar las prácticas ágiles
 XP
 Prácticas específicas de desarrollo y pruebas
Lean
Ágil
Scrum
XP

25
Principios de Lean (Toyota)
 Eliminar los desperdicios
 Fomentar el aprendizaje
 Decidir lo más tarde posible
 Reaccionar lo más rápido posible
 Potenciar el equipo
 Conseguir la integridad
 Ver todo como un conjunto

26
Principios del Agilismo
 Satisfacer al cliente mediante entregas
tempranas y continuas de software de valor
 Doblegarse a los requisitos cambiantes
 Trabajo conjunto de personas de negocio y
desarrolladores
 Mantener la motivación de los individuos
 Aportarles los entornos y apoyo que
necesiten
 Confiar en su capacidad

27
Principios del Agilismo
 Comunicar la información cara a cara
 Utilizar el software que funciona como
medida de progreso
 Mantener un ritmo constante de trabajo
 Simplicidad y excelencia técnica
 Equipos auto-organizados
 Auto-reflexión periódica del equipo para ser
más efectivos

28
Métodos Ágiles
Metodología Acrónimo Creación Tipo de modelo Característica
Adaptive Software
Development
ASD Highsmith 2000 Prácticas + Ciclo de
vida
Inspirado en sistemas
adaptativos complejos
Crystal Methods CM Cockburn 1998 “Familia de
metodologías”
MA con énfasis en
modelo de ciclos
Dynamic Solutions
Delivery Model
DSDM Stapleton 1997 Framework / Modelo de
ciclo de vida
Creado por 16 expertos
en RAD
Evolutionary Project
Management
Evo Gilb 1976 Framework adaptativo Primer método ágil
existente
Extreme
Programming
XP Beck 1999 “Disciplina en prácticas
de ingeniería”
Método ágil radical
Feature-driven
development
FDD De Luca & Coad 1998
Palmer & Felsing 2002
“Metodología” Método ágil de diseño y
construcción
Lean Development LD Charette 2001, Mary y
Tom Poppendieck
“Forma de pensar” –
Modelo logístico
Metodología basada en
procesos productivos
Microsoft Solutions
Framework
MSF Microsoft 1994 Lineamientos,
Disciplinas, Prácticas
Framework de desarrollo
de soluciones
Scrum Scrum Takeuchi 1986 -
Schwaber 1995
“Proceso” (framework
de management)
Complemento de otros
métodos, ágiles o no

29
Actividades y Fases de Proyecto
 Todo proyecto incurre en una serie de actividades
 Toma de requisitos
 Diseño Arquitectónico
 Construcción
 Pruebas de Integración (internas)
 Pruebas de Sistema (externas)
 Estas actividades se realizan (o no) en fases
 Modelo de Ciclo de Vida
 Cómo se secuencian y particionan estas actividades
 Es determinante para que una metodología funcione

30
¿Por qué ese interés?
 ¿Qué es mejor?
 Modelo puramente secuencial (Cascada)
 Implica realizar todas las pruebas al final
 Y éstas derivan en cambios y agujeros en los requisitos
 Además, seguramente impliquen cambios de diseño
 Modelo puramente iterativo (XP)
 XP Implica centrarse en la construcción
 Se pierden de vista los requisitos y el diseño
 Al final se acumulan los requisitos cambiantes
100% Requisitos 100% Diseño 100% Construcción 100% Test

31
¿Por qué ese interés?
 Las prácticas ágiles sólo son efectivas si el modelo
de ciclo de vida es adecuado
 El modelo de ciclo de vida es el atributo definitorio de
un Método Ágil
 Indica si un método es o no es Ágil
 Se pueden hacer mucha o pocas iteraciones
 Con mucha o poca dedicación a cada actividad

32
Contenidos
IV. Scrum
V. Kanban

33
Historias de Usuario
 Característica escrita en una o dos frases
utilizando el lenguaje común del usuario
 Como {rol}
 quiero {algo}
 para obtener {valor de negocio}
 Forma rápida de administrar los requisitos sin
gran cantidad de documentos formales
 Debe ser limitada, escribible sobre un post-it
 Duración estimada: 10 horas - 2 semanas

34
 Tiene asociada una prioridad
 Tiene asociadas unas pruebas de validación
 No es una especificación rigurosa sino un
comienzo
 No es una tarea
 Cada historia es, en principio, independiente
 Las historias SON negociables
 Las historias son valiosas

35
 Las historias son estimables
 Días ideales
 Puntos de historia
 Triangulación
 Deben ser pequeñas y fáciles de entender
 Deben poder probarse para asegurar que
han finalizado
 Pruebas unitarias
 Criterio de aceptación
 Prototipos

36
 Beneficios
 Representan requisitos que pueden
implementarse rápidamente (días o semanas)
 Necesitan poco mantenimiento
 Mantienen una relación cercana con el cliente
 Permite dividir los proyectos en pequeñas
entregas
 Permite estimar fácilmente el esfuerzo de
desarrollo
 Ideal para proyectos con requerimientos no muy
claros

37
 Limitaciones
 Sin pruebas de validación pueden quedar abiertas
a distintas interpretaciones haciendo difícil
utilizarlas como base para un contrato
 Se requiere un contacto permanente con el cliente
durante el proyecto lo cual puede ser difícil o
costoso
 Podría resultar difícil escalar a proyectos grandes
 Requiere desarrolladores muy competentes
 Requieren saber cuando se puede considerar
hecha

38
 Ejercicio A
 Se quiere desarrollar un sistema sencillo de control de
préstamos en una biblioteca. El sistema debe admitir el alta
y la baja de socios y de libros. Los socios pueden pedir
libros en préstamo, pero no se pueden tener más de tres
libros en préstamo en un momento determinado. Los libros
se han de devolver antes de un mes de la fecha del
préstamo. Cada vez que un socio devuelve un libro después
de la fecha de la devolución, se penaliza reduciendo en una
unidad el número de libros que puede tener
simultáneamente. Cuando llega a cero el socio se dé de
baja automáticamente.

39
 Ejercicio B
 Se quiere desarrollar un simulador de Mus para
jugar online.
 Ejercicio C
 Se quiere desarrollar un simulador del juego de
cartas Bang! de Emiliano Sciarra.
 Instrucciones

40
 Ejercicio A
 Alta libro
 Baja libro
 Alta socio
 Baja socio
 Préstamo de libro
 Devolver libro
 Penalizar socio
 Baja automática de socio
 Iniciar sesión en el sistema
 Cerrar sesión
 Alta usuario
 Baja usuario

41
Planning Poker
 Estimación de tareas por consenso
 Utilizando cartas con valores:
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?,
 No tiene unidades, el objetivo no es dar un valor
 Se explica la característica a estimar y todos votan
excepto un moderador
 Los votos más extremos deben explicarse
 Se repite la votación hasta el consenso
 Evita el poder de alguien influyente
 Incluye el punto de vista del cliente

43
Planning Poker
 Ejercicio A
 Estimar cada una de las historias detectadas en el
ejercicio anterior
 Ejercicio B: Estimar
 Como usuario quiero poder ver los productos
disponibles para comprar ordenados por precio
y/o tipo de artículo para encontrar lo que busco
más rápido.
 Como usuario quiero poder ver los detalles de mi
pedido para saber en qué estado se encuentra y
si todavía estoy a tiempo de modificarlo.

44
Planning Poker
 Ejercicio C: Estimar
 Como usuario quiero poder pagar con tarjeta o
mediante Pay-Pall para tener distintas alternativas
en caso de no tener el número de tarjeta a mano.
 Como usuario quiero poder acceder a la
aplicación desde mi móvil para poder utilizarla en
cualquier parte.
 Como usuario quiero poder imprimir documentos
para poder llevármelos conmigo.
 Como usuario quiero poder ver la fecha y hora
actuales para no tener que salir de la aplicación
para ello.

45
TDD
 Test Driven Development
 Desarrollo Dirigido por Ejemplos
 Diseño e implementación de las pruebas antes de
programar la funcionalidad
 Pilares fundamentales:
 Implementar justo lo que necesita el usuario
 Y no más
 Minimizar el número de defectos a producción
 Crear SW muy modular y reutilizable

46
TDD
 No se trata de crear pruebas a granel
 Sino diseñarlas en función de los requisitos
 No implementar tareas
 Pensar en ejemplos sin ambigüedad
 La arquitectura emergerá de los ejemplos

47
TDD
 Un test NO se realiza para comprobar que un sistema no tiene
errores, NI para demostrar que funciona
 Un test se realiza para encontrar fallos (decisión fuerte)
 Se pueden probar las distintas fases de desarrollo
 Modelo en V

49
TDD
 ¿Cómo es un Test?
 Supongamos un sistema de gestión documental
public class Test{
public void testDocument() {
Document d = new Document("a", "t", "y");
assertEquals("a", d.getAuthor());
assertEquals("t", d.getTitle());
assertEquals("y", d.getYear());
}
}

50
TDD
 Aserciones
 Condiciones que deben darse para validar un test
 assertTrue("mensaje", condición)
 assertFalse("mensaje", condición)
 assertSame(objeto, objeto)
 assertNotSame(objeto, objeto)
 assertNull(objeto)
 assertNotNull(objeto)
 assertEquals(variable, variable)

51
TDD
 Fases de un test (rojo, verde, refactorizar)
1. Escribir el test
2. Compilarlo
3. Implementar lo justo para que compile
4. Ejecutarlo y comprobar que falla
5. Implementar lo justo para que pase
6. Ejecutarlo y comprobar que no falla
7. Refactorizar para simplificar y eliminar
duplicados
8. Repetir

52
TDD
 Ejemplo
 Programar una función de búsqueda
public void testResultadosVacios() {
Buscador b = new Buscador();
Resultado r = b.buscar("algo");
assertEquals(0, r.getNumResultados();
}

53
TDD
 Para que compile creo un stub de búsqueda
public class Buscador{
public Buscador() {}
Resultado buscar(String q) {return null;}
}
 El test compila pero falla, cambiamos:
Resultado buscar(String q)
{return new Resultado();}

54
TDD
 ¿Qué haríamos ahora?
 Probar que se encuentra 1 elemento
 ¿Cómo lo haríamos?
 Un nuevo test
 Un aserto encontrando un elemento
 Un aserto no encontrando el elemento
 ¿Algo más?
 Modificar el buscador para que el test pase

55
TDD
 Trucos y consejos
 Programar como si las clases y los métodos ya existieran
 Y refactorizar para que se generen automáticamente
 Una vez implementado extraer las interfaces de
programación
public interface Buscador{
Resultado buscar(String q);
}
public interface Resultado{
public int getNumResultados();
}

56
TDD
 Spikes
 Pequeño programa para explorar la
funcionalidad de una librería desconocida
 A partir de él podemos crear tests
 Mock
 Clase que sustituye una parte del sistema
 Para centrar el test en lo que vamos a probar
 Ej: Mock que simula una BD que no existe

57
TDD
 Frameworks de pruebas
 JUnit
 NUnit
 DBUnit
 Carga datos para un único test
 Pero no permite restaurar
 Hay que eliminar los datos anteriores
 HttpUnit
 Simula un navegador accediendo al servidor
 Permite acceder a enlaces, tablas, formularios,…

58
TDD
 Frameworks de pruebas
 Selenium IDE
 Plugin de pruebas de sistema para Firefox
 CubicTest para Eclipse
 JMeter
 Lanza pruebas de stress contra servidor
 Simulando múltiples usuarios concurrentes
 Genera informes y gráficos
 Mockito
 Librería Java para crear Mocks

59
ATDD
 Tests de Aceptación
 Afirmaciones en leguaje humano (ejemplos)
 ATDD es TDD enfocado a estos ejemplos
 Conexión perfecta entre Scrum y XP
 Se describen los ejemplos de cada historia con
el cliente
 Cada historia provoca preguntas
 Las respuestas son ejemplos
 Que se convierten en tests de aceptación

60
ATDD
 Tests de Aceptación
 Pueden ser funcionales o no funcionales (tiempo
de respuesta, capacidad de carga,…)
 Los detecta el analista
 Machacando al cliente hasta que dice “pero,
¿esto realmente importa?”
 Así comienzan a involucrarse

61
ATDD
 Ejemplos
 Cuando el libro X se añade al carrito, el sistema
devuelve un mensaje que dice: ‘‘El libro X ha
sido añadido al carrito’’
 Al mostrar el contenido del carrito aparece el
libro X
 El libro X ya no aparece entre los libros a añadir
al carrito
 Al introducir la fecha y hacer click en el botón de
añadir, se crea un nuevo registro vacío

62
ATDD
 Frameworks ATDD
 Concordion
 FitNesse
 Robot
 Cucumber

63
ATDD
 Ejercicio: Formular criterios de aceptación
 Quiero lanzar al mercado un software educativo para
enseñar matemáticas a niños.
 Necesito que puedan jugar o practicar a través de una
página Web pero también a través del teléfono móvil y
quizás más adelante también en la consola Xbox.
 El sistema debe recordar a cada niño, que tendrá un
nombre de usuario y una clave de acceso.
 El sistema registrará todos los ejercicios que han sido
completados y la puntuación obtenida para permitirles
subir de nivel si progresan.
 Existirá un usuario tutor que se registra a la vez que el niño
y que tiene la posibilidad de acceder al sistema y ver
estadísticas de juego del niño.
 El tema más importante ahora mismo es la aritmética
básica con números enteros.

64
ATDD
 Ejercicio: Formular criterios de aceptación
 "2 + 2", devuelve 4
 "5 + 4 * 2 / 2", devuelve 9
 "3 / 2", produce el mensaje ERROR
 "* * 4 - 2": produce el mensaje ERROR
 "* 4 5 - 2": produce el mensaje ERROR
 "* 4 5 - 2 -": produce el mensaje ERROR
 "*45-2-": produce el mensaje ERROR
 ¿Puede ser negativo el resultado de una resta
en nuestra calculadora?
 ¿Cual es el número más grande que se permite?

65
Contenidos
IV. Scrum
V. Kanban

66
Scrum
“El factor más importante en el desarrollo de software
no son las técnicas y las herramientas que emplean
los programadores, sino la calidad de los propios
programadores”
Robert L. Glass
“Estimo que el 75% de las organizaciones que utilizan
Scrum no van a obtener los beneficios que esperan”
Ken Schwaber
Scrum y XP desde las Trincheras
Henrik Kniberg

68
Scrum
 No es un método independiente, sino complemento
de otras metodologías (XP, MSF, RUP)
 Enfatiza valores y prácticas de gestión, no
cuestiones técnicas de desarrollo
 Equipos auto-dirigidos y auto-organizados
 No hay un Jefe de Proyecto que decida, solo “miembros del
equipo” o “cerdos”
 Excepción: el Scrum Master que debe ser 50% programador
y que resuelve problemas, pero no manda
 Los observadores externos se llaman “gallinas”; pueden
observar, pero no interferir ni opinar

69
Categorías en Scrum
 Primero una historia:
Una gallina y un cerdo pasean por la carretera cuando la gallina le
dice al cerdo: “¿Qué te parece si abrimos un restaurante?”, a lo
que el cerdo le pregunta: “¿y cómo se llamaría?”
La gallina le contesta: “Huevos con jamón” y el cerdo le replica:
“No estoy de acuerdo, porque en este negocio yo estaría
comprometido, mientras que tu sólo estarías implicada”

70
Categorías en Scrum
 ¿Qué queremos decir?
 Quienes tienen la responsabilidad
también tienen la autoridad necesaria
para poder lograr el éxito
 Para que quienes no la tienen no
puedan producir interferencias
innecesarias

71
Roles en Scrum (Cerdos)
 Dueño del Producto
 Product Owner
 Determina qué es importante
para el proyecto
 Determina la dirección en que
evoluciona el producto
 Equipo Scrum
 Analista, Desarrollador,
Tester,…
 Proactivos, multifuncionales,
autoorganizados, <10 por equipo

72
Roles en Scrum (Cerdos)
 Scrum Master
 Debe asegurar que el proyecto
progresa con suavidad
 Y que el equipo tiene lo que
necesita para tener éxito
 Establece reuniones
 Resuelve problemas
 Monitoriza el progreso del
proyecto

73
Roles en Scrum (Gallinas)
 Usuarios finales
 Marketing
 Áreas comerciales
 Áreas contables
 Administradores
 Etc

75
Sprint
 Iteraciones de 15-30 días (~3 semanas)
 Demostración a participantes externos al final
de cada iteración en una fecha indicada
 Al principio de cada iteración, plantear una
Meta expresada en términos de negocio
 Planificación del Sprint entre todos con una
agenda acotada (no alargar reuniones!!)
 Se selecciona una Pila de Sprint
 Historias que se van a incluir en el Sprint

76
Pila de Producto (Product Backlog)
 Lista priorizada de requisitos/historias
 Nombre, importancia, estimación, cómo probarlo,…
 Puntos de historia: días/persona ideales para
completar la historia

77
Pila de Sprint (Sprint Backlog)
 Historias ordenadas
por importancia de la
pila de producto que
se van a
implementar
 Tener en cuenta la
velocidad del equipo

79
División de las historias
 Al equipo le interesan tareas pequeñas
 Una historia se descompone en tareas
 No son entregables, el cliente no se
preocupa
 Pizarra/Tablón y post-its

80
Scrum Diario (Daily Standup)

81
Cambios durante el Sprint
 Durante un Sprint no se puede modificar el
contenidos de la pila
 El cliente puede cambiar una historia en las
reuniones mensuales (cambiando el alcance
y/o prioridad de una historia, o dividiéndola)
 Sólo el Scrum Master puede abortarlo
 Si la tecnología seleccionada no funciona
 Si las circunstancias del negocio han cambiado
 Si el equipo ha tenido interferencias

82
Alarmas
 Tareas terminadas de baja prioridad
 Exceso de tareas no planificadas

84
Al final de un Sprint…
 Hacer una demo para:
 Obtener reconocimiento para el equipo
 Que todos sepan lo que se está haciendo
 Obtener un feedback de los interesados
 Permite interactuar con otros equipos
 Fuerza a que realmente se terminen las cosas
 Auque haya poco y el resultado sea malo que
enseñar se motiva al equipo para que la próxima
demo sea mejor

85
Al final de un Sprint…
 En la demo, centrarse en:
 Presentar claramente el objetivo del Sprint
 No hacer florituras (PPT, detalles de implementación,…)
 Mantener un ritmo rápido
 Mantenerse a nivel de negocio, sin detalles técnicos
 Hacer una retrospectiva para ver
 Cosas bien hechas
 Cosas mejorables
 Ideas de mejora para el futuro

86
Ejercicio 1: Doggy Day Care
 Product Backlog:
 Crear carátulas, la marca y/o logotipo
 Definir las principales secciones de atención
 Describir requisitos mínimos (vacunas, temperamento, etc)
 Establecer la estructura de precios para los servicios
 Proporcionar testimonios de clientes satisfechos
 Crear perfiles de personal (antecedentes, formación,
intereses)
 Definir las ofertas de servicios
 Completar una póliza de garantía
 Definir un servicio "Ultra Perrito Spa"
 Definir servicios con descuento para socios
 Esquema el menú de la semana

87
Ejercicio 2: Turismo Marciano
 Definir las claves más importantes para el turismo marciano
 Describir un tour por el "Arte por Europa"
 Describir un tour por los "Deportes Humanos"
 Esquema de mensajes de advertencia (gravedad, oxígeno,
bacterias, hongos, etc)
 Explicar las opciones de viaje a/desde Marte
 Establecer precios de los tours
 Expedición a las "7 maravillas del mundo"
 Proponer opciones de ropa

88
Ejercicio 3: Wedding Planner
 Definir las principales ofertas de servicio
 Determinar el formato para el diseño de un folleto
 Incluir servicios para personas fuera de la ciudad
 Proporcionar referencias de clientes satisfechos
 Lista de recomendaciones para la recepción/localización
 Reunir los nombres de posibles proveedores de servicios
 Definir tratamientos especiales fiesta nupcial
 Establecer la estructura de precios
 Definir opciones de música
 Lista de opciones de catering y precios
 Definir los temas personalizados de la boda

90
¿Cómo funciona el equipo?
 Las métricas y medidas proporcionan una indicación
de dónde se puede mejorar
 Hay medidas informativas y motivacionales
 Las informativas pueden ayudar a mejorar los
procesos y a ser más efectivo y coordinado
 En los Métodos Ágiles interesan las informativas
 ¿Cómo las tomamos? Preguntado al equipo
 ¿Cuándo las tomamos?
 En el Scrum diario  Medidas de coordinación
 En la retrospectiva  Medidas de proceso

91
Diagrama Burndown
 Ver el progreso de tareas completadas en un Sprint
 ¿Se van a conseguir los objetivos del Sprint?
 Por encima de la diagonal  Exceso de historias
 Por debajo de la diagonal  Pocas historias

92
Diagrama Burndown
 Inicializarlo en la planificación
del Sprint
 Marcando en eje X el Nº de días
 Y en el eje Y el Nº de horas de
trabajo estimadas
 Marcar la tendencia ideal
 Si el ritmo de trabajo fuera
constante
 Actualiza el valor diariamente
 ¿Qué hiciste ayer? ¿Qué harás
hoy? ¿Qué problemas tienes?
110-
100-
90-
80-
70-
60-
50-
40-
30-
20-
10-
0-
‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘
1 2 3 4 5 6 7 8 9 10 11

93
Diagrama Burndown
 Diariamente se monitoriza
 Mirando las tareas pendientes
 Seleccionando las mejores tareas
para no desviarnos del ideal
 Cono de +/- 20%
 Si nos salimos del cono por debajo
 Añadir nuevas historias de la pila
 Porque somos así de buenos! 
 Si ocurre a menudo hay que mejorar
las predicciones
 Si nos salimos del cono por encima
 Eliminar impedimentos
 Hacer las cosas de otro modo
 Reducir el alcance
110-
100-
90-
80-
70-
60-
50-
40-
30-
20-
10-
0-
‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘
1 2 3 4 5 6 7 8 9 10 11

94
Diagrama Burndown
 NO OCULTAR EL DIAGRAMA
 Es una medida del progreso del proyecto y es importante
que el equipo y cualquiera que le interese pueda verlo
 ACTUALIZARLO A DIARIO
 Si no se actualiza a diario surgen tendencias horizontales
que nada tienen que ver con la realidad
 NO TENER EXCESO DE ESPECIALIZACIÓN
 El equipo podría elegir sólo las tareas que le interesa a cada
individuo y dejar las “aburridas” sin hacer
 UTILIZAR EL DIAGRAMA PARA CORREGIR
 Si la tendencia no es buena tomar medidas cuanto antes

95
Diagrama Burnup
 Representa las historias de usuario completadas
 Estimadas mediante puntos de historia
 Para un Sprint concreto
 Pero sólo cuentan las historias completas (hecho-hecho)
 Hecho-Hecho
 Se ha construido de manera adecuada
 Se ha construido el módulo adecuado
 Análisis, diseño, codificación, pruebas y aceptación
 Criterio de Aceptación

96
Diagrama Burnup
 Inicializarlo en planificación del Sprint
 Marcando en el eje X el Nº de días
 Y en el eje Y el Nº de puntos de
historia comprometidos
 Diariamente
 Marcar las historias hechas-hechas
 Esto impone un énfasis en terminar
las historias
 Las historias sin completar no aportan
valor
 No importa el trabajo “en progreso”
 Importa el feedback temprano
50-
45-
40-
35-
30-
25-
20-
15-
10-
5-
0-
‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘
1 2 3 4 5 6 7 8 9 10 11

97
Diagrama Burnup
 NO DESESTIMAR EL DIAGRAMA BURNDOWN
 El diagrama de Burndown refleja el progreso del equipo
 El diagrama de Burnup refleja qué tal lo están haciendo
 REALIZAR LAS PRUEBAS DE ACEPTACIÓN
 Si no se acepta, una historia no está hecha-hecha y no se
puede añadir al diagrama y pasará al siguiente Sprint
 UTILIZARLO PARA OBTENER FEEDBACK
 De manera continua y temprana
 Centrándonos en aportar valor de negocio

98
Velocidad del Equipo
 Medida de la cantidad de trabajo que puede
realizar el equipo en un Sprint
 Medido en cada Sprint
 Para mantener un histórico
 Basado en el trabajo real que han
completado
 Importan los resultados, no el esfuerzo
 Hecho-hecho

99
 Es una base para la planificación de tiempos
 Varía al cambiar miembros del equipo
 … y cuando hay vacaciones
 … y al aumentar la experiencia del equipo
 … y cuando se presentan problemas o
impedimentos
 …
 Permite estimar qué hará el equipo en
sucesivos Sprints

100
 Estimar la Pila de Producto
 Extraer las historias a comprometernos para el Sprint
 Ejecutar el Sprint y calcular la velocidad
 No se consideran las historias no terminadas
Velocidad
real = 18

101
Estimación de la Velocidad
 Opción 1: El tiempo que hizo ayer
 Nos comprometemos a realizar tanto trabajo como el que
completamos en el/los último/s Sprint
 Sólo sirve con equipos experimentados
 No sirve cuando el equipo cambia o hay vacaciones
 Opción 2: Cálculo de recursos
 Calcular la disponibilidad del equipo los días de Sprint
 Considerar el factor de dedicación del equipo pasado
Velocidad = [d/h disponibles] * [Factor de dedicación]

102
Seguimiento de la Velocidad
 La velocidad debería ser constante
 Si varía mucho algo están haciendo mal
 En los Sprints 3 y 4 es posible que estén pasando
por alto algunas pruebas y el sistema puede volverse
inestable
 Por eso en los Sprints 5 a 8 la velocidad ha bajado
0
5
10
15
20
25
30
35
1 2 3 4 5 6 7 8
Velocidad

103
En Resumen…
 Divide tu organización en equipo pequeños
 Inter disciplinares y autoorganizados
 Divide el trabajo en una lista de entregables
 Pequeños y priorizados
 Divide el tiempo en iteraciones cortas
 Con entregables visibles y testados
 Optimiza tus procesos

104
En Resumen…
 El gráfico de Burndown muestra el esfuerzo
pendiente en el Sprint actual
 El gráfico de Burnup muestra la cantidad de
software completo que se puede entregar
 La velocidad registra el histórico de software
completado por el equipo

105
Contenidos
IV. Scrum
V. Kanban

107
Kanban
 ¿Por qué Kanban?
 Scrum no sirve siempre
 Hay entornos con demasiados cambios
 El equipo no se puede comprometer a un Sprint
 Problema de las tareas urgentes
 Que surgen cada día
 Y duran más de una jornada
 No hay Sprint suficientemente pequeño
 Eliminar los Sprints y aplicar Kanban

108
Kanban
“El principio de Kanban es que comienzas con lo que
sea que estés haciendo, comprendes tu proceso … y
acuerdas los límites de trabajo … a continuación
comienzas a hacer fluir el trabajo … Kanban
proporciona transparencia al proceso y su flujo”
David Anderson
Kanban y Scrum – Obteniendo lo Mejor de Ambos
Henrik Kniberg
http://virtualkanban.net/

109
Kanban
 "Tarjeta visual"
 Fabricación de productos en la cantidad y
tiempo necesarios (Toyota 1940's)
 WIP
 Work In Progress
 Empezar algo nuevo sólo cuando el trabajo
anterior haya finalizado
 NO es Desarrollo de Software
 NO es Gestión de Proyectos
 Es Gestión Evolutiva del Cambio

110
Kanban
 ¿Qué es Kanban?
 Aproximación a la gestión evolutiva e incremental
de los cambios en procesos y sistemas
 Limitando la cantidad de trabajo en curso (WIP)
 Busca optimizar el proceso y terminar las tareas

111
Kanban
 ¿En qué se parece/diferencia de Scrum?
 Ambos son herramientas de proceso
 No son completas ni sirven para todo
 Ambos debo adaptarlos a mi equipo
 Scrum es más prescriptivo
 Kanban es más adaptativo
 Kanban tiene menos reglas (Haz lo que sea)

112
Kanban
 Kanban no habla de roles
 Kanban no habla de iteraciones
 Se pueden mezclar planificaciones y entregas
 Kanban limita el número de tareas WIP
 Máximo 2 tareas en curso y 5 pendientes
 Scrum limita las tareas por velocidad de equipo
 Ambos practican el "menos es más"
 Menos estados en las tareas
 Simplicidad en las soluciones (KISS, YAGNI)

113
Kanban
 En Scrum restringe cambios durante un Sprint
 Kanban permite sustituir un cambio por otra tarea
 En Kanban no hay restricciones del equipo
 Kanban no tiene técnicas de estimación
 Ambos admiten proyectos simultáneos
 Ambos son sistemas de planificación tipo "pull"
 Kanban no tiene Pila de Producto
 El equipo decide qué tarea completar

114
Kanban
 Ambos son empíricos
 Hay que experimentar para optimizarlos
 ¿Qué máximo de tareas en curso ponemos?
 Ambos tienen ciclos de feedback
 Retrospectivas Scrum
 Cuellos de botella y lead time Kanban
 Kanban tiene tiempos de respuesta menores
 No hay que esperar al siguiente Sprint
 Kanban admite interacción fuera del equipo

115
Kanban
 Tablero Scrum

116
Kanban
 Tablero Kanban

117
Kanban
 Principios Kanban
1. Empieza haciendo lo que haces ahora
 NO es un proceso nuevo, no hay que cambiar
2. Acepta cambios incrementales y evolutivos
 Es una buena forma de mejorar el sistema
3. Respeta roles, responsabilidades y procesos
 Es importante que no se vea como una amenaza
4. Fomenta el liderazgo en todos los niveles
 Es importante que la organización esté alineada

118
Kanban
 Cultura Kaizen
 "Mejora continua"
 El equipo tiene poder, se potencia al equipo
 El individuo actúa, detecta problemas y propone e
implementa soluciones
 Elige sus tareas voluntariamente, se autoorganiza
 La rama de gestión tolera los fallos
 Si el objetivo era mejorar el proceso/rendimiento
 Se respeta a los individuos y sus aportaciones
 Reduce desperdicios y costes de coordinación

119
Kanban
 Cultura Kaizen
 Adoptar una metodología ágil exige un cambio en
la cultura de la organización
 Se vuelve más flexible a los cambios
 Kanban se centra en optimizar lo que ya existe
 En lugar de cambiarlo todo
 A largo plazo mejora la madurez, capacidad y
cultura de la empresa

120
Kanban
 Prácticas Clave en Kanban
1. Visualizar el flujo de trabajo (real)
 Para que sea más entendible
 Generando el Tablón Kanban a partir del workflow
2. Limitar el WIP
 Implementando un sistema pull
 Que guía el proceso de desarrollo
3. Gestiona el proceso (flow)
 Monitorizar los estados del trabajo
 Evaluar el efecto de los cambios en el sistema

121
Kanban
 Prácticas Clave en Kanban
4. Explicitar las políticas de proceso
 Para evaluar los posibles problemas
 De manera objetiva y consensuable
5. Implementar ciclos de feedback
 Revisar el flujo de trabajo y distintas métricas
 Buscando cambios evolutivos
6. Usar modelos para detectar oportunidades
 Mejorar en colaboración
 Evolucionar por experimentación

123
Kanban
 ¿Cómo implementar Kanban?
 Modelar el flujo de trabajo
 Buffers entre los procesos

124
Kanban
 Tablón Kanban (card wall)

125
Kanban
 Límites WIP

126
Kanban
 Límites de capacidad de servicio

127
Kanban
 Relación entre equipos

128
Kanban
 Cadencias: Forma en la que organizamos
nuestros ciclos de trabajo

129
Kanban
 Un ejemplo
 Visualizar el Workflow

130
Kanban
 Un ejemplo
 Detectar problemas

131
Kanban
 Un ejemplo
 Limitar el WIP

132
Kanban
 Un ejemplo
 Mejorar el proceso

133
Kanban
 Un ejemplo
 Mejorar el proceso

134
Kanban
 Un día cualquiera en Kanban

135
Kanban

136
Kanban

137
Kanban

138
Kanban

139
Kanban

140
Kanban

141
Kanban

142
Kanban

143
Kanban

144
Kanban

145
Kanban

146
Kanban
 ¿Tiene que ser así?
 No, tú adaptas el Kanban
 Pero el flujo tiene que ser visual y suave
 Para minimizar el tiempo de entrega
 Adaptar las columnas y los límites WIP
 Límite bajo  Gente ociosa, poco productiva
 Límite alto  Tareas paradas, mala respuesta
 Lo mejor es que refleje el flujo de trabajo
 Si se alcanza el límite y estás parado busca
cuellos de botella

148
Kanban
 Implantar Kanban con Éxito
 Centrarse en la calidad
 Herramientas, inspecciones, patrones, TDD,…
 Reducir el trabajo en curso
 Entregas frecuentes
 Mejora las relaciones con equipos externos
 Balancear demanda y rendimiento
 Permite detectar cuellos de botella reales
 Priorizar
 Atacar las causas de variabilidad
 Mejora la predecibilidad (Teoría de Colas)

149
Kanban
 Implantar Kanban con Éxito
 Implantarlas de arriba abajo en orden
 Las primeras son más funcionales
 Las últimas pueden tener rechazo
 Cambiar el comportamiento es difícil
 Requiere diplomacia, tacto, inteligencia
emocional, psicología,… la confianza del equipo
 Abordar el último paso primero sobre las causas
que no requieran cambios en el comportamiento

150
Kanban
 Proporcionar Niveles de Servicio
 Establecer tipos y políticas de servicio
 Se pueden distinguir por colores en el tablón
 Establecer niveles SLA (criterio porcentual)
 Es un target controlable estadísticamente
 Tipos estándar:
 Bala de plata (operación crítica)
 Fecha fija de entrega
 Intangible (sin coste asociado al retraso)
 Normal

151
Kanban
 Métricas
 En Kanban no es relevante si un proyecto llega a
tiempo o si se está siguiendo un plan
 Lo importante es saber si es predecible
 Si el proceso fluye según lo esperado
 Si se busca la mejora continua
 Interesa la tendencia en el tiempo de indicadores
 Para detectar las posibles variaciones

152
Kanban
 Diagrama de Flujo Acumulado
 Gráfico que relaciona las tareas en curso
(tablero) con su estado concreto
 Muestra lo que tarda una tarea en pasar de la
pila a producción (lead time)
 Muestra a qué se está dedicando más tiempo
 Muestra el número de tareas en curso (WIP)
 Muestra algunos cuellos de botella
 Las bandas deberían ser estables

153
Kanban
 Diagrama de Flujo Acumulado

154
Kanban
 Lead Time
 Tiempo de ciclo
 Mide lo predecible que son las entregas
 Comparable con nuestra promesa SLA
 Reportar la distribución y el tiempo medio

155
Kanban
 Medidas de Rendimiento y Productividad
 Due Date Performance
 Rendimiento "en fecha"
 Porcentaje de items entregados a tiempo
 Analizar la causa raíz de las desviaciones
 Throughput
 Número de items entregados en un período
 Similar a la velocidad del equipo
 Indica si el sistema mejora continuamente

156
Kanban
 Flow Efficiency
 Medida del desperdicio en tiempo
 Relaciona el tiempo dedicado a una tarea
respecto al tiempo que pasa en el sistema (lead)

157
Kanban
 Medidas de Calidad
 Initial Quality
 Tasa de bugs por item
 Número de defectos que se han escapado
 En porcentaje respecto al WIP
 Failure Load
 Carga de trabajo por fallos
 Detectados por los usuarios
 Que han generado nuevas tareas

158
Kanban
 Valor Aportado
 Una tarjeta Kanban representa una tarea
 Derivada de una historia de usuario
 Se sabe que la historia aporta valor
 ¿Cuándo completo ese valor? ¿Cuánto valor es?
 ¿Qué valor tiene un flujo trasversal?
 Importa la característica (historia) no la tarea
 Minimum Marketable Feature (MMF)
 Minimum Marketable Release (MMR)

159
Kanban
 MMF
 Requisito de negocio "liberable al mercado"
 Caso de uso, Historia de Usuario, Backlog,…
 Compuesto de muchos items de trabajo
 Permiten disparar una entrega
 Manteniendo bajo coste y alta satisfacción
 Deben dividirse en items/tareas del flujo
 Tablón Kanban "en 2 niveles"

161
Contenidos
IV. Scrum
V. Kanban

162
Cultura y Estructura
 Agile no se implanta en un mes…
 Requiere cambios…
 En las Personas
 Es necesario tener un equipo de desarrolladores expertos
 Es necesaria una cultura de formación constante
 En los Procesos
 Los procesos pesados interfieren en los Métodos Ágiles
 Los equipos ágiles se autogestionan
 En las Herramientas
 Las herramientas ayudan a realizar el trabajo
 Pero no cambian la cultura de la empresa por sí solas

163
Cultura y Estructura
 Los cambios requieren tiempo
 Debemos alinear a clientes y gerentes
1. Utilizar buffers normalizados (midiendo!!!)
2. Hacer entregas frecuentes
3. Ser flexible en los cambios
4. Realizar pagos incrementales
5. Compartir los beneficios
6. Hablar con el cliente
7. Formar al cliente

164
7 Rasgos de un Gestor Efectivo
1. Habilidad para gestionar y manejar riesgos
2. Orientación a los resultados
3. Mucha energía
4. Sentirse parte del equipo
5. Ser capaz de dedicarse a múltiples tareas
6. Orientación a la mejora
7. Primero escuchar, después hablar

165
Efectividad del equipo
 El equipo tiene autoridad para tomar
decisiones
 El equipo tiene acceso al dueño del producto
 El equipo tiene un gran Scrum Master
 El equipo se reúne diariamente y está al
tanto de los proyectos actuales y futuros
 Todos los implicados asisten a reuniones
regulares

166
Efectividad del equipo
 El equipo utiliza la retrospectiva para mejorar
 El equipo sabe lo que significa hecho-hecho
 El equipo es responsable de las tareas que
se compromete y lo hace de manera seria
 El equipo es eficiente, productivo,
responsable, está motivado, organizado,
dedicado, bien gestionado

167
Cosas que “huelen mal”
 Falta de energía en el equipo
 No respetar los compromisos
 Equipo preocupado por el tiempo y no por la
productividad
 El equipo no quiere hacer demos
 El equipo no quiere hacer reuniones diarias

168
Cosas que “huelen mal”
 El equipo tiende a sobrestimar
 El equipo está desanimado
 Las reuniones diarias no son para el equipo
 Los roles son muy especializados
 El Scrum Master asigna las tareas

169
Sugerencias
 No buscar culpables, la culpa es del equipo
 Trabajar en conjunto como una unidad
 Mantener al equipo centrado y motivado
 Medir el nivel de agilismo de la empresa
 Personal
 % Cambios
 Cultura corporativa
 Impacto del producto
 Tamaño del equipo
 Dispersión del equipo

170
Diagrama de Radar
 Permite ver varias variables en un vistazo

171
Diagrama de Radar
 Peor cuanto más disperso

172
Diagrama de Radar
 Mejor cuanto más centrado

173
Más Claves [Antes de nada]
 Verificar que el proyectos necesita agilismo
 Si el tiempo o el presupuesto son críticos SÍ
 Si la funcionalidad/características es fija NO
 Estaríamos buscando un problema que no existe
 El enfoque incremental siempre es beneficioso
 Aplicar iteraciones en el momento adecuado
 Se puede iterar en cualquier momento (1-2 actividades)
 Cada iteración debe ser lo más compacta posible
 Iterar más rápido donde haya mayor riesgo
 Las release
 Planificarlas de manera interactiva y en ciclos cortos
 En ocasiones son puramente internas

174
Más Claves [Equipo]
 Realizar Sprints pequeños
 El progreso del proyecto es más visible
 Mantiene alta la moral
 Minimiza los cambios de rumbo
 Equipo = Desarrollador + QA + Gestor + Cliente
 Mejora la toma de decisiones
 Y esto mejora la ejecución
 Es importante un equipo disciplinado (Teoría Y)
 Utilizar estándares de codificación y buenas
prácticas

175
Más Claves [Pruebas]
 Realizar integraciones y compilados diarios
 Utilizar Frameworks de pruebas unitarias
 Automatizar las pruebas (TDD)
 Aprender de las retrospectivas
 Permite “afilar el hacha” de manera frecuente
 Permite añadir más valor al proyecto
 Evitar las reuniones “por reunirse”
 Realizar reuniones más cortas

176
Algunas herramientas
 http://www.agilebuddy.com
 http://www.agilezen.com
 http://atlassian.com/software/jira
 http://virtualkanban.net
 http://www.versionone.com
 http://www.tuneupprocess.com
 Silver Catalyst
 Greenhopper/Jira
 …

177
Epílogo
 Be Agile my friend

178
Epílogo
 No existen comidas gratuitas

Muchas gracias
Óliver Centeno Álvarez
[2012, Pronoide S.L.]

Scrum y Kanban, métodos ágiles para el desarrollo de software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Scrum y Kanban, métodos ágiles para el desarrollo de software

Similar a Scrum y Kanban, métodos ágiles para el desarrollo de software (20)

Más de Oliver Centeno

Más de Oliver Centeno (20)

Último

Último (20)

Scrum y Kanban, métodos ágiles para el desarrollo de software