4. Scrum
“The New New Product Development
Game” in Harvard Business Review, 1986.
◦ “The… ‘relay race’ approach to product
development…may conflict with the goals of
maximum speed and flexibility. Instead a
holistic or ‘rugby’ approach—where a team
tries to go the distance as a unit, passing the
ball back and forth—may better serve today’s
competitive requirements.”
5. El software es colectivo
Conocimientos
Conocimientos
Estados de
Estados de
ánimos
ánimos
Actitud
Actitud
6. Manifesto for Agile Sof tware
Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
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.
8. ¿Proyecto predecible?
Far from
Agreement
Requirements
Anarchy
Close to
Agreement
Complex
Co
m
pl
ica
te
d
Perdida debido a
erosión de la
participación de
mercado
Simple
Close to
Certainty
Perdida
debido a
planes
inadecuados
Technology
Far from
Certainty
Fuente: “Strategic Management and Organizational Dynamics “, Ralph Stacey
tomado de “Agile Software Development with Scrum”, Ken Schwaber y Mike Beedle.
9.
10. Valor .
¿Seguimos el contrato o hacemos lo
que necesitas?
1
2
3
4
5
6
7
Iteraciones
8
9
10
11
12
11. Scrum en 100 palabras
• Scrum es un proceso ágil que nos permite centrarnos
en ofrecer el más alto valor de negocio en el menor
tiempo.
• Nos permite rápidamente y en repetidas ocasiones
inspeccionar software real de trabajo (cada dos semanas
o un mes).
• El negocio fija las prioridades. Los equipos se autoorganizan a fin de determinar la mejor manera de
entregar las funcionalidades de más alta prioridad.
• Cada dos semanas o un mes, cualquiera puede ver el
software real funcionando y decidir si liberarlo o seguir
mejorandolo en otro sprint.
15. 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
16. 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
17. 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
19. Daily Scrum meetings
Características
Tres preguntas:
1.
2.
3.
¿Qué hice ayer?
¿Qué haré hoy?
¿Encontré obstáculos/impedimentos?
Gallinas (invitados) y chanchos
Diarios
15 minutos
Parados
No son para resolución de problemas
Ayuda a evitar reuniones adicionales
Solo los chanchos hablan
20. Sprint Review Meeting
• El Equipo presenta lo logrado
• Normalmente se muestra la nueva
funcionalidad
• Informal
– Regla: 2 hs de preparación
• El cliente / PO usa el producto
• Participantes
–
–
–
–
Clientes
Gerencia
Product Owner
Miembros de otros equipos
21. Sprint Retrospective Meeting
• Sólo el Equipo
– A veces el Product Owner participa
• Instancia de aprendizaje
• Tres preguntas
– Empezar
– Dejar
– Continuar
• … o dos
– Mantener
– Cambiar
R
A
T
N R
E E O
T C
IN HA IP
U
Q
E
23. Product Backlog
• Lista del lo que se quiere tener en el
producto
– Basados en historias de usuario.
– A veces tareas técnicas.
• Lista priorizada por el Product Owner
– Unificando visiones: Product Manager,
Marketing, Cliente interno, etc.
28. Dayly meetgings
What did you do yesterday?
What will you do today?
Are there any impediments in your way?
My ____ broke and I need a new one today.
I still haven't got the software I ordered a month ago.
I need help debugging a problem with ______.
I'm struggling to learn ______ and would like to pair with someone on it.
I can't get the vendor's tech support group to call me back.
Our new contractor can't start because no one is here to sign her contract.
I can't get the ____ group to give me any time and I need to meet with them.
The department VP has asked me to work on something else "for a day or two."
31. • Como <rol de usuario>, quiero <función
de sistema> para lograr <valor de
negocio>
• Consiste de
– Descripción escrita
– Conversación (detalle, documentos,…)
– Pruebas de aceptación (def. completo)
33. Estimación
• Métricas
– Story point.
– Días ideales.
• Precisión de la estimación
– Mejora limitada al aumentar el tiempo de
estimación.
– Los que hacen la tarea.
– Estimación, no compromiso.
33
36. •
•
•
•
•
•
•
Pérdida de ritmo.
Chickens hablando en Daily Scrum.
Pigs que no están en el Daily Scrum.
Equipos que no aprenden.
Trabajo asignado (por el ScrumMaster).
Daily Scrum para el ScrumMaster.
Roles especializados.
40. FAQ sobre las reuniones
• ¿Por que diarias?
– “How does a project get to be a year late?”
• “One day at a time.”
– Fred Brooks, The Mythical Man-Month.
• ¿Puede reemplazarse la reunión por mails?
– No!
– El equipo completo ve la foto completa
– El compromiso es ante todos
40
Notes de l'éditeur
Software colectivo. Esta realizado por los ánimos de todos los involucrados. Las personas no son máquinas. El desarrollo de software se hace con el cerebro, no de forma automatizada.
Scrum is a simple "inspect and adapt" framework that has three roles, three ceremonies, and three artifacts