Este documento proporciona una introducción a SCRUM, una metodología ágil para el desarrollo de software. Explica los roles clave de Product Owner, Development Team y Scrum Master, así como los artefactos centrales de Product Backlog, Sprint Backlog y Definition of Done. También describe los eventos principales de Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective que estructuran cada iteración o Sprint en SCRUM.

1. SCRUM
Angel Lacret

2. Modulo I
- Metodologias ágiles
- Antecedentes
- Manifesto agile
- ¿Por qué Agil?
- Filosofia Ágil
- Valor en el manejo de proyectos
SCRUM

3. Modulo II
- SCRUM
- Roles
- Artefactos
- Eventos (Planning, Daily, Retrospective)
- MOSCOW (ROI)
SCRUM

4. Modulo I
SCRUM

5. Metodologías ágiles
Las metodologías ágiles son una alternativa al manejo tradicional de
proyecto usado típicamente en el desarrollo de software. Ayuda a los
equipos a responder a la incertidumbre a través del trabajo iterativo e
incremental en periodos conocidos como sprints. Las metodologías
ágiles con una alternativa al desarrollo secuencial o en cascada. (http:
//agilemethodology.org/)
SCRUM

6. Antecedentes
- 1957: Bernie Dimsdale en IBM (Los Angeles, California)
- 1970: New York Telephone Company's Systems Development Center
- 1974: Edmons, E.A. “A Process for the Development Software for
Nontechnical Users as an Adaptive System “, General Systems
- Muchas otras más durante los 80 y 90 criticando la rigurosidad de los
procesos en cascadas
- 1994: El Proceso unificado Racional de IBM
- 1995: SCRUM
SCRUM

7. Antecedentes
- 1996: Crystal Clear y Extreme Programming (XP)
- 2001: Manifesto Agile
SCRUM

8. Agile Manifesto
- En el 2001, un grupo de desarrolladores se reúnen en
SnowBird, Utah, USA, para discutir nuevas formas ligeras
de desarrollar el software, y concluyen en lo siguiente:
SCRUM

9. Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
SCRUM

10. Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
SCRUM

11. Agile Manifesto
1) Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua
de software con valor.
2) Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3) Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
SCRUM

12. Agile Manifesto
4) Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana
durante todo el proyecto.
5) 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.
6) 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.
SCRUM

13. Agile Manifesto
7) El software funcionando es la medida principal de progreso.
8) Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores
y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9) La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
SCRUM

14. Agile Manifesto
10) La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11) Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12) A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.
FUENTE: http://agilemanifesto.org/
SCRUM

15. ¿Por qué Agil?
¿Por qué tomar una aproximación ágil a un proyecto?
¿Por qué adoptar una filosofía ágil de desarrollo de software?
SCRUM

16. ¿Por qué Agil?
INCERTIDUMBRE y CULTURA
SCRUM

17. ¿Por qué Agil?
INCERTIDUMBRE
SCRUM

18. ¿Por que Agil?
INCERTIDUMBRE:
En la tecnología a implementar
En el alcance de las fases o de la totalidad del proyecto
En la respuesta o aceptación de los usuarios
En el mercado objetivo
En los procesos de negocio
En los requisitos
En los cambios
SCRUM

19. ¿Por qué Agil?
CULTURA
SCRUM

20. ¿Por que Agil?
CULTURA:
La Cultura Organizacional se refiere a los gustos, costumbres, valores,
experiencias y creencias de un grupo de personas dentro de una Empresa.
Con el pasar de los años la experiencia ha demostrado que la productividad en los
miembros de una organización está directamente relacionada con la motivación y
la sensación de bienestar que estos puedan tener dentro de su entorno laboral,
sensaciones que están directamente relacionadas con la Cultura dentro de la
empresa.
SCRUM

21. ¿Por que Agil?
CULTURA:
Actualmente cada vez más empresas han evolucionado a una Cultura más
orientada o propensa a adaptarse al dia a dia de las personas, siendo consecuente
con las emociones y sensaciones de estas.
Factores como empoderamiento, confianza, interacción y autoorganización, -
pilares fundamentales dentro de las metodologías ágiles- representan valores
que van en consonancia con las nuevas tendencias de culturas organizacionales.
La agilidad, como la cultura es “peoplecentric”
SCRUM

22. Filosofia Ágil
SCRUM

23. Filosofia Ágil
- No podemos predecir o planear con absoluta certeza lo que vamos a entregar, cuanto
lo entregaremos y cuál será su costo
- Empecemos con planes iniciales alrededor de las estimaciones, fechas y alcances, pero
enfoquémonos en la revisión continua de estas restricciones a medida que avanzamos
- La meta es entregar el mejor software posible dadas estas restricciones, pero ningun
metodo con el enfoque de receta de cocina mejorará lo que es “mejor”
Fuente: http://www.slideshare.net/luchoslide/cultura-agil-v210
SCRUM

24. ¿Valor en el manejo de proyectos?
SCRUM

25. Valor en el manejo de proyectos
- Aumento de la productividad por el uso de una metodología alrededor de
la cultura
- Comunicaciones eficientes gracias a un marco de interacción entre sus
miembros
- Respuesta rápida de parte de equipos autoorganizados
- Capacidad de maniobrabilidad por el empoderamiento de las estructuras
ágiles
SCRUM

26. Modulo II
- SCRUM
- Roles
- Artefactos
- Eventos (Planning, Daily, Retrospective)
- MOSCOW (ROI)
SCRUM

27. Modulo II
SCRUM

28. SCRUM
Fuente (www.scrumalliance.org)
SCRUM

29. SCRUM
A framework within which people can address complex adaptive problems, while productively and
creatively delivering products of the highest possible value.
Scrum is: Lightweight, Simple to understand, Difficult to master
Scrum is a process framework that has been used to manage complex product development since the
early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within
which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your
product management and development practices so that you can improve.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and
rules. Each component within the framework serves a specific purpose and is essential to
Scrum’s success and usage.
SCRUM

30. SCRUM
PILARES:
- Empirismo (Experiencia y conocimiento): Transparencia,
Inspección y Adaptación
- Iterativo e Incremental
SCRUM

31. SCRUM
VALORES:
- Enfoque: Pocas cosas a la vez
- Coraje: Tomar grandes retos
- Franqueza: expresar emociones y preocupaciones
- Compromiso: Comprometerse con el equipo
- Respeto: Para cada miembro del equipo
SCRUM

32. ROLES (El Equipo)
SCRUM

33. ROLES (El Equipo)
- Product Owner
- Development Team (Developers, QA, ….)
- Scrum Master
SCRUM

34. ROLES: Product Owner
- Responsable de maximizar el valor del producto
- Responsable del Backlog
- Expresa bien los requerimientos o hace que el equipo lo haga
- Es uno solo, y es el punto de convergencia de los cambis solicitados por
interesados
- Comunicativo y transparente
SCRUM

35. ROLES: Development Team
- Autoorganizado y Multidisciplinario
- Es el unico que entrega valor al producto a traves del incremento
- Scrum no reconoce titulos (Ministro, Super intendente, Mariscal …)
- No hay subequipos
- Pueden ser diversos, pero todos cuentan cómo Development Team
- Idealmente entre 4 y 8 (Two Pizza Teams)
SCRUM

36. ROLES: Scrum Master
- Garantizar SCRUM
- Es el un SERVANT-LEADER
- Mejoras las interacciones dentro del equipo
SCRUM

37. ARTEFACTOS
SCRUM

38. ARTEFACTOS
- Product Backlog
- Sprint Backlog
- Definition of Done
SCRUM

39. ARTEFACTOS: Product Backlog
- Única fuente de requerimientos para el equipo
- Todo lo que debería tener el producto
- Responsabilidad del Product Owner
- Ordenado por prioridad
- No necesita estar completo
- Estimado por el Development Team
SCRUM

40. ARTEFACTOS: Sprint Backlog
- Subconjunto del Product Backlog
- Priorizado
- Bien claro
- Compone el Sprint Goal
SCRUM

41. ARTEFACTOS: Definition of Done
- Definicion de que quiere decir LISTO
- Cuando se declara un item como LISTO, es necesario que todo el mundo
sepa que quiere decir LISTO
- En equipos complejos incluye requerimientos e items de calidad. Ejemplo:
Pantallas, Pruebas unitarias, Desarrollo, Integración, QA
SCRUM

42. EVENTOS ó CEREMONIAS
SCRUM

43. EVENTOS
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
SCRUM

44. EVENTOS: Sprint Planning
- El trabajo a ser realizado en el Sprint
- Participa todo el equipo de trabajo
- Máximo de 8 horas para Sprints de un mes
- Responde a lo que va ser entregado en el Sprint (Sprint Goal)
- Los items seleccionados para el Sprint deben ser aclarados en este evento
SCRUM

45. EVENTOS: Daily Scrum
- Reunión diaria de 15 minutos para sincronizar las actividades que se están
realizando
- Lo miembros de el Development Team responden: ¿Que hice ayer?, ¿Que
hare hoy?, ¿Note un impedimento para continuar con el trabajo?
- Es responsabilidad del Scrum Master que se de la reunión, pero es ejecutada
por el Development Team
- Solo para el Development Team
SCRUM

46. EVENTOS: Sprint Review
- Inspeccionar el incremento
- Se cambia el Backlog de ser necesario
- 4 horas en sprint de un mes
- El product owner explica el avance
- Se revisan los problemas y cómo se resolvieron
- Se revisan los tiempos, presupuestos etc
SCRUM

47. EVENTOS: Sprint Retrospective
- Despues del Sprint Review
- Una oportunidad para mejorar e implementar correcciones
- Crear un plan para estas mejoras
SCRUM

48. SCRUM?
SCRUM

49. SCRUM
SCRUM!

50. ALGO EXTRA
SCRUM

51. ESTIMACIONES
SCRUM

52. ESTIMACIONES
- Planning Poker
SCRUM

53. MOSCOW
SCRUM

54. MOSCOW
- Must have: Items necesarios en el Sprint
- Should: Importante pero no necesario, no criticos.
- Could have: deseables pero no necesarios, pueden mejorar la experiencia o
satisfacción a un bajo costo
- Won't have: menor criticidad, bajo valor, o no apropiados en este momento
-
SCRUM

55. PROJECT MANAGER
vs
SCRUM MASTER
SCRUM

56. PECADOS EN SCRUM
SCRUM

57. PECADOS EN SCRUM
- Puntos de historia como horas de trabajo
- Sobreestimar
- Convertir al project manager en el scrum master
- Convertir al scrum master en el product owner
- No tener dailys meeting
- Alargar los sprints
- No hacer retrospectives meetings
SCRUM