Presentación de Scrum
Descargar como PPTX, PDF4 recomendaciones6,266 vistas
El documento presenta una introducción a la gestión de proyectos ágiles y específicamente a la metodología Scrum, destacando su adaptación a contextos cambiantes y sus beneficios frente a metodologías tradicionales. Describe la historia de Scrum, sus componentes, roles, y el proceso, incluyendo reuniones clave y artefactos relevantes. También se enfatizan los valores y pilares del modelo Scrum, así como su importancia en la optimización del desarrollo de software.
Presentación de Scrum
- 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.
- 5. Metodologías Ágiles Scrum Extreme Programming (XP) Adaptive Software Development (ASD) Dynamic System Development Method (DSDM) Test development driven (TDD) Crystal Feature Driven Development (FDD) Lean
- 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.
- 13. Framework
- 14. Roles de Scrum
- 15. Roles de Scrum
- 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
- 19. El proceso Scrum
- 20. El proceso Scrum Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectives
- 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
- 24. Agile Project Management - Scrum 24
- 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
- 28. Agile Project Management - Scrum 28
- 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
- 30. Agile Project Management - Scrum 30
- 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”.
- 41. Scrum de Scrums
- 42. DevOps
- 43. Consultas
- 44. FIN • Gracias a todos
Notas del editor
- #4: 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.
- #7: Autores: Jeff Sutherland y Ken Schwaber Successful = increase in productivity, satisfied/ happy team OOPSLA = (Object-Oriented Programming, Systems, Languages & Applications)
- #8: Determina Prácticas Emergentes. Especialmente, usado para proyectos de innovación.
- #14: 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)
- #15: Ponemos foco en 3: Product Owner y su relación con los Stakeholders. Delivery team. (Development team) Scrum Master.
- #18: 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
- #24: 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.
- #26: 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
- #27: 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
- #28: 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.
- #30: 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.
- #34: 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
- #35: 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.
- #36: 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.
- #38: 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.
- #40: Indicadores de progreso y estrategia. Realizan una proyección del trabajo restante del Product Backlog (PB)
- #41: 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”
- #43: Scrum y Agilidad. Base de la Continuous Delivery Pipeline. (Canalización de entrega continua) Base de DEVOPS.