Esta es una presentacion de Scrum y sus fundamentos basicos.

2. ¿Por que fallan los proyectos?
¿Por qué fallan los suyos?

3. La cruda realidad

4. Causa de Fracasos en los
Proyectos
 Cronogramas poco realistas
 Personal inadecuado
 Cambios en los requerimientos
 Trabajo de pobre calidad
 Creer en magia
 Winning with Software: An Executive
Strategy. Watts S. Humphrey

5. ¿VIAJARÍA USTED EN UN
AVIÓN AL QUE USTED LE
ESCRIBIÓ EL SOFTWARE
DE NAVEGACIÓN?

6. Manifiesto Ágil
Estamos descubriendo formas mejores de desarrollar software
tanto por nuestra propia experiencia como ayudando a terceros. A
través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
http://agilemanifesto.org/iso/es/

7. Los 12 Principios
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.
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.
7. El software funcionando es la medida principal de progreso.
http://agilemanifesto.org/iso/es/

8. Los 12 Principios
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.
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.
http://agilemanifesto.org/iso/es/

9. Valores
 Compromiso
 Enfoque y Foco
 Apertura y transparencia
 Respeto
 Coraje

10. Objetivo: Pasar a la otra orilla a pie sin
mojarse (sin usar un puente, etc, etc.)

11. Crecimiento orgánico
(iterativo e incremental)
Una
mujer con
una
pradera
atrás

12. Diferencias entre enfoque iterativo y
enfoque orgánico (iterativo e
incremental)

13. SCRUM
“El Arte de Amar los Lunes”.
Alan Cyment

14.  Scrum es una framework metodológico para la gestión
de proyectos, expuesta por Hirotaka Takeuchi e Ikujiro
Nonaka, en el artículo The New New Product
Development Game[Harvard Business Review Ene-Feb
1986] en el que ponen de manifiesto que:
 El mercado competitivo de los productos tecnológicos,
además de los conceptos básicos de calidad, coste y
diferenciación, exige también rapidez y flexibilidad.
 Los nuevos productos representan cada vez un porcentaje
más importante en el volumen de negocio de las empresas.
 El mercado exige ciclos de desarrollo más cortos.

15. Scrum ha sido utilizado por:
•Microsoft
•Yahoo
•Google
•Electronic Arts
•High Moon Studios
•Lockheed Martin
•Philips
•Siemens
•Nokia
•Capital One
•BBC
•Intuit
•Intuit
•Nielsen Media
•First American Real Estate
•BMC Software
•Ipswitch
•John Deere
•Lexis Nexis
•Sabre
•Salesforce.com
•Time Warner
•Turner Broadcasting
•Oce

16. Scrum ha sido utilizado para:
 Software comercial
 Desarrollos internos
 Desarrollos bajo Contrato
 Proyectos Fixed-price
 Aplicaciones Financieras
 Aplicaciones certificadas ISO
9001
 Sistemas Embebidos
 Sistemas con requisitos 7x24
y 99.999% de disponibilidad
 Joint Strike Fighter
• Desarrollo de video juegos
• Sistemas críticos de soporte
vital, aprobados por laFDA
• Software de control satelital
• Sitios Web
• Software para Handheld
• Teléfonos portátiles
• Aplicaciones de Network
switching
• Aplicaciones de ISV
• Algunas de las más grandes
aplicaciones en uso

17. Características
 Equipos auto-organizados
 El producto avanza en una serie de “Sprints"
de dos semanas a un mes de duración
 Los requisitos son capturados como
elementos de una lista de “Product Backlog"
 No hay prácticas de ingeniería prescritas
 Utiliza normas generativas para crear un
entorno ágil para la entrega de proyectos
 Uno de los “procesos ágiles”

18. Sprints
 En Scrum los proyectos avanzan en
una serie de “Sprints”
 Análogo a las iteraciones en XP
 La duración típica es 2–4 semanas o a
lo sumo un mes calendario
 La duración constante conduce a un
mejor ritmo
 El product es diseñado, codificado y
testeado durante el Sprint

19. Scrum Framework
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Reuniones
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos

20. Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Reuniones
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos
•Product owner
•ScrumMaster
•Team
Roles

23. Product Owner
 Define las funcionalidades del producto
 Decide sobre las fechas y contenidos de los releases
 Es responsable por la rentabilidad del producto (ROI)
 Prioriza funcionalidades de acuerdo al valor del mercado/negocio
 Ajusta funcionalidades y prioridades en cada iteración si es
necesario
 Acepta o rechaza los resultados del trabajo del equipo

24. Product Owner
El espiritu de Scrum.
Alan Cyment

25. El ScrumMaster
 Representa a la gestión del proyecto
 Responsable de promover los valores y prácticas de
Scrum
 Remueve impedimentos
 Se asegura de que el equipo es completamente
funcional y productivo
 Permite la estrecha cooperación en todos los roles y
funciones
 Escudo del equipo de interferencias externas

26. El Team
 Típicamente de 5 a 9 personas
 Multi-funcional:
◦ Programadores, testers, analistas, diseñadores, etc.
 Los miembros deben ser full-time
◦ Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)
 Los equipos son auto-organizativos
◦ Idealmente, no existen títulos pero a veces se utilizan de
acuerdo a la organización
 Solo puede haber cambio de miembros entre los sprints

27. Interacción entre los roles
Fuente: El espiritu de Scrum.
Alan Cyment

28. •Product owner
•ScrumMaster
•Team
Roles
Scrum Framework
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Reuniones

29. Sprint Planning meeting
Priorización
• Analizar y evaluar el Product
Backlog
• Seleccionar el objetivo del Sprint
Planificación
• Decidir como alcanzar el
objetivo del Sprint (diseño)
• Crear el Sprint Backlog (tareas)
en base a los temas del Product
Backlog (user stories / features)
• Estimar Sprint Backlog en horas
Objetivo
del Sprint
Sprint
Backlog
Condicione
s del
Negocio
Capacidad
del Equipo
Product
Backlog
Tecnología
Producto
Actual

30. Planificación del Sprint
 El equipo selecciona los temas a partir del Product
Backlog que pueden comprometerse a completar
 Se crea el Sprint Backlog
 Se identifican tareas y cada una es estimada (1-16 horas)
 Realizado colaborativamente, no solo por el ScrumMaster
 El diseño de Alto Nivel es considerado
YO COMO planificador
de vacaciones, QUIERO
ver fotos de los
hoteles. PARA poder
mostrar diferentes
sitios a mis clientes
Codificar la capa intermedia (8 hs)
Codificar la interfaz de usuario (4)
Escribir los test fixtures (4)
Codificar la clase foo (6)
Actualizar test de performance (4)

31. Daily Scrum
 Parámetros
 Diaria
 Dura 15 minutos
 Parados
 No para la solución de problemas
 Todo el mundo está invitado
 Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden
hablar
 Ayuda a evitar otras reuniones innecesarias

32. Todos responden 3
preguntas
 No es dar un status report al Scrum Master
 Se trata de compromisos delante de pares
¿Qué hiciste ayer?
1
¿Qué vas a hacer hoy?
2
¿Hay obstáculos en tu camino?
3

33. Sprint review
 El equipo presenta lo realizado durante el
sprint
 Normalmente adopta la forma de una
demo de las nuevas características o la
arquitectura subyacente
 Informal
◦ Regla de 2 hs preparación
◦ No usar diapositivas
 Todo el equipo participa
 Se invita a todo el mundo

34. Sprint retrospective
 Periódicamente, se echa un vistazo a lo que
funciona y lo que no
 Normalmente 1 hora
 Se realiza luego de cada sprint
 Todo el equipo participa
 ScrumMaster
 Product owner
 Equipo
 Posiblemente clientes y otros

35. Retrospective
 Por lo general se evalua
Felicidad
Productividad
Calidad
Esto es sólo una
de las muchas
maneras de
hacer una
retrospectiva.

36. •Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Reuniones
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos

37. Ejemplo de Product
Backlog

38. Ejemplo de Sprint
Backlog
Tareas
Codificar UI
Codificar negocio
Testear negocio
Escribir ayuda online
Escribir la clase foo
L
8
16
8
12
8
M
4
12
16
8
M J
4
11
8
4
V
8
8
Agregar error logging
8
10
16
8
8

39. Scrum estar acompañado
de buenas prácticas de
ingeniería.
Scrum = reglas + espíritu + buenas
prácticas