1. SCRUM – Gestión ágil de proyectos de software
JAI v.2.0
20
Rosario 5 Dic 2006
Fabián Longhitano

2. Objetivo
Presentar un proceso de gestión de proyectos
(SCRUM) aplicable a desarrollo de productos con
requerimientos que tienen alto nivel de
q q
incertidumbre.
Fabián Longhitano – JAI v. 2.0

3. Algunos problemas en la gestión de proyectos de software
Requerimientos fuera de control
No cumplimiento de los tiempos
planificados (Desvíos)
Estimaciones deficientes
Re-trabajo excesivo
Baja calidad
j
Costos excedidos
Insatisfacción del Cliente
Insatisfacción de los profesionales
participantes
Etc. etc. etc.
Fabián Longhitano – JAI v. 2.0

4. Estrategias actuales para desarrollar software
Sin procesos Procesos compliance CMMI
Waterfall RUP, prototipación
Sin documentación Con documentación
Planificación informal Planificación formal
Equipos no Equipos disciplinados
disciplinados
di i li d
Equipos entrenados
Equipos no
Etc., etc…
entrenados
Etc., etc…
Ninguna metodología garantiza el éxito absoluto!!
La clave está en saber discernir cual es la que mejor
se ajusta a nuestras necesidades
Fabián Longhitano – JAI v. 2.0

5. Nivel de ruido en los proyectos
Lejos del
acuerdo
Scrum
Anarquia
ntos
equerimien
S
Complejo
Re
Simple
Cerca del
acuerdo
Tecnología
Cerca de Lejos de la
la certidumbre certidumbre
Source: Strategic Management and
Organizational Dynamics by Ralph Stacey
in Agile Software Development with Scrum
by Ken Schwaber and Mike Beedle.
Proceso definido o empirico?
Fabián Longhitano – JAI v. 2.0

6. El mercado d
d demanda !!!!
d
Alta calidad + diferenciación + bajo costo
se requiere
Velocidad + Flexibilidad
Qué estrategia utilizamos para gestionar el
desarrollo?
Fabián Longhitano – JAI v. 2.0

7. Qué tienen en común cuando desarrollan sus productos?
Inestabilidad incorporada
Equipos auto - organizados
Multi - aprendizaje
Control Sútil
Transferencia de aprendizaje a nivel
organizacional
Fases de desarrollo solapadas
“Estas características son como piezas de un rompecabezas. Cada
elemento por si mismo no aporta fl ibilid d y velocidad. C
l t ii t flexibilidad l id d Cuando se
d
complementan pueden producir una poderosa dinámica que hace la
diferencia.”
Hirotaka Takeuchi y Ikujiro Nonaka – The new new product
j p
development game – Harvard Business Review 1986
Fabián Longhitano – JAI v. 2.0

8. Estilos de administración de proyectos
The new new product development Takeuchi y Nonaka (1986)
Fabián Longhitano – JAI v. 2.0

9. Gestión ágil de proyectos - SCRUM
Proceso ágil de gestión de proyectos desarrollado por Ken Schwaber y Mike
Beedle.
Enfocado al desarrollo de productos de manera empírica.
Proceso simple que requiere mucha disciplina para q resulte exitoso.
pq q p p que
Administración de requerimientos
Muy riguroso!!!
Administración de riesgos
Planificación y seguimiento
Se basa en los principios ágiles:
Colaboración estrecha con el cliente
Predisposición y respuesta al cambio
Desarrollo incremental con entregas funcionales frecuentes
Motivación y responsabilidad de los equipos por la auto-gestión, auto-
auto-gestión, auto-
organización y compromiso
Fabián Longhitano – JAI v. 2.0

10. Scrum – El proceso
Daily Scrum
Meeting
M ti
Sprint
15-30
días
Product Backlog
User Story - A
Incremento de producto
User Story - B
Tareas identificadas
potencialmente
y estimadas
entregable
User Story - C
Source: Adapted from Agile Software
User Story - D
Development with Scrum by Ken
Schwaber and Mike Beedle.
User Story - E
Fabián Longhitano – JAI v. 2.0

11. Sprint – Iteraciones
Estrategia tradicional - Waterfall
Ventajas Sprint
Los riesgos se reducen a la
duración de un Sprint
Sprint.
Los cambios en los
requerimientos no afectan la
construcción.
t ió
El equipo se concentra en el
Estrategia ágil – Iteraciones fijas (Sprint)
valor del producto no en las
producto,
tareas.
Entrega rápida y períodica de
funcionalidad.
Feedback rápido del cliente.
Iteraciones fijas (usualmente 30 días)
Fabián Longhitano – JAI v. 2.0

12. Roles Scrum
6-8 personas full-time
full-
Auto-
Auto-organizado
Multi-
Multi-funcional
Team
Transforman los requerimientos en funcionalidad
Members
en cada incremento
Define funcionalidad requerida
Toma las decisiones de priorización
Product Representa a todos los interesados en el producto final
Owners
Remueve i
R impedimentos
di t
Facilitador
Asegura que se cumpla Scrum
Scrum
S
Master
Fabián Longhitano – JAI v. 2.0

13. Pig & Chicken?
COMPROMETIDOS EN EL PROYECTO IMPLICADOS EN EL PROYECTO
Product Owner Marketing
Equipo
Ei Comercial
C il
Scrum Master Etc.
Fabián Longhitano – JAI v. 2.0

14. Herramientas - Product Backlog
Lista priorizada de
requerimientos.
Priorizado
P i i d y administrado
d ii d
por el Product Owner
Priorización basada en la
funcionalidad que agrega
mayor valor al negocio.
Evoluciona
E ol ciona según las
condiciones de negocio y/o
tecnología.
Cualquiera puede aportar
nuevos requerimientos.
Es visible a todos
todos.
Reglas esenciales!! : El único que cambia las prioridadades es el PO
Fabián Longhitano – JAI v. 2.0

15. Sprints
Período fijo de tiempo durante el cual el equipo desarrolla un
incremento de funcionalidad (no más de 30 días).
No se aceptan cambios a los requerimientos acordados
El producto es diseñado, codificado y testeado durante
el Sprint
Solo el Scrum Master puede cancelar el Sprint cuando;
La tecnología no funciona
g
Las circunstancias del negocio cambiaron
El equipo tuvo interferencias
Iteraciones cortas permiten reducir riesgos !!!
Fabián Longhitano – JAI v. 2.0

16. Sprint Planning Meeting
Daily Scrum
Meeting
M ti
Sprint
15-30
días
Product Backlog
User Story - A
Tareas identificadas
User Story - B
y estimadas
User Story - C
Source: Adapted from Agile Software
Sprint Backlog
User Story - D
Development with Scrum by Ken
Priorizado y estimado Schwaber and Mike Beedle.
User Story - E
Fabián Longhitano – JAI v. 2.0

17. Sprint Planning Meeting
Dos reuniones:
Primera reunión:
− Se establece la meta del Sprint
− Se identifica la funcionalidad que se va a
construir en el Sprint
Segunda reunión:
− Se identifican y estiman las tareas para
satisfacer
− Se crea un Sprint Backlog
− Las tareas son distribuidas por decisión de
los miembros del equipo
− Los miembros del equipo se comprometen a
cumplir con la meta del Sprint
Entradas:
− Product Backlog actualizado.
− Feedback último Sprint.
− Perfomance del equipo en los Sprint anteriores
Fabián Longhitano – JAI v. 2.0

18. Daily Scrum Meeting
Tres preguntas: todos
responden – de a uno por favor ;) Todos
los días
15 minutos
Qué trabajo realizó ayer?
Eliminar impedimentos!!
Qué trabajo realizará hoy?
Hay algo que necesita o que impide
que realice el trabajo previsto?
Sprint
15- 30
días
Sprint Backlog
User Story - C
User Story - D
User Story - A
y
Source: Adapted from Agile Software
User Story - B
Development with Scrum by Ken
Schwaber and Mike Beedle.
Fabián Longhitano – JAI v. 2.0

19. Daily Scrum Meeting
Duración aproximada de 15 minutos. Todos los días a la misma hora y en el
mismo lugar
Participa el equipo y el Scrum Master (Product Owner opcional)
No hay conversaciones entre los miembros del equipo
Las gallinas pueden asistir pero no hablan!!
No se divaga
eliminar impedimentos
El principal objetivo es
Beneficios:
Beneficios
Mejor entendimiento de las interdependencias entre los miembros de equipo. (sincronización)
Mejora en la comunicación.
Todos conocen el estado del proyecto.
Elimina la necesidad de otras reuniones.
Identifica y remueve impedimentos.
Promueve decisiones rápidas.
Fabián Longhitano – JAI v. 2.0

20. Sprint Backlog Burndown
Velocidad
real del
120
equipo
100
80
Horas
s
Esfuerzo disponible
60
Horas Restantes
40
20
Velocidad 0
0 1 2 3 4 5 6 7 8 9 10
ideal
Días
estimada
Fabián Longhitano – JAI v. 2.0

21. Sprint Review Meeting
Todos
los días
15 minutos
Sprint
15-30
días
Sprint Backlog
User Story - C
Incremento de producto
User Story - D
potencialmente
User Story - A
y
entregable
User Story - B
Fabián Longhitano – JAI v. 2.0

22. Sprint Review Meeting (Qué construímos)
Objetivo: Presentar al Product Owner y demás involucrados del proyecto el trabajo
realizado (incremento del producto) durante el Sprint
Participan: Equipo Scrum Master Product Owner todas las personas involucradas en
Equipo, Master, Owner,
el proyecto
Reglas a seguir:
El Team no invierte más de una hora para preparar el Sprint review
Las funcionalidades no finalizadas completamente no se presentan
Los miembros del equipo presentan las funcionalidades
Las demostraciones se realizan en las workstations de los miembros del equipo
Al finalizar la reunión se pide opiniones a los participantes, los cuales pueden sugerir
cambios y mejoras
Al finalizar:
Se actualiza y vuelve a priorizar el Product Backlog
El Scrum Master anuncia el lugar y la fecha de la próxima revisión de Sprint
El Product Owner decide si la funcionalidad
presentada cumple con los objetivos del Sprint
Fabián Longhitano – JAI v. 2.0

23. Sprint Retrospective (Cómo contruímos)
Objetivo: identificar que cosas se pueden
cambiar para hacer el trabajo más agradable y
productivo en las próximas iteraciones.
Se realiza al finalizar el Sprint
Participantes: Team, Scrum Master Product
Team Master,
Owner (opcional).
Dos preguntas (todos responden):
Qué cosas hicimos bien?
Qué cosas podemos mejorar?
Todo aquello que afecte como el equipo
construye software se debe debatir
Permite al equipo evolucionar continuamente
mejorando durante el proyecto.
Fabián Longhitano – JAI v. 2.0

24. Herramientas – Panel de Control
Tareas en progreso
Historias de usuarios
Tareas a
Burndown Chart
(Sprint Backlog) realizar Tareas finalizadas
Fabián Longhitano – JAI v. 2.0

25. Resumiendo
Scrum es un proceso iterativo e incremental que puede ser utilizado para
desarrollar cualquier producto o administrar cualquier trabajo. Sus principales
atributos son:
Un enfoque orientado a que los equipos desarrollen sistemas y productos de manera
iterativa e incremental cuando los requerimientos cambian de manera rápida
Un
U proceso que controla el caos d conflictos d i t
tl l de fli t de intereses y necesidades
id d
Una manera de mejorar las comunicaciones y maximizar la cooperación
Una manera de maximizar la productividad
Escalable a múltiples proyectos y toda la organización
Una forma que todos se sientan bien con su trabajo, entendiendo que cada uno con sus
contribuciones hizo lo mejor q p
j que podía hacer
Extremadamente simple pero que requiere
mucha disciplina para que funcione !!
Fabián Longhitano – JAI v. 2.0

26. Referencias
www.controlchaos.com
www.agilealliance.org
www agilealliance org
www.jeffsutherland.com
Fabián Longhitano – JAI v. 2.0

27. Muchas gracias!!
Fabián Longhitano
flonghitano@gmail.com
http://mejorsoftware.blogspot.com/
http://mejorsoftware blogspot com/
Fabián Longhitano – JAI v. 2.0