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)

ProgramManager

Microsoft

(2011-2014)

ProductManager /

Product Owner

Softonic

(2015-2015)

ProductManager /

Agile Coach

Packlink

(2015-2015)

ProductManager /

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?

De dónde venimos

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.

AgileUtah. Febrero de 2001

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

• 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/

Lean Startup

Lean Startup

Agile en el Mundo Real

Quién está usando Agile

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

VersionOne 10th Annual State of Agile Report

1. Mejorar la gestión de cambios de prioridades

2. Mejorar la productividad

3. Mejorar la visibilidad del proyecto

Qué están obteniendo

VersionOne 10th Annual State of Agile Report

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

VersionOne 10th Annual State of Agile Report

SCRUM

TransparenciaDefiniciones y

resultados disponibles para

todos

Los pilares de SCRUM

InspecciónRevisión crítica y

frecuente de procesos y progreso

AdaptaciónAjustar 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

Los intocables

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

DevelopmentTeam

• 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

DailyScrum

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 historiasde la cima del backlog.

• Se cierra el compromiso sobrequé 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.

Informe de inicio de Sprint

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)

Burn-up / Burn-down

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 historias100% hechas (segúnDoD)

• Punto de partidapara el siguientesprint.

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.

Informe de cierre de Sprint

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

• Revisarcompromisos de la retro anterior

Informe de Action Items

Herramientas

Product BacklogÉpicas, Historias, TareasHistorias de usuarioBugsVersionesEstimacionesNivel de cariñoDefinition of Done (DoD)Sprint BacklogSprint 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

HistoriaUsuario 1

HU 2 HistoriaUsuario 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

HistoriaUsuario 1

HU 2 HistoriaUsuario N

Subtarea1

ST 2

ST N

Tarea…

…

BugÉpica

HistoriaUsuario 1

HU 2 HistoriaUsuario N

Subtarea1

ST 2

ST N

Tarea…

…

Bug

Épica

HistoriaUsuario 1

HU 2 HistoriaUsuario N

Subtarea1

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.

Delivery

Delivery

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.

Análisis de estimaciones

Nivel de cariño

Nivel de cariño

Calidad de

códigoExplicación Ejemplo (Amazon)

Rollete de una noche

BajaBajo riesgo, tráfico medio, conocimiento sin validar, con posibilidades de que cambie

Experimento en una landinginformativa

Rollo de verano

MediaRiesgo medio-alto, tráfico bajo, conocimiento sin validar, con posibilidades de que cambie

Experimento en el funnel de compra

Novieta AltaRiesgo 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 ExtremaCrí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 BufferPeer

ReviewTesting

PreTo

uploadTesting

ProdDone Blocked

Fuego

Must

ASAP

SPRINT BOARD

FIREFIGHTER BOARD

Cómo se puede aplicar

ShuSigue las normas para aprender la

base

RiEncuentra tu propio camino aprendiendo de tus experiencias

HaRompe 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