La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
6. 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
7. Si hay que hacer cambios, hay que volver a
empezar desde la fase 1.
10. 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
11. • 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
12. • 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
14. 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
15. 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
22. Cómo lo están aplicando
+ Prescriptivo + AdaptableDSDM XP SCRUM KANBAN POR LIBRE
VersionOne 10th Annual State of Agile Report
23. 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
24. 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
25. 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
33. 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
36. 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
37. 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.
38.
39.
40.
41. 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
42. Product Owner/Manager vs. Project Manager
Project Managers centrados en el proceso:
• Tiempos
• Presupuesto
• Gestión con clientes/partners
43. 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.
44. 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.
45. 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.
46. 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.
47. 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.
48. 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).
50. 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.
51. 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.
52. 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.
54. 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)
56. 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
57. 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.
58. 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.
60. 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
63. 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.
64. Product Backlog
- Detalle
- Prioridad
+ Detalle
+ Prioridad
Siguiente sprint
Siguiente par de sprints
Futuro
65. Épicas, Historias, Subtareas, Tareas y Bugs
Épica
Historia
Usuario 1
HU 2 Historia
Usuario N
Subtarea 1 ST 2 ST N
Tarea…
…
Bug
66. 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.
67. 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
68. 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
69. 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.
70. 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.
71. 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.
74. 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.
76. 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
77. 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.
78. 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.
79. 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|
80. Sprint Dashboard
ToDo InProgress Buffer
Peer
Review
Testing
Pre
To
upload
Testing
Prod
Done Blocked
Fuego
Must
ASAP
SPRINT BOARD
FIREFIGHTER BOARD
81. 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
82.
83. Pabgarm (at) Gmail (dot) com
@pabgarm
https://es.linkedin.com/in/pabgarm
¡Gracias!
Para dudas, comentarios, preguntas y/o feedback:
84. 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
Notas del editor
Todas las fases quedan documentadas
The starting point was the need for an alternative to documentation driven, heavyweight software development processes convened.
Agile Manifesto
Individuos
La resolución de problemas surge de interacción entre personas
Software
El foco tiene que ser entregar valor. La documentación, cuando sea necesaria, tiene que priorizarse con respecto a las tareas que aportan valor al cliente.
Cliente
Los proyectos deberían ser un trabajo de equipo entre cliente y equipo, más que 2 equipos aislados
Adaptación al cambio
Los planes quedan obsoletos prácticamente en cuanto se escriben
Hay que entender que habrá cambios, asumirlo en vez de prevenirlo o bloquearlo, para entregar lo que el cliente necesita.
Agile Manifesto
Individuos
La resolución de problemas surge de interacción entre personas
Software
El foco tiene que ser entregar valor. La documentación, cuando sea necesaria, tiene que priorizarse con respecto a las tareas que aportan valor al cliente.
Cliente
Los proyectos deberían ser un trabajo de equipo entre cliente y equipo, más que 2 equipos aislados
Adaptación al cambio
Los planes quedan obsoletos prácticamente en cuanto se escriben
Hay que entender que habrá cambios, asumirlo en vez de prevenirlo o bloquearlo, para entregar lo que el cliente necesita.
Scrum es un marco de trabajo para el desarrollo y el mantenimiento de productos complejos.
Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.
Las iteraciones se basan en datos y se centran en el cliente.
Scrum se basa en que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce.
El objetivo es entregar productos del máximo valor posible.
Se prepara previamente, no se improvisa con los stakeholders delante. Si no sale bien, se mina la credibilidad del Dev team.
Al cierre del sprint, se envía el listado de historias para la Demo a los stakeholers, para que sepan qué se va a revisar.
Se resumen los highlights del sprint en 2 categorías:
Qué ha ido bien
Qué se puede mejorar
Se acuerdan compromisos de mejora para el siguiente sprint (con personas asignadas!).
Idealmente, se empiezan y terminan en el mismo sprint.