You are on page 1of 22

SCRUM

Presentan
Héctor Hernández
Ixchel Zazueta
¿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.
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.
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.
Los pilares de SCRUM
Scrum preescribe 4 formas de inspección -
adaptación:

● Sprint Planning Meeting


● Daily Scrum
● Sprint Review Meeting
● Sprint Retrospective
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”
Scrum Framework
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.
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.
Team

● Tamaño : 5-9 personas


● conformado por diseñadores, testers,
programadores, etc.
● Miembros deben estar presentes tiempo
completo.
● Auto organizables
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.
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.
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
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?
Artefactos
● Product Backlog
● Sprint Backlog
● Burndown Chart
● Muestra el trabajo acumulado que queda en un
sprint, día a día.

Resumiendo
Quiénes usan SCRUM
http://www.youtube.com/watch?
v=41adYnJ2k3s&feature=player_embedded
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
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