Una presentación del marco de trabajo de Scrum. Apunta a establecer en breves imágenes los roles, procesos y artefactos necesarios para la agilidad de proyectos de desarrollo de software o tecnologías de información.
2. Agenda
• Introducción
• Gestión de proyectos Agiles
• Metodologías Ágiles
• Historia del Scrum
• Manifiesto Ágil
• Que es Scrum?
• Componentes de Scrum
• Roles
• El proceso
• Artefactos
• Consultas
3. Introducción
• La metodologías tradicionales
posee muchas desventajas:
• Planificación inicial
• Muchos supuestos
• Grandes riesgos
• Cambios difíciles de
implementar
• Metodologías Ágiles son
adaptativas a los contextos.
6. Historia del Scrum
• 1995:
• Metodología tradicional para el desarrollo de software
• Metodología no adecuada para procesos empíricos, de comportamientos
impredecibles y no repetibles.
• Diseño de un nuevo método: Scrum por Jeff Sutherland y Ken Schwaber
• Mejora de Scrum por Mike Beedle y se combina el Scrum con Extreme
Programming
• 1996:
• Presentación de Scrum en la conferencia OOPSLA
• 2001:
• Publicación del libro “Agile Software Development with Scrum” por
Ken Schwaber & Mike Beedle
• 2010:
• Aplicación exitosa de Scrum en más de 50 compañías.
• Los fundadores son miembros de la Alianza Ágil
• Scrum Alliance (https://www.scrumalliance.org/)
• Una organización sin fines de lucro promueve el desarrollo ágil.
7. Agile Project Management - Scrum
Que es Scrum?
El Scrum es una jugada que reinicia el
juego después de una interrupción,
donde los delanteros de cada lado se
unen en una formación cerrada y luchan
por tomar posesión de la pelota cuando
se la arroja entre ellos.
7
8. Scrum – un proceso ágil
• SCRUM es un proceso ágil y liviano para administrar y controlar el desarrollo de
software y productos en entornos complejos y altamente cambiantes.
• Iterativo, proceso incremental.
• Enfoque basado en equipos
• Desarrollo de sistemas/productos con requisitos rápidamente cambiantes.
• Controla el caos de los intereses y necesidades en conflictos.
• Mejora la comunicación y maximice la cooperación
• Protege al equipo de interrupciones e impedimentos
• Una forma de maximizar la productividad
9. Que nos permite Scrum y la Agilidad
VARIABLE
FIJO
CASCADA AGILE
TIEMPO COSTO
ALCANCE TIEMPO COSTO
ALCANCE
10. Manifiesto
para el
Desarrollo
Agile
• Individuos e interacciones sobre
procesos y herramientas
• Software funcionando sobre
documentación extensa.
• Colaborar con el cliente sobre
las negociaciones contractuales
• Respuesta al cambio sobre
seguir un plan de proyecto.
http://agilemanifesto.org/iso/es/manifesto.html
11. Valores del
equipo Scrum
• Foco sobre un acotado numero de
características.
• Coraje para asumir compromisos
desafiantes.
• Apertura para discutir los
problemas con transparencia.
• Compromiso con el éxito del
proyecto.
• Respeto por el valor de cada
persona.
12. Pilares de
Scrum
Del modelo predictivo al
empírico:
• Transparencia. Expectativas
claras para quienes construyen y
quienes aceptan sobre un acotado
numero de características.
• Inspección frecuente de los
artefactos.
• Adaptación para detectar
oportunidades de mejoras.
16. Agile Project Management - Scrum
Product Owner
• Maximiza el valor del producto.
• Actúa como una sola voz (en cualquier caso).
• Representa al negocio, stakeholders, clientes y
usuarios finales.
• Sabe lo que se debe construir y en qué secuencia
se debe hacer.
• Por lo general, es un gerente de producto.
16
17. Agile Project Management - Scrum
Scrum Master
• Lidera en forma servicial.
• Es un Coach.
• Representa la gestión del Proyecto.
• Por lo general, lo ocupa un Jefe de Proyecto o
Líder de Equipo.
• Sus principals funciones son:
17
18. Agile Project Management - Scrum
Equipo de desarrollo o
Delivery team
• Equipo compuesto entre 5 a 10 personas.
• Co-ubicación del equipo.
• Cross-functional (QA, programadores, diseñadores
UI, etc.)
• Los miembros trabajan a tiempo completo.
• El equipo es auto-organizado
• Los miembros pueden cambiar entre Sprints
18
21. El proceso Scrum
• Iteración
• Duración 1 mes
• Genera incremento de
producto.
• Sin interrupciones para el
equipo.
• Inicia con una Daily Scrum
Meeting.
Sprint
22. El proceso Scrum
• Una forma especial de Sprint
Planning Meeting
• Reunión antes del inicio del
Proyecto.
Pre-Project / Kickoff Meeting
23. El proceso Scrum
• Duración de 15 minutos diarios.
• Scrum Master y Equipo.
• Responder a las 3 preguntas:
• Que hicieron.
• Que harán hoy.
• Que impedimentos hay.
Daily Scrum
25. El proceso Scrum
• Duración 8 horas
• Al Inicio de cada Sprint.
• PO, Scrum Master y el Equipo.
• ¿Qué? Se define Sprint Goal.
• ¿Como? Se define Sprint
Backlog
Sprint Planning Meeting
26. Estimación de PBI
(Product Backlog Items)
Establece la velocidad
del equipo (cuanto
esfuerzo puede
manejar en un Sprint).
01
Determinando unidades
de complejidad.
• Size-category (“T-Shirt size”)
• Puntos de Historias
• Work days/work hours
02
Métodos de estimación:
• Revisión de expertos
• Creando una WBS
03
27. El proceso Scrum
• Al final de cada Sprint
• PO inspecciona el Incremento
de Producto.
• Reunión no distrae el resto del
equipo.
• Se Acepta o Rechaza el
producto.
• Feedback
• Nuevas funcionalidades.
Sprint Review Meeting
29. El proceso Scrum
• A continuación de la última
Sprint Review.
• Base de la mejora continua de
la metodología.
• Prácticas emergentes.
• Análisis de Causa raíz
• El equipo decide las próximas
mejoras.
Scrum Retrospectivas
32. Artefactos de Scrum
• Minimum Viable Product (MVP)
• Product Backlog
• Sprint Backlog
• Burn down Charts
• Lista de impedimentos
• Incremento de producto
• Historias de usuario
33. Artefactos de Scrum
• Generado en la Sprint Planning.
• Requisitos para un sistema.
• Administrado por el Product
Owner.
• Cambia Sprint Planning Meeting.
Product Backlog Lista priorizada
34. Artefactos de Scrum
• Un subconjunto de PBIs.
• Es administrado SOLAMENTE por
miembros del equipo.
• Gestión visual a través de
Kanban.
Sprint Backlog Lista seleccionada para el Sprint
35. Artefactos de Scrum
• Refinamiento del producto.
• El Product Owner organiza.
• Profundiza en el entendimiento
de los PBI.
2 veces por SprintBacklog Grooming
36. Artefactos de Scrum
• Versión mínima de un producto.
• Permite recolectar información
del mercado.
• Pone foco en las características
mínimas.
Minimum Viable Product (MVP) Cada entrega cumple con ser un
“Producto”.
37. Artefactos de Scrum
• Principal objetivo:
Visibilidad del equipo.
• Cada PBI tiene su propio
estado.
• Actualización diaria por
cada miembro.
• No más de 300 PBI visibles.
Sprint Backlog Gestión visual con Kanban
38. Artefactos de Scrum
• Surge del Extreme Programming
(XP)
• Contiene Especificaciones
funcionales.
• El problema identificado es, no
conduce a un resultado.
• La comunicación cubre solo:
• 7% ➔ contenido (las palabras)
• 38% ➔ tono de voz
• 55% ➔ expresiones faciales
• Se recomienda comunicación:
Cara a Cara.
• Debe ser INVEST.
Historias de Usuario Lista de Historias de usuarios
39. Artefactos de Scrum
• Se usan para representar
el "trabajo terminado".
• Proyección del trabajo
restante del PB.
• Se usan 3 tipos:
• Sprint Burn down
Chart (progreso del
Sprint)
• Release Burn down
Chart (progreso del
release)
• Product Burn down
chart (progreso del
producto)
Indicadores de Progreso Estratégico Burn Down Charts
40. Incremento de
producto
• Suma de los PBI completados.
• PBI Terminado ó “Definition of
Done” es definido en la User
History Mapping.
• Cada PBI, debe estar
”terminado”.
La metodologías tradicionales de desarrollo de software con muchas desventajas:
- Esfuerzo en planificación inicial
- Cambio de requisitos difícil de abordar.
Metodologías Ágiles, se mueven en contextos Complicados y Complejos.
Dominios identificados para la toma de decisiones
Simple: Desarrollo de autos (mejores prácticas)
Complicado: Ejemplo Performance de BD. (buenas prácticas)
Complejo: Surgen Prácticas emergentes
Caótico: Solo existe la Improvisación
Desorden: No sabemos donde estamos.
Autores: Jeff Sutherland y Ken Schwaber
Successful = increase in productivity, satisfied/ happy team
OOPSLA = (Object-Oriented Programming, Systems, Languages & Applications)
Determina Prácticas Emergentes.
Especialmente, usado para proyectos de innovación.
Scrum Framework en un vistazo (at a glance)
Scrum y Agilidad.
Base de la Continuous Delivery Pipeline. (Canal de entrega continua).
Base de DEVOPS (por eso se integra)
Ponemos foco en 3:
Product Owner y su relación con los Stakeholders.
Delivery team. (Development team)
Scrum Master.
Responsabilidades:
Responsable de promover los valores y practicas.
Función es eliminar impedimentos.
Asegurar el entendimiento y seguimiento del scrum.
Mantener la cooperación y la comunicación en el equipo.
Apoya el rendimiento del equipo.
Mantener al equipo sin distracciones
Correcto empleo y evolución de Scrum
Facilitar el uso de Scrum
Mantener sin distracciones al equipo
Enseña al PO.
Gestionar el producto backlog
Maximizar el valor con la priorización del backlog
Ayuda al PO a Entender la agilidad
Enseña al Equipo Desarrollo
Crear producto de alto valor
Enseñar a Remover los impedimentos a los miembros de equipo.
Ayudar a enfocarse
Duración de 15 minutos diarios.
Scrum Master y Equipo.
Todos los miembros deben responder a las 3 preguntas.
1. Que hicieron el día anterior.
2. Que harán hoy.
3. Que impedimento hay.
No se resuelven problemas.
Se realizan los compromisos del equipo.
Duración 8 horas
Al Inicio de cada Sprint.
Asiste el Product Owner, el Scrum Master y el Equipo de desarrollo.
Se pregunta: “¿qué? Y ¿cómo?.
Dividido en 2 partes (“antes de almuerzo y despues de almuerzo”)
1st Part:
Participants: Product Owner, Scrum Master, Scrum Team
Creating Product Backlog
Determining the Sprint Goal.
2nd Part:
Participants: Scrum Master, Scrum Team
Creating Sprint Backlog
Como calculamos un Item en el PB.
Según Kanban, corresponde al WIP (work in progress) del equipo .. Suma de todos los esfuerzos posibles de un equipo.
Se establecen categorías de complejidad por Item o Historias de Usuario (llamados Puntos de Historia).
Se puede generar una
Se realiza al final de cada Sprint.
Product Owner inspecciona el software (Incremento de Producto potencialmente entregable).
Reunión no distrae el resto del equipo.
Aceptan o rechazan el producto.
Se realiza Feedback. (cambios o nuevas funcionalidades)
Nuevas funcionalidades, para el siguiente Sprint.
A continuación de la última Sprint Review.
Base de la mejora continua de la metodología.
Implementa prácticas emergentes (soluciones rápidas).
Base para mejora continua.
Herramienta Análisis Causa raíz
El equipo decide las mejoras para el siguiente Sprint.
Requisitos para un sistema,
expresado como una lista priorizada de elementos acumulados
Es administrado y es propiedad de un Product Owner
Hoja de cálculo (típicamente)
Por lo general, se crea durante la reunión de planificación de Sprint
Se puede cambiar y volver a priorizar antes de cada PM
Un subconjunto de PBI (Product Backlog Item), que forman el trabajo a realizar en un Sprint.
Es creado SOLAMENTE por miembros del equipo desarrollo.
Es un buen monitor de alertas.
Algunas reglas:
Cada artículo tiene su propio estado. Usamos Kanban.
Actualización diaria.
No más de 300 tareas en la lista.
Si una tarea requiere más de 16 horas, debe descomponerse.
El equipo puede agregar o quitar elementos de la lista. El propietario del producto no puede hacerlo.
Actividad constante durante los Sprint, según la necesidad del equipo.
Cuando y Como.
El PO puede dividir PBI en pequeños PBI.
Permite la detección de riesgos en cada uno de los PBI.
Se revisan y ajustan las prioridades de PBI en el Backlog.
Como gestionamos el Sprint Backlog???
Un subconjunto de PBI (Product Backlog Item), que forman el trabajo a realizar en un Sprint.
Es creado SOLAMENTE por miembros del equipo desarrollo. Es un buen monitor de alertas.
Algunas reglas:
Si una tarea requiere más de 16 horas, debe descomponerse.
El equipo puede agregar o quitar elementos de la lista. El propietario del producto no puede hacerlo.
Indicadores de progreso y estrategia.
Realizan una proyección del trabajo restante del Product Backlog (PB)
Aquí es importante como se genera una Historía de usuario como Item del PB.
Como se escribe una Historia de usuario.
Como se estima una Historia de usuario
Como se define que una Historia de usuario, esté totalmente terminada. “Ejemplo, Que se hayan realizado la subida a GitHub o SVN. Compilado OK”
Scrum y Agilidad.
Base de la Continuous Delivery Pipeline. (Canalización de entrega continua)
Base de DEVOPS.