Introducción a scrum - Rodrigo Corral (Plain Concepts)
Descargar como PPTX, PDF1 recomendación633 vistas
Este documento presenta una introducción a Scrum, un marco ágil para el desarrollo de software. Scrum se basa en iteraciones cortas llamadas sprints durante las cuales los equipos trabajan para completar elementos de una lista de producto priorizada. Los roles clave son el product owner, quien es responsable de la lista de producto, el equipo de desarrollo auto-organizado, y el scrum master, quien ayuda al equipo a seguir las reglas de Scrum. Al final de cada sprint, el equipo demuestra el incremento de funcionalidad completado y busca formas
Introducción a scrum - Rodrigo Corral (Plain Concepts)
- 1. Introducción a Scrum Rodrigo Corral rcorral@plainconcepts.com http://geeks.ms/blogs/rcorral Twitter: r_corral MVP Team System / CSM / CSP / PSDT Plain Concepts
- 2. El manifiesto ágil Individuos e iteraciones sobre Procesos y Herramientas Sofware que funciona sobre documentación exhaustiva Colaboración con el cliente sobre negociación de contratos Responder al cambio sobre seguir un plan Aunque hay valor en los elementos de la derecha , valoramos más los elementos de la izquierda. “La agilidad es un marco común las metodologías implementaciones”
- 3. Principios ágiles Satisfacer al cliente. Los cambios son bienvenidos. Las entregas son frecuentes. Trabajamos en equipo. Motivamos a la gente. Nos gusta la comunicación cara a cara. Medida de progreso: Software que funciona. Mantenemos un ritmo sostenido y sostenible. La calidad no es opcional. Primamos la simplicidad. Evolucionamos nuestros diseños. Reflexionamos con regularidad.
- 4. ¿Por qué queremos ser ágiles? La aproximación ágil al desarrollo de software a demostrado ser mejor para lograr: Reaccionar frente a cambios (en los requisitos, en el mercado, en las prioridades, en la arquitectura…) Priorizar el desarrollo para logra maximzar el retorno de la inversión Controlar en tiempo real el progreso del desarrollo, la calidad y los impedimientos. Involucrar y motivar a los desarrolladores.
- 5. ¿Quién usa Scrum? Fuente: TFS Adoption within EMEA – A Process Perspective http://processmentor.com/Community/blogs/carl_rogers/archive/2008/02/29/481.aspx
- 6. ¿Quién usa Scrum? Fuente: Scrum Alliance – Firms using Scrum http://scrumcommunity.pbworks.com/Firms+Using+Scrum
- 7. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective • Scrum permite que equipos de desarrolladores sean productivos en entornos con incertidumbre y cambios. • Es un marco simple y poderoso, con reglas claras, que permite a los equipos y sus clientes adaptar y controlar el desarrollo de los proyectos. • Proporciona una alto grado de claridad, visibilidad y transparencia. • Scrum hace visibles rápidamente los problemas y permite y exige mejorar continuamente los resultados. Scrum Master Sprint Sin cambios (ni en duración, ni en alcance)
- 8. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • El Product Owner decide que se debe producir para lograr el éxito del proyecto y asegura el ROI. • El Product Owner recoge la información proporcionada por usuarios finales, gestores, ‘stakeholders’, ejecutivos, expertos etc… y elabora una visión unificada. • Esta visión unificada se recoge en una lista priorizada atendiendo al ROI y riesgo. • Esta lista se llama Product Backlog.
- 9. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • El Product Backlog el la lista única y maestra de requisitos. • Recoge requisitos funcionales y no funcionales priorizados según el valor para el negocio y el riesgo según el criterio del Product Owner. • El orden dentro de la lista deja clara la prioridad. • El Product Backlog es revisado constantemente y refinado constantemente por el Product Owner y se añaden, eliminan o modifican los elementos para maximizar el valor para el negocio de esfuerzo del equipo.
- 10. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • Descripción de una funcionalidad atómica desde el punto de vista del negocio. • La descripción debe ser ‘suficiente buena’ para permitir a los desarrolladores primero estimarla y después dividirla en tareas y desarrollarla. • Debe incluir criterios de aceptación. Product Backlog Item / Historia de usuario
- 11. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • El tamaño ideal es de unos 7 miembros. • El equipo es multidisciplinar y tiene todos las capacidades necesarias para desarrollar el proyecto. Todo el mundo contribuye según su capaciada, no según su puesto. • El equipo es autoorganizado y auto gestionado. • El equipo es responsible de realizar compromisos basados en estimaciones realista y alcanzar sus propios objetivos.
- 12. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • El Scrum Master trabaja al servicio del equipo (elimina impedimentos), protege al equipo (de ruido, interrupciones, o interferencias) y les guía y enseña a usar Scrum. • El Scrum Master es un facilitador (una jardinero, un apicultor…) • Es el responsable de que todas las liturgias de Scrum ocurran.
- 13. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • El equipo trabaja en periodos fijos de tiempo llamados Sprints. • Los Sprints duran entre 1 y 4 semanas. Nunca más. • Los Sprints se suceden de manera continua. • Nada ocurre fuera de un Sprint (salvo Spikes puntuales).
- 14. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • El Product Owner propone el trabajo a realizar en cada sprint. • El Product Owner describe verbalmente el trabajo que el equipo ha de realizar en el próximo sprint. • El equipo divide el trabajo a realizar el próximo sprint en tareas. • El equipo compromete el trabajo que estima que es posible realizar. • Todo el equipo forma parte de este proceso. • Problema: todos los equipos comprometen más de lo que son capaces de hacer en los primeros sprints.
- 15. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • Durante el Sprint no cambia el alcance del trabajo comprometido por el equipo, ni la duración del spring (máximo 30 días) • Esto permite al equipo mantener sus compromisos y permite que trabaje enfocado. • Duarnte el sprint el PO trabaja para preparar el siguiente Sprint. • Si ocurre una circustancia anomala el Scrum Master puede cancelar el sprint. Esto es un mecanismo de protección.
- 16. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • En compensación por no hacer cambios durante el Sprint el Produc Owner puede hacer los cambios que considere necesarios antes de comenzar el siguiente Sprint. • El Product Owner puede añadir, quitar, o reordenar elementos del Producto Backlog.
- 17. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • Cada día el equipo mantiene una reunión corta de seguimiento (15 min. max.) • Típicamente de pié cada miembro contesta tres preguntas: • ¿Qué hiciste ayer? • ¿Qué vas ha hacer hoy? • ¿Qué te impide avanzar? • Es labor del Scrum Master actuar sobre los impedimentos detectados.
- 18. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • El afán del equipo es completar el 100% del trabajo comprometido. • Completado significa completado: funcionalidad totalmente diseñada, implementada y probada, sin defectos aparentes. • Deplegar los incrementos de funcionalidad potencialmente entregables es opcional, pero siempre debería ser posible.
- 19. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • Al final del Sprint el Product Owner, el equipo , el Scrum Master y todos los stakeholders que lo deseen se reúnen para ver una demostración de lo que el equipo a producido. • El Product Owner recoge el ‘feedback’ de todo el mundo con el fin de mejorar los resultados del proyecto. • El ‘feedback’ se incorpora al Producto Backlog y el Product Owner es quien lo prioriza.
- 20. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) • El equipo, el Product Owner, y el ScrumMaster se reunen al final de cada Sprint y revisan cómo trabajan buscando maneras de mejorar su efectividad. • Este es el mecanísmo de mejora continua y la manera de detectar problemas que deben ser corregidos y comunicados a gestores o clientes.
- 21. Scrum 2. 3. 4. 5. 1. 7. 8. 9. 10. 6. Product Backlog TeamProduct Owner Sprint Planning Meeting Daily Scrum Meeting Sprint Review Incremento de funcionalidad Sprint Retrospective Scrum Master Sprint Sin cambios (ni en duración, ni en alcance) Tiempo Recursos Alcance Calidad
- 22. Flujo acumulado de proyecto ¿Cuándo terminaremos? ¿Cuánto han cambiado los requisitos?
- 23. Sprint burndown chart ¿Cuánto retraso tenemos acumulado?
- 24. ¿Qué ha cambiado? • Visibilidad total de como ‘funciona la fabrica’. • Implicar a todos en: – La cultura de excelencia y calidad. – La gestión de los proyectos. – La inquietud por la mejora continua. – El servicio al cliente. • Gestión basada en métricas claras y simples. • Todos el mundo tiene un modelo claro de como se desarrolla software. • Todo el mundo trabaja contra objetivos claros, realistas y a corto plazo.
- 26. Q&A, Recursos Calendario e información http://bit.ly/xc3rPE May 7-8 Professional Scrum Foundations May 9-11 Professional Scrum Developer (.NET) jlsoria@plainconcepts.com http://geeks.ms/blogs/jlsoria @jlsoriat
- 27. ¡GRACIAS!