Scrum es una metodología ágil para el desarrollo de software que se basa en iteraciones cortas llamadas sprints para entregar valor al cliente de forma continua. Los roles clave son el Product Owner, que prioriza las características, el Scrum Master, que guía el proceso, y el equipo auto-organizado que desarrolla el producto. Scrum se enfoca en la inspección y adaptación continua a través de eventos como la revisión y retrospectiva del sprint.

1. SCRUM
Presentan
Héctor Hernández
Ixchel Zazueta

2. ¿Qué es SCRUM?
● Metodología de desarrollo ágil
● Permite enfocarte en la entrega de el mayor valor de
negocio en el menor tiempo posible.
● Permite rápida y repetitivamente inspeccionar el
software funcional existente (2 semanas - 1 mes).
● Los equipos se auto-organizan para determinar la mejor
manera de entregar el componente de mayor prioridad.
● Cada dos semanas - un mes, cualquiera puede ver el
resultado real del software funcionando y decidir liberarlo
como esta o si continuar iterando para mejorarlo.

3. Orígenes
● 1986 se publicó en HBR por Hirotaka Takeuchi y Ikujiro
Nonaka
○ cámaras de fotos de Canon, fotocopiadoras de Xerox,
automóviles de Honda, ordenadores de HP
○ Los equipos partían de requisitos muy generales,
novedosos, y debían salir al mercado en corto tiempo
○ La forma de trabajo de equipos altamente productivos y
multidisciplinares VS la colaboración entre los jugadores
de Rugby y su formación de Scrum
● En 1993 se realizó el primer Scrum para desarrollo de
software
● En 1995 el proceso fue formalizado por Ken Schwaber
● En 2001 se escribieron los valores fundamentales de los
procesos ágiles.

4. Características
● Desarrollo de software iterativo e incremental basado en
prácticas ágiles.
● Liberación de entregables reales en 30 días.
● Aplicación a nuevos y/o existentes proyectos.
● Se acomoda a cualquier tipo de proyectos de desarrollo.
● Se guía en los 12 principios del manifiesto ágil.
● Simple de entender, difícil de masterizar.

5. Los pilares de SCRUM

6. Scrum preescribe 4 formas de inspección -
adaptación:
● Sprint Planning Meeting
● Daily Scrum
● Sprint Review Meeting
● Sprint Retrospective

7. Product Backlog
● Lista del trabajo de todo lo que el equipo debe hacer para
acabar el producto. Todos los requerimientos.
● Sprint: Las nuevas adiciones o nuevas características
se desmenuzan en tareas, las que deberían dividirse
entre cuatro y dieciséis horas de trabajo.
● Las tareas en el backlog del Sprint no son asignadas =>
Auto-organización
● A menudo se usa un pizarrón
de tareas: “por hacer”
“en progreso” y “terminado”

8. Scrum Framework

9. Roles de canela
Product Owner
● Define las características del producto.
● Define la fecha de lanzamiento y el contenido.
● Es responsable de la rentabilidad del producto.
● Prioritiza las características de acuerdo a su
valor.
● Ajusta caracteristicas y prioridades en cada
iteración.
● Acepta o rechaza el trabajo realizado.

10. Scrum Master
● Administra el proyecto
● Responsable de que se lleven a cabo las
practicas de Scrum.
● Remueve Impedimentos.
● Asegurar que el equipo sea funcional y
productivo.
● Habilitar la cooperacion entre todos los roles y
funciones.
● Escudo del equipo contra interferencias externas.

11. Team
● Tamaño : 5-9 personas
● conformado por diseñadores, testers,
programadores, etc.
● Miembros deben estar presentes tiempo
completo.
● Auto organizables

13. Eventos
Sprint Planning
● El equipo selecciona tareas del product backlog
que puedan ser completadas.
● Se crea el Sprint Backlog
● Se considera diseño de alto nivel.

14. Eventos
Sprint review
● El equipo presenta lo que se ha completado
dentro de la iteracion.
● informal
○ 2 hrs max
○ Sin diapositivas
● Todo el equipo participa.

15. Eventos
Sprint Retrospective
● Se analiza lo que está y no está funcionando.
● Duración: 15 a 30 min
● Se realiza despues de cada iteración.
● Todo el equipo participa
● Todo el equipo discute lo que quiere:
○ Empezar a hacer
○ Dejar de Hacer
○ Continuar Haciendo

16. Eventos
Daily Scrum Meeting
● Diario
● 15 min
● Stand Up
● No se resuelven problemas
● Ayuda a evitar reuniones que no son necesarias
● Preguntas claves
○ ¿Qué hiciste ayer?
○ ¿Qué harás ahora?
○ ¿Qué es lo que no te deja avanzar?

17. Artefactos
● Product Backlog
● Sprint Backlog
● Burndown Chart
● Muestra el trabajo acumulado que queda en un
sprint, día a día.
●

18. Resumiendo

19. Quiénes usan SCRUM

20. http://www.youtube.com/watch?
v=41adYnJ2k3s&feature=player_embedded

21. Referencias
SCRUM The art of the possible (Advanced Development
Methods Lexington, Massachusetts). Recuperado de http:
//controlchaos.squarespace.com/storage/scrum-
articles/Brochure.pdf
ftp://ftp-developpez.com/bruno-orsier/scrum/fichiers/Notes%
20from%20Agile%20Project%20Management%20with%
20Scrum.pdf
http://www.agilemanifesto.org/
http://www.scrum.org/storage/scrumguides/Scrum%20Guide%
20-%202011.pdf

22. Doce principios del desarrollo ágil:
● Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y
continua de software que aporte valor.
● Aceptamos de buen grado cambios en los requisitos, incluso si llegan tarde al
desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del
cliente.
● Entregar con frecuencia software que funcione, desde un par de semanas hasta un par
de meses, con preferencia a la escala de tiempo más corta.
● La gente de negocio y los desarrolladores deben trabajar juntos de forma cotidiana
durante todo el proyecto.
● Construir proyectos en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en que ellos conseguirán hacer el trabajo.
● El método más eficiente y efectivo de comunicar información a y dentro de un equipo
de desarrollo es la conversación cara a cara.
● El software que funciona es la principal medida de progreso.
● Los procesos ágiles promueven el desarrollo sostenido. Los promotores, desarrolladores
y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida.
● La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
● La simplicidad, el arte de maximizar la cantidad de trabajo que no se hace, es esencial.
● Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
● En intervalos regulares, el equipo reflexiona en cómo ser más efectivo, se afina y