4. ¿Qué es Scrum?
“Un marco de trabajo por el cual las personas pueden acometer problemas
complejos adaptativos, a la vez que entregar productos del máximo valor
posible productiva y creativamente. Scrum es:
• Ligero
• Fácil de entender
• Extremadamente difícil de llegar a dominar”
Ken Shwaber y Jeff Sutherland.
5. ¿Qué es Scrum?
“Un marco de trabajo basado en un conjunto de valores, principios y prácticas
que suministran los fundamentos para que cada organización le agregue su
implementación única.”
Kenneth Rubin, Essential Scrum
6. ¿Qué es Scrum?
• Método ágil más popular. Puede ser aplicable a diferente tipos de actividades,
no solo a desarrollo de software.
• Centrado en las personas y basado en los valores de honestidad, apertura,
esfuerzo, respeto, enfoque, confianza, empoderamiento y colaboración.
• Equipos enfocados al resultado, que trabaja de forma auto dirigida.
• Adaptación continua a las circunstancias de la evolución del proyecto.
• Puede complementarse y convivir con otras metodologías (agiles y no agiles).
7. Casos de éxito
• Yahoo
• Microsoft
• Google
• Lockheed Martin
• Motorola
• SAP
• Cisco
• GE
• CapitalOne
• DoD (USA)
• Reserva Federal de Estados Unidos
9. Beneficios
• Se pueden gestionar las expectativas del cliente de manera regular (requisitos
desarrollados, velocidad de desarrollo, calidad).
• Se pueden tomar decisiones en cada iteración.
• El cliente puede obtener resultados importantes y utilizables desde las
primeras iteraciones.
• El cliente puede iniciar el proyecto con requerimientos de alto nivel. Sólo
debe tener detallado requerimientos de las primeras iteraciones.
10. Beneficios
• Se pueden administrar de manera natural los cambios que aparecen durante
el proyecto.
• Al finalizar la iteración el equipo puede decidir cómo mejorar su proceso de
trabajo basado en las experiencia obtenida.
• Permite mitigar desde el inicio los riesgos del proyecto.
• Se minimiza el número de errores que se producen en el desarrollo y se
aumenta la calidad. Lo anterior debido a que en cada iteración se entregan
requerimientos terminados.
12. Restricciones
• El cliente debe estar disponible durante todo el proyecto debido a su
participación continua.
• La relación con el cliente se debe basar en los principios de colaboración más
que tratarse de una relación contractual.
• Cada iteración debe dar como resultado requisitos implementados (criterio
de done).
• Timebox.
18. Actividades
• Sprint
• Planeación del Sprint
• Daily
• Ejecución del Sprint
• Revisión del Sprint
• Retrospectiva del Sprint
• Refinamiento del Product Backlog
19. Sprint
• Cada Sprint crea algo de valor tangible para el usuario o el cliente.
• Iteraciones regulares entre 1 y 4 semanas.
• Durante el Sprint no se permiten cambios en el Sprint Backlog o en la
conformación del equipo.
• Se realiza una planeación al inicio de cada Sprint y una retrospectiva al final.
20. Planeación del Sprint
• El Product Owner define el objetivo del Sprint.
• Tomando los elementos de más alta prioridad del Product Backlog, el equipo
de desarrollo determina los elementos que se compromete a implementar
para el Sprint.
• Los elementos del Product Backlog seleccionados en tareas para crear el
Sprint Backlog.
• La planeación dura 8 horas para un Sprint de un mes.
21. Daily Sprint
• Punto de inspección y adaptación en Scrum.
• Máximo 15 minutos.
• El equipo se reúne para comunicar y entender el status.
• Esencial para conocer el progreso continuo y evitar bloqueos.
• No tiene como objetivo reportar progreso al Scrum Master, Product Owner o
cualquier otro Stakeholder.
• El equipo responde ¿qué hizo desde la última Daily?¿qué va a hacer hasta la próxima
Daily?¿qué impedimentos ha tenido?
23. Revisión del Sprint
• Demostración de las nuevas funcionalidades que el equipo desarrolló durante el
Sprint.
• Se inspecciona lo entregado por el equipo y se obtiene retroalimentación de los
asistentes para poder adaptar el plan para próximos Sprints.
• Deben asistir todos los involucrados relevantes para ayudar al equipo con
retroalimentación valiosa sobre el producto.
• 4 horas para un Sprint de un mes.
• El resultado es un Product Backlog revisado que define los elementos posibles para
el siguiente Sprint.
24. Retrospectiva del Sprint
• El foco es la mejora continua del proceso.
• Se restringe a los miembros del equipo Scrum.
• Se inspecciona en profundidad cuán colaborativo y productivo es el equipo y
cómo hacer para mejorar.
• Luego de la reunión el equipo debe haber identificado y se debe
comprometer con acciones de mejora para el proceso.
• 3 horas para un Sprint de un mes.
25. Refinamiento del Product Backlog
• Liderado por el Product Owner.
• Actividad colaborativa entre Product Owner, Scrum Master, Equipo de
Desarrollo e involucrados externos.
• El Product Owner toma las decisiones.
28. Product Owner
• Responsable de definir que será desarrollado y en qué orden.
• Empoderado para ser el punto central del producto.
• Responsable del éxito de la solución desarrollada.
• Responsable de que el trabajo que se realice de el mayor valor de negocio (ROI).
• Trabaja de forma colaborativa con el Scrum Master y el equipo de desarrollo.
• Debe estar disponible para responder las preguntas sobre el producto, tan pronto
como se presenten.
• Responsable de revisar el producto desarrollado.
29. Scrum Master
• Responsable de guiar al equipo en crear y seguir su propio proceso basado en Scrum.
• Facilitador que ayuda al equipo a resolver los problemas que van apareciendo y a mejorar
la aplicación de prácticas Scrum.
• Líder de procesos, ayudando al equipo a lograr un alto desempeño.
• Responsable de proteger el equipo de cualquier interferencia externa.
• Enseña al equipo a auto administrarse.
• Guía de las reuniones Scrum.
• Es un mentor, no una autoridad jerárquica.
• Toma el liderazgo para remover impedimentos del equipo.
30. Equipo de desarrollo
• Responsables por definir como entregar el producto solicitado por el Product
Owner.
• Se auto organiza para cumplir los objetivos.
• Puede tener entre 3 y 9 miembros. Tamaño típico 7+/-2.
• Los miembros del equipo deben tener todas las habilidades para crear un producto
funcional de alta calidad (equipo multifuncional).
• Enfocados y comprometidos.
• Comunicación constante y transparente.
33. Product Backlog
• Se busca hacer el trabajo más valioso primero.
• Administrado por el Product Owner.
• Inicialmente son las características requeridas para cumplir la visión del producto.
• En el desarrollo se puede alimentar con nuevas características, cambios a
características existentes, corrección de defectos, mejoras técnicas, etc.
• Es un artefacto en constante evolución. Se pueden adicionar, eliminar elementos o
cambiar prioridades de los elementos (refinamiento).
• Responde a ¿Qué hacer?
34. Sprint Backlog
• Se revisa el Product Backlog y se determinan los elementos de alta prioridad
que puedan realísticamente ser incluidos en el Sprint.
• Se dividen los elementos del Product Backlog en tareas.
• Responde a ¿Cómo hacerlo?
35. Incremento del producto
• Parte terminada del producto o incremento de un producto existente.
• El equipo tiene la confianza de que el producto está listo para ser liberado.
• La liberación es decisión del negocio.
37. Bibliografia
• Shwaber Ken, Sutherland Jeff. La Guía Definitiva de Scrum: Las Reglas del Juego.
2013 Julio. Disponible en:
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf
• Rubin, Kenneth. Essential Scrum. Addison-Wesley. 2012. 452p.
• Principios Manifiesto Ágil, http://agilemanifesto.org/iso/es/principles.html
• Colusso Ricardo, Gabardini Juan. Desarrollo ágil de software: Una introducción a
las metodologías ágiles de desarrollo de software [Internet]. Versión 1. agilesintro.
2011 Nov 26. Disponible en: https://agilesintro.wordpress.com/article/desarrollo-
agil-de-software-3satfj6065tbv-2/.