Un poco más de Agile y Scrum à la Pablo

Waterfall
Agile y Lean Startup
Scrum - Contexto
Scrum - Roles
Scrum - Eventos
Scrum - Herramientas
De qué vamos a hablar

(2003 – 2008)
Ing. Informático
UPV
(2008-2011)
Program
Manager
Microsoft
(2011-2014)
Product
Manager /
Product Owner
Softonic
(2015-2015)
Product
Manager /
Agile Coach
Packlink
(2015-2015)
Product
Manager /
Agile Coach
EsLife
(2015 – 2016)
Agile Coach
Pocketworks
(2016-Ahora)
Product
Manager
Schibsted
(Milanuncios)
Certified
Professional
Scrum Master
Scrum.org
Y tú, ¿quién eres?

Requisitos
Análisis
Diseño
Desarrollo
Validación
Mantenimiento
Waterfall

Cuando la cascada se queda seca…

Hay que saber exactamente qué se quiere desde el principio
– Se confía en que los requisitos se han tomado bien
– No se esperan cambios a mitad del proyecto

Si hay que hacer cambios, hay que volver a
empezar desde la fase 1.

Documentación obsoleta prácticamente en cuanto se escribe.
Es una inversión poco óptima de tiempo y esfuerzo.

Procesos y herramientas
Documentación extensiva
Negociación contractual
Seguir un plan
Individuos e interacciones
Software funcionando
Colaboración con el cliente
Adaptación al cambio
http://agilemanifesto.org
Agile Manifesto

• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software
con valor.
• Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles
aprovechan el cambio para proporcionar ventaja competitiva al cliente.
• Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al
periodo de tiempo más corto posible.
• Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante
todo el proyecto.
• 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.
• 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.
• El software funcionando es la medida principal de progreso.
• Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
• La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
• A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia
12 Principios de Agile
http://agilemanifesto.org

Proceso
Iterativo
e incremental
Agile en pocas palabras
Foco
Datos y
cliente
Equipo
Autogestionado
y
multidisciplinar

Requisitos Análisis Diseño Desarrollo Validación Mantenimiento
Comparativa entre metodologías
Iteración 1 Iteración 2 Iteración 3
…
Iteración N
Waterfall
Agile

Waterfall Agile
Entorno Predictivo Cambiante
Proceso Secuencial Iterativo
Investigación y definición Al principio En cada iteración
Planificación Largo plazo Corto plazo
Interacción con el cliente Principio y final En cada iteración
Desarrollo Linear Iterativo
Flexibilidad ante cambios Baja Alta
Tiempo de reacción ante errores Alto Bajo
Entrega Al final Incremental
Responsable Project Manager Equipo
Equipo Por disciplinas Multifuncionales
Documentación Extensa Sólo la imprescindible
Comparativa entre metodologías

Con dibujos 
http://www.projectcartoon.com
Iteración 1 Iteración 2 Entrega final
Entrega final

Con dibujos 
http://effectivesoftwaredesign.com/

Cómo lo están aplicando
+ Prescriptivo + AdaptableDSDM XP SCRUM KANBAN POR LIBRE
VersionOne 10th Annual State of Agile Report

1. Acelerar la entrega de producto
2. Mejorar la gestión de cambios de prioridades
3. Mejorar la productividad
Por qué lo están usando

1. Mejorar la gestión de cambios de prioridades
2. Mejorar la productividad
3. Mejorar la visibilidad del proyecto
Qué están obteniendo

1. Cultura de empresa no alineada con metodologías ágiles
2. Falta de experiencia con metodologías ágiles
3. Falta de soporte por parte de dirección
Por qué no les está funcionado

Transparencia
Definiciones y
resultados
disponibles para
todos
Los pilares de SCRUM
Inspección
Revisión crítica y
frecuente de
procesos y
progreso
Adaptación
Ajustar procesos
y herramientas si
se detectan
desvío

Organización dividida en equipos pequeños, multidisciplinares y
auto-organizados.
Organización

Trabajo dividido en una lista priorizada y estimada de
pequeñas tareas que aporten valor.
Trabajo

Tiempo
Iteraciones cortas con código potencialmente entregable y
demostrable al final de cada iteración.

Prioridades
Prioridades actualizadas después de cada iteración en base a
datos y feedback del cliente

Procesos
Procesos optimizados haciendo una retrospectiva después de
cada iteración, en base a la nueva experiencia adquirida.

Scrum Kanban
Iteraciones Tiempo fijo (1-4 semanas) Sin tiempo fijo
Compromiso Compromiso de entrega por sprint Sin compromiso
Equipo Equipos multidisciplinares Opcional
Planificación Planificación por sprint Sin planificación
Tamaño de tareas Tienen que caber en 1 sprint Sin tamaño definido
Estimaciones Obligatorias Sin estimaciones
WiP Limitado por la capacidad del sprint Limitado por dev
Roles PO, SM, Dev Team Sin roles
Reuniones Planning, Daily, Retro, Demo Sin reuniones
Board Se empieza en cada sprint Siempre el mismo
SCRUM vs. KANBAN

Elementos intocables (aunque ampliables)
Roles
• Product Owner
• Scrum Master
• Development
Team
Ceremonias
• Sprint planning
• Daily Scrum
• Demo
• Retro
Artefactos
• Product backlog
• Sprint backlog
• Incremento

Roles
Product Owner
• Gestionar el
Product Backlog
• Resolver dudas
de negocio
Scrum Master
• Guía espiritual
de Scrum
• Facilitar y ayudar
con
impedimentos
Development
Team
• Gestionar tareas
sprint
• Decidir cómo
implementar la
solución

Product Owners
• Los responsables de maximizar el valor aportado por el
trabajo del Dev. Team.
• Responsables de definir, gestionar y priorizar el backlog.
• Resuelven las dudas de negocio al Dev. Team.
• Definen qué se hace, pero no cómo. Validan la entrega final.
• Son los únicos que pueden decir al Dev Team en qué
trabajar.

Product Owner/Manager vs. Project Manager
POs/PMs centrados en el producto:
• Medio-largo plazo:
– Visión y estrategia del producto
– Inputs: Clientes, mercado, competidores, etc.
• Corto plazo:
– Trabajan codo con codo con el equipo de desarrollo
– Aterrizan esa visión en historias de usuario

Product Owner/Manager vs. Project Manager
Project Managers centrados en el proceso:
• Tiempos
• Presupuesto
• Gestión con clientes/partners

Scrum Master
• Gurú de Scrum. Guía espiritual en esta
metodología.
• Responsable de que se entienda y se cumpla la
metodología.
• Asistente del Dev Team, PO y Stakeholders para
resolver dudas, quitar impedimentos, facilitar
ceremonias, promover mejoras.

Qué NO es el Scrum Master
• No es el jefe del proyecto.
• No es el representante del equipo de desarrollo.
• No es la máxima autoridad técnica en ninguna tecnología.
• No establece prioridades.
• No define cómo implementar la solución.
• No es responsable de la entrega a final de sprint.

Development Team
• Definen e implementan el “cómo” frente al “qué” de
los POs. Sólo trabajan en tareas añadidas por los POs.
• Equipo multidisciplinar y autogestionado.
• Comprometidos a aportar valor al final de cada sprint.
• No hay individuos ni roles, sólo miembros de un
equipo.
• El éxito o fracaso son grupales.

Development Lead
• Otro miembro del equipo de desarrollo.
• Punto de referencia técnico en su disciplina.
• Guía para el resto de desarrolladores a nivel de arquitectura y diseño.
• Primer punto de contacto del PO con el Dev Team.
• NO es el único responsable técnico.
• NO toma las decisiones técnicas en solitario. No se impone, sino que
promueve el trabajo en equipo.
• No tiene por qué ser el más avanzado en todas las tecnologías.

Dev Team & Gremios
• Los equipos mutidisciplinares siguen teniendo
especialistas en distintas tecnologías.
• Los especialistas de cada equipo pueden juntarse en
gremios/comunidades de práctica para compartir
experiencias.

Stakeholders y Clientes
• Expresan necesidades y sugieren nuevas funcionalidades a
los POs.
• NO hablan directamente con el equipo de desarrollo, sólo
con POs.
• Pueden asistir a las Demos.
• Pueden validar el desarrollo de funcionalidades.
• Como clientes, o sus representantes, tienen el foco de
atención del resto de roles (gestionados por los POs).

Ceremonias
Sprint
Planning
Daily
Scrum
Grooming Demo Retro

Antes de empezar con las reuniones…
Puntualidad
Hay que prepararlo
todo antes de
empezar.
Sin cacharros
No se llevan ni
portátiles, ni
móviles.
Papel y boli.
Contexto
Recordad por qué se
tiene la reunión, los
temas a tratar y el
objetivo.
Control del tiempo
Cada tema se trata
en su slot. Si salen
temas nuevos, se
dejan para el final.
Notas
Alguien debe tomar
notas de lo que se
trata en la reunión,
par enviarlo al
finalizar.
Responsables
Para cada acción
pendiente, se
acuerda un
responsable y una
fecha de entrega.

Sprint Planning
¿Quién?
• Dev Team
• Product Owner
• Scrum Master
¿Cuándo?
• Inicio de sprint
• 4h máximo
(sprint 2 sem.)
¿Qué?
• Dev. Team analiza,
divide en tareas y
estima las historias
de la cima del
backlog.
• Se cierra el
compromiso sobre
qué se entregará al
final del sprint.

Informe de inicio de Sprint
• Título del sprint:
– Número de Sprint. Ej. Sprint 1.
– Semanas cubiertas por el sprint. Ej. Sprint 15-16.
– Otros nombres: Ej. Planetas de Star Wars, Personajes de los Simpson, etc.
• Objetivo del sprint: Acordado durante el sprint planning.
• Capacidad del sprint: Suma de la capacidad de cada Dev.
• Sprint backlog: Listado de las historias/tareas a realizar durante el
sprint.
– Total planificado: Total de puntos de historia planificados .
– Capacidad del sprint: Total de puntos de historia disponibles durante el
sprint.
– Buffer disponible: Puntos no planificados de la capacidad.

Daily Scrum
¿Quién?
• Dev Team
• POs y SM
(opcionales)
¿Cuándo?
• Diariamente
• Mismo sitio,
misma hora.
• Máximo 15min.
¿Qué?
• Ayer
• Hoy
• Impedimentos
• (Todos en pie)

Grooming / Refinamiento
¿Quién?
• Product Owner
• Algunos Devs
(como Leads).
¿Cuándo?
• 2-3 días antes de
la planning
• 1 hora máximo
(sprint 2 sem.)
¿Qué?
• Revisar las
historias para el
siguiente sprint
• Preguntar dudas
• Dejar el backlog
listo para
planning

Demo
¿Quién?
• PO
• SM
• Dev Team
• Stakeholders
¿Cuándo?
• Al final del sprint
• 1,5 hora máximo
(sprint de 2 sem.)
¿Qué?
• Revisar las historias
100% hechas (según
DoD)
• Punto de partida
para el siguiente
sprint.

Informe de cierre de Sprint
• Tareas planificadas y terminadas: Tareas inicialmente planificadas
para el sprint que se consideran Done (según la DoD).
• Tareas planificadas y no terminadas: Tareas inicialmente
planificadas para el sprint que no se consideran Done.
• Tareas no planificadas y terminadas: Tareas que no se incluyeron en
la planificación inicial pero que se han terminado en el sprint.
• Resumen: Resumen de la capacidad, los puntos de historia
planificados, los terminados y los no planificados.

Retrospectiva
¿Quién?
• PO
• SM
• Dev Team
¿Cuándo?
• Al final del sprint
• 2 hora máx.
(sprint 2 sem.)
¿Qué?
• Analizar cómo ha
ido el sprint
• Proponer mejoras y
potenciar lo que
funciona
• Revisar
compromisos de la
retro anterior

Herramientas
Product Backlog
Épicas, Historias, Tareas
Historias de usuario
Bugs
Versiones
Estimaciones
Nivel de cariño
Definition of Done (DoD)
Sprint Backlog
Sprint Dashboard

Product Backlog
• Sólo lo actualiza el Product Owner.
– Aunque las estimaciones únicamente las proporciona el Dev Team.
• Contiene todo en lo que se va a trabajar en futuros sprints.
• Sólo hay 1 backlog por producto, aunque haya varios equipos.
• Es un listado priorizado, con un nivel de detalle decreciente.
• Visibile para stakeholders y el resto de la organización.

Product Backlog
- Detalle
- Prioridad
+ Detalle
+ Prioridad
Siguiente sprint
Siguiente par de sprints
Futuro

Épicas, Historias, Subtareas, Tareas y Bugs
Épica
Historia
Usuario 1
HU 2 Historia
Usuario N
Subtarea 1 ST 2 ST N
Tarea…
…
Bug

Historias de usuario
• Título: Título descriptivo-
• Descripción: Siguiendo el formato Como… Quiero…Para…
– El Como… es desde el punto de vista del usuario final, no del reporter.
• Due date (opcional): Para cuándo tiene que estar listo (si aplica).
• Criterios de aceptación: Aquello que se va a comprobar para decidir si está
lista para subir.
• Nivel de cariño: Indica qué nivel de detalle hay que incluir dependiendo de si
es algo que se va a quedar, si es un test o un parche temporal.
• Épica: Grupo de funcionalidades a la que pertenece la historia.
• Reporter: Quién lo ha solicitado, por si hay dudas en el futuro.
• Estimación inicial: Estimación de alto nivel del Dev Team.

Bug template
• Título: Título descriptivo
• Descripción: Descripción del error
• Pasos para reproducir el error:
– 1)
– 2)
– 3)
• Comportamiento actual: Qué pasa cuando se siguen los pasos anteriores
• Comportamiento esperado: Qué debería pasar al seguir los pasos anteriores
• Versión: En qué versión del product pasa el error
• Plataforma: En qué plataforma pasa el error
• Información adicional: Más información que no se haya cubierto en los campos anteriores

Versiones
Épica
Historia
Usuario 1
HU 2 Historia
Usuario N
Subtarea
1
ST
2
ST
N
Tarea
…
…
Bug
Épica
Historia
Usuario 1
HU 2 Historia
Usuario N
Subtarea
1
ST
2
ST
N
Tarea
…
…
Bug
Épica
Historia
Usuario 1
HU 2 Historia
Usuario N
Subtarea
1
ST
2
ST
N
Tarea
…
…
Bug

Estimaciones
• Aproximación del esfuerzo necesario para realizar cada
tarea.
• NO se usan ni días ni horas, sino puntos de historia.
Sólo son válidas cifras de la secuencia de Fibonacci
– 0,1,1,2,3,5,8,13,21,34…
• Se toma como punto de partida una tarea muy sencilla.
Ejemplo: Añadir una imagen
• Hay que ser realistas, pero es mejor no quedarse corto.

Planning Poker
• Técnica de estimación consensuada durante la
sesión de planning.
• Después de analizar una historia de usuario, todos
los desarrolladores seleccionan una de las cartas
de estimación.
• Si hay consenso, se anota la estimación. Si no, se
ponen en común los distintos puntos de vista
hasta llegar a un acuerdo.

Puntos vs. Valor
• Puntos Estimados: Estimación inicial del
esfuerzo para realizar la tarea.
• Esfuerzo real: Una vez terminada la tarea, el
esfuerzo real invertido en realizarla.
• Valor: Valor aportado al cliente cuando la tarea
está en producción.

Análisis de estimaciones
• Junto al listado de tareas planificadas y sus
estimaciones iniciales.
• Cuando una tarea se pasa a Done, se añade el
esfuerzo real invertido.
• Para identificar desviaciones y aprender de cara
a futuras estimaciones.

Nivel de cariño
Nivel de
cariño
Calidad
de
código
Explicación Ejemplo (Amazon)
Rollete de
una noche
Baja
Bajo riesgo, tráfico medio, conocimiento sin
validar, con posibilidades de que cambie
Experimento en una landing
informativa
Rollo de
verano
Media
Riesgo medio-alto, tráfico bajo,
conocimiento sin validar, con posibilidades
de que cambie
Experimento en el funnel de
compra
Novieta Alta
Riesgo bajo, tráfico bajo-medio,
conocimiento validado, poco probable que
cambie
Cambios en el perfil del usuario
Novia
formal
Muy
alta
Crítico, tráfico medio-alto, alto impacto en
usuarios, validado, poco probable que
cambie
Integración de una nueva
plataforma de pago
Boda Extrema
Crítico para el funcionamiento del producto,
validado y poco probable que cambie
Tramitación de compra y envío

Definition of Done (DoD)
• Definición de qué significa que algo está 100% hecho.
• Una historia no está terminada si no se satisfacen
todas las condiciones de la DoD.
• Lo definen Dev Team + PO.

Sprint Backlog
• Items del Product Backlog que se harán en el sprint.
• Se cierra al final del sprint planning.
• Todas las historias están estimadas y divididas en tareas más
pequeñas (también estimadas).
• Sólo se pueden añadir tareas “haciendo hueco” (quitando otras).
• El Dev Team se compromete a terminar todo lo que deciden que
entra.

Sprint Dashboard
• Refleja el estado de todas las historias/tareas/bugs del sprint.
• Permite ver si hay algún “problema” en función de la distribución de
las tareas.
• Idealmente, se trabaja con versión online y física.
– El online se actualiza al momento, en cuanto hay cambios en la tarea.
– El físico se puede actualizar durante el Daily Scrum.
• Los encargados de mantenerlo son el Dev Team.
• Se pueden usar post-it de varios colores para identificar distintos tipos
de ítems (Historias, Tareas, Bugs, Tickets, etc.)
• Se puede usar una sección para imprevistos con | Fuegos | Must |
ASAP|

Sprint Dashboard
ToDo InProgress Buffer
Peer
Review
Testing
Pre
To
upload
Testing
Prod
Done Blocked
Fuego
Must
ASAP
SPRINT BOARD
FIREFIGHTER BOARD

Cómo se puede aplicar
Shu
Sigue las normas
para aprender la
base
Ri
Encuentra tu propio
camino aprendiendo
de tus experiencias
Ha
Rompe con la
tradición, sé creativo e
investiga por tu cuenta

Pabgarm (at) Gmail (dot) com
@pabgarm
https://es.linkedin.com/in/pabgarm
¡Gracias!
Para dudas, comentarios, preguntas y/o feedback:

Referencias
Guía oficial de Scrum
• Ken Schwaber & Jeff Sutherland. Creadores de Scrum
• Link: http://www.scrumguides.org/
The Scrum Master Training Manual
• Nader K. Rad, Frank Turley. Management Plaza
• Link: http://mplaza.pm/product/scrum-master-training-manual/
Otros
• https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf
• http://agilemanifesto.org/
• http://www.scrumguides.org/
• Kanban and Scrum - Making the Most of Both by Henrik Kniberg and Mattias Skarin
• The Scrum Master training manual, By Nader K. Rad, Frank Turley
• https://en.wikipedia.org/wiki/Shuhari

Un poco más de Agile y Scrum à la Pablo

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Un poco más de Agile y Scrum à la Pablo

Similar a Un poco más de Agile y Scrum à la Pablo (20)

Último

Último (6)

Un poco más de Agile y Scrum à la Pablo

Notas del editor