ANALISIS DE DISEÑO

DE SISTEMAS

SCRUM y el desarrollo ágil

ING. MBA. ALICIA TORRES CONTRERAS
Agenda de la Presentación
 Desarrollo Ágil
 Orígenes de SCRUM
 Definición de SCRUM
 Descripción - Marco de Trabajo de SCRUM
 Roles
 Reuniones
 Artefactos
 Escalamiento (Scrum de Scrum)
 Ventajas y Desventajas
 Conclusiones y Recomendaciones
Desarrollo Ágil - Principios

SIMPLICIDAD VALENTIA

COMUNICACION RECICLADO
CONTINUO
Desarrollo Ágil - Principios
Desarrol Dialy
Interca
COMUNICAC lo de stand
mbio de
ION proyect up
ideas
os meeting
Cuidado
Interfac
SIMPLICIDA en
es
D desarrol
simples
lo
Analisis
Asumir
VALENTIA colegiad
riesgos
o
Comunic Cliente
RETRO - ión involucr
ALIMENTACI
ON entre ado
partes siempre
Desarrollo Ágil - Principios
 Satisfacción del cliente  Cooperación cercana y
en base a la entrega diaria entre personas del
rápida y frecuente de negocio y
software desarrolladores
 Entregas frecuentes del  Se aprovecha la mejor
software (semanas en forma de comunicación
lugar de meses) (cara a cara)
 El software es la medida
 Los proyectos son
de progreso. ejecutados por
individuos motivados
 Incluso cambios tardíos  Enfoque en la excelencia
en los requerimientos
técnica y el buen diseño
son bienvenidos.
 Simplicidad
 Equipos auto–
organizados
 Manifesto de Desarrollo Agil

Individuos
Individuos ee sobr Procesos
Procesos yy
interacciones
interacciones e herramientas
herramientas
Software
Software que
que sobr Documentación
Documentación
funciona
funciona e exhaustiva
exhaustiva
Colaboración
Colaboración sobr Negociación
Negociación de
de
con
con el
el cliente
cliente e contratos
contratos
Responder
Responder Seguimiento
Seguimiento
sobre
ante
ante el
el cambio
cambio de
de un
un plan
plan

Fuente: [Link]
Desarrollo Ágil – Metodologías

 Agile Modeling  Extreme

 Agile Unified Process programming (XP)
(AUP)  Feature Driven
 Agile Data Method Development (FDD)
 DSDM  Getting Real
 Essential Unified  Open Unified Process
Process (EssUP) (OpenUP)
 Scrum
Desarrollo Ágil - Prácticas
 Test Driven Development (TDD)
 Behavior Driven Development (BDD)
 Desarrollo guiado por pruebas.
 Cliente presente.
 Integración continua.
 Refabricación sin piedad.
 Diseño simple.
 Propiedad colectiva del código y
convenciones del mismo.
Scrum
SCRUM - Orígenes
 Hirotaka Takeuchi e Ikujiro
1986
Nonaka. “The New Product
Development Game”.
 Ken Schwaber puso en práctica
90 ’s en Advanced Development
Methods.
 Jeff Sutherland primero en
denominarla formalmente
1995 Scrum.
 Sutherland y Schwaber, durante
el OOPSLA (Object Oriented
Programming, Systems,
languages and applications),
2001 presentación pública de la
metodología.
 Schwaber y Mike Beedle. “Agile
SCRUM - Definición

 Metodología que soporta la flexibilidad en el

proceso de software.

 Tiene un alto grado de tolerancia a los cambios

del ambiente (requerimientos).

 Asume que el análisis, diseño y desarrollo en la

fase SPRINT son impredecibles.

Hirotaka Takeuchi, Ikujiro Nonaka, 1986 The New New Product Development game
 SCRUM – Fases y Marco de
Trabajo
DAILY SCRUM
MEETING

24 HORAS
POTENTIALLY
SHIPPABLE
PRODUCT SPRINT PRODUCT
BACKLOG BACKLOG INCREMENT
2–4
SEMANAS

SPRINT
SPRINT PLANNING SPRINT REVIEW
RETROSPECTIVE
MEETING MEETING
MEETING

PLANNING & ARCHITECTURE SPRINT CLOSURE

Imagen disponible en [Link]/scrum y adaptado por el grupo

 SCRUM – Fases y Marco de
Trabajo
DAILY SCRUM
MEETING

PLANNING & POTENTIALLY

24 HORAS

ARCHITECTURE
SHIPPABLE
PRODUCT SPRINT PRODUCT
BACKLOG BACKLOG INCREMENT
• 2SEMANAS
Definición del release
–4

del
producto

• Estimaciones, planes
y
costos SPRINT
SPRINT PLANNING SPRINT REVIEW
RETROSPECTIVE
MEETING MEETING
MEETING

PLANNING & ARCHITECTURE SPRINT CLOSURE

Imagen disponible en [Link]/scrum y adaptado por el grupo

 SCRUM – Fases y Marco de
Trabajo
DAILY SCRUM
MEETING
SPRINT

• El producto es 24 HORAS
desarrollado, POTENTIALLY
SHIPPABLE
revisado,
PRODUCT SPRINT PRODUCT
INCREMENT
BACKLOG BACKLOG
probado y 2–4
SEMANAS
ajustado
• Liderado por
Scrum
Master
• No se aceptan
cambios durante SPRINT PLANNING SPRINT REVIEW
SPRINT
MEETING RETROSPECTIVE
su MEETING
MEETING

desarrollo
PLANNING & ARCHITECTURE SPRINT CLOSURE
• Intervienen uno
o más
Imagen disponible en [Link]/scrum y adaptado por el grupo
equipos de
 SCRUM – Fases y Marco de
Trabajo
DAILY SCRUM
MEETING

CLOSURE
24 HORAS
POTENTIALLY
SHIPPABLE
PRODUCT SPRINT PRODUCT
INCREMENT
BACKLOG
•
BACKLOG
Documentación 2–4
SEMANAS
final
• Documentación
de pruebas
completas
• Entrega del
SPRINT
producto
SPRINT PLANNING SPRINT REVIEW
MEETING
RETROSPECTIVE
MEETING MEETING

PLANNING & ARCHITECTURE SPRINT CLOSURE

Imagen disponible en [Link]/scrum y adaptado por el grupo

SCRUM -
Características
 Las fases de planificación y cierre consisten de
procesos bien definidos.
 La fase Sprint es un proceso empírico.
 Los Sprints son no-lineales y flexibles.
 El producto se construye en una serie de
“Sprints”.
 El proyecto está abierto hasta la fase de cierre.
 Equipos auto-organizados.
 Al final de cada Sprint, se decide liberar o
seguir mejorando el producto.
Scrum - Marco de Trabajo
Roles
•Product
owner
•ScrumMaster
•Team Reunione
s Sprint planning
•
•Daily scrum
meeting
•Sprint review
•Sprint Artefacto
retrospective
s Product backlog
•
•Sprint backlog
•Burndown charts
Scrum - Marco de Trabajo
Roles
•Product
owner
•ScrumMasterReunione
•Team
s Sprint planning
•
•Daily scrum
meeting
•Sprint review
•Sprint Artefacto
retrospective
s Product backlog
•
•Sprint backlog
•Burndown charts
El Product Owner
 Representa la voz del cliente
 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 (Sprint) si es necesario
 Acepta o rechaza los resultados del
El Scrum Master
 Encargado de la gestión del proyecto
(Facilitador)
 Responsable de promover los valores y
prácticas de SCRUM
 Remueve impedimentos que impiden que el
equipo alcance el objetivo del Sprint /
Proyecto
 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
El Team
 Típicamente de 6 a 8 personas
 Multi-funcional: programadores, testers,
analistas, diseñadores, etc.
 Normalmente asignados a tiempo
completo
 Los equipos son auto-organizativos; no
existen títulos pero a veces se utilizan de
acuerdo a la organización
 Solo puede haber cambio de miembros
entre los Sprints
 Son los responsables de traducir los
requerimientos en funcionalidad en cada
Scrum Framework
Roles
•Product
owner
•ScrumMaster
•Team Reunione
s Sprint planning
•
•Daily scrum
meeting
•Sprint review
•Sprint Artefacto
retrospective
s Product backlog
•
•Sprint backlog
•Burndown charts
Al inicio de cada iteración el Product
Owner y el Scrum Team se reúnen para
definir los objetivos, el Sprint Backlog y el
Plan para el siguiente Sprint. Esta reunión
se denomina SPRINT PLANNING
MEETING
Sprint Planning Meeting
Capacidad
Capacidad
del
del Equipo
Priorización
Equipo Objetivo
Objetivo
• Analizar y evaluar los
Product
Product elementos del Product del
del
Backlog
Backlog Backlog a desarrollar Sprint
Sprint
Actualizad
Actualizad • Seleccionar el objetivo del
oo Sprint
Condicion
Condicion
es
Planificación
es del
del
Negocio
Negocio • Decidir como alcanzar el
objetivo del Sprint (diseño)
Sprint
Sprint
Desempe
Desempe
ño
ño en
en • Crear el Sprint Backlog Backlog
Backlog
anteriores
anteriores (tareas de la iteración) en
Sprints
Sprints base a los temas del Product
Backlog Plan
Plan del
del
Feedback
Feedback
del
• Estimar Sprint Backlog en Sprint
Sprint
del ultimo
ultimo horas
Sprint
Sprint
• Auto asignar tareas.
Diariamente el equipo se junta para una
reunión minuciosa denominada DAILY
SCRUM
Daily Scrum
 Dura 15 minutos. Todos los participantes 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
 Todo el equipo y de a uno deben responder:
1
¿Qué
¿Qué hiciste
hiciste ayer?
ayer?
2
¿Qué
¿Qué vas
vas aa hacer
hacer hoy?
hoy?
3
¿Hay
¿Hay obstáculos
obstáculos en
en tu
tu camino?
camino?
 El propósito de la reunión es sincronizar el trabajo
de todos los miembros del equipo
Al final de cada Sprint se presenta al Product
Owner y demás Stakeholders el trabajo realizado
(incremento de producto). Esta reunión se
denomina SPRINT REVIEW MEETING
Sprint Review Meeting
 Participan en la reunión el equipo de
proyecto, el ScrumMaster, el Product Owner,
y otros Stakeholders
 Se revisa que trabajado se completó y cual
no se finalizó en el Sprint
 Se presenta solo el trabajo completado
(“demo")
 Se define un límite de 4 horas
 Caracter Informal
 Al finalizar se actualiza y vuelve a priorizar
el Product Backlog
 El Product Owner decide si la funcionalidad
presentada cumple con los objetivos del
Con el objetivo de identificar que cosas se pueden
cambiar para hacer el trabajo más agradable y
productivo en las siguientes iteraciones se lleva a
cabo al final de cada Sprint una reunión
denominada SPRINT RETROSPECTIVE MEETING
Sprint Retrospective
 Participanen la reunión el equipo de
proyecto, el Scrum Master, el Product Owner
y posiblemente clientes y otros satkeholders
 Se busca una duración de 15 a 30 minutos

 Se realiza al finalizar cada sprint

 Todos responden 2 preguntas:
Que cosas hicimos bien?
Que cosas podemos mejorar?
 Permiteal equipo evolucionar
continuamente, mejorando durante el
proyecto
Scrum framework
Roles
•Product
owner
•ScrumMasterReunione
•Team
s Sprint planning
•
•Daily scrum
meeting
•Sprint review
•Sprint Artefacto
retrospective
s Product backlog
•
•Sprint backlog
•Burndown charts
Product Backlog

 Una lista de todos los

trabajos deseados en el
proyecto
 Cada requerimiento
tiene un valor asignado
 La priorización es
definida por el Product
Owner y es el único que
la puede cambiar
 Evoluciona segun las
condiciones del negocio
y/o tecnología
product
product  Actualizada y
repriorizada al
backlog
backlog comienzo de cada
Sprint
 Es visible a todos
Product Backlog - Ejemplo
Id Descripción de Priorida Estimación Criterio de Observación
la d (Hrs) Validación
Funcionalidad
1 Depósito 30 5 Entrar, abrir página Necesita un diagrama
de depósito, depositar UML. No preocuparse
US$ 10, ir a página de por encriptación aún.
balance y comprobar
que se ha
incrementado en US$
10.
2 Ver tu historial 10 8 Entrar, ver Utilizar paginación
de transacciones transacciones. para no hacer
Realizar un depósito consultas muy
de US$ 10. Ir a grandes a la [Link].
transacciones y Diseño similar a la
comprobar que se ha página de usuario.
actualizado con el
nuevo depósito.
Otros Campos que se pueden adicionar son:
 Categoría, Componentes, Solicitante, Bug
Trucking Id, Persona Asignada, Nro del Sprint en
el que se realiza, Módulo del sistema al que
pertenece, Etc.
Product Backlog - Ejemplo

Fuente: [Link]
Sprint Backlog
 Describe cómo el equipo va a implementar
los requisitos durante el siguiente sprint
 Las tareas se dividen en horas con ninguna
tarea de duración superior a 16 horas. Si una
tarea es mayor de 16 horas, deberá ser
dividida en mayor detalle
 Las tareas nunca son asignadas, son
tomadas por los miembros del equipo del
modo que les parezca oportuno
 La estimación del trabajo restante es
actualizada diariamente
 Cualquier miembro del equipo puede añadir,
borrar o cambiar el Sprint Backlog
 Actualizar el trabajo restante a medida de
que se cuenta con más información
Sprint Backlog

 Lista inicial de estas tareas creada en la

segunda parte del Sprint Planning
Meeting.
 Define el trabajo o las tareas que
estarán listas e la próxima versión.
Sprint Backlog (ejemplo)

Fuente: [Link]
Sprint Burndown Chart

 Muestra la cantidad de trabajo restante a través

del tiempo
 Cantidad de trabajo restante vs. el progreso del
equipo en la reducción de este trabajo.
Scrum of Scrums

 Un equipo Scrum típicamente está formado

por 6-10 individuos. Jeff Sutherland (uno de
los fundadores de esta corriente) ha escalado
Scrum hasta más de 500 personas trabajando
en simultaneo.
Scrum of Scrums

No se mencionan nombres
15 Minutos

Cada participante responde cuatro preguntas:

¿Qué ha hecho su equipo desde la última reunión?
¿Qué hará su equipo hasta nuestra próxima reunión?
¿Existe algo que impida o complique el avance de su equipo?
¿Esperan trabajar algo que pueda afectar el resultado de otro de
los equipos?
necesario
El tiempo

Se resuelven problemas y discuten temas incluidos en el Backlog

Scrum of Scrums
Los temas específicos sobre los cuales se
concentra el SoS Meeting:
Dependencias entre módulos
Necesidad de compartir recursos entre
módulos/equipos (no es una práctica
recomendable pero la realidad lo exige)
Confrontar cuestiones que se escalan de niveles
inferiores
Identificar Riesgos
Compartir lecciones aprendidas y mejores
prácticas
Modelos Tradicionales vs.
Ágiles

Modelos Tradicionales
Modelos Agiles
 Poca tolerancia al cambio  Los
cambios son la
 Comunicaciónbasada en norma
la documentación  Comunicación Cara a
 Comunicación con el cara
cliente solo al inicio del  Cliente es parte del
proyecto
equipo
 Metodología impuesta por  Metodología decidida por
la empresa
el equipo
 Mayor número de  Menor número de
artefactos y trabajadores
artefactos y trabajadores
Modelos Ágiles

Configuration Mangement Journal – 2006

“La ingeniería tiende a establecer una separación entre el
diseño y la construcción, asumiendo que la construcción
es la parte que concentra la mayor cantidad de esfuerzo y
es un proceso predecible. Esta separación no es útil
cuando se trata de desarrollar software”.

(Ken Schwaber creador del modelo SCRUM)

Ventajas de usar Scrum

 Capacidad de aceptar modificaciones sin influir en el

desarrollo. El progreso se logar aun cuando los
requerimientos no son estables
 Maximiza el valor obtenido por el negocio en base a
una correcta priorización de requerimientos y la
reducción del riesgo
 Le otorga visibilidad al proyecto
 Incrementa la productividad de los equipos de
desarrollo.
 Ofrece Flexibilidad
 Propicia la transmisión de conocimientos entre los
desarrolladores
Ventajas de usar Scrum

 Permite el control de procesos de desarrollo de

productos complejos.
 Busca establecer una Propiedad compartida entre los
miembros del equipo.
 Es escalable y permite trabajar con equipos grandes y
pequeños.
 Desarrolla una relación de confianza con el cliente.
Desventajas de usar Scrum

 No es efectivo para proyectos pequeños

 Es difícil de implementar cuando los miembros del
equipo de proyecto no están en las mismas
instalaciones.
 El entrenamiento formal es requerido.
 Siempre existe resistencia al cambio. Incluso la
Gerencia debe estar dispuesta a plantear cambios
para garantizar el éxito del equipo de proyecto.
 Algunos trabajadores no se sienten cómodos con la
responsabilidad que Scrum les obliga a asumir.
Conclusiones y
Recomendaciones

 SCRUM es una metodología de desarrollo flexible y

adaptativa que propicia una cultura de la
comunicación, de difusión del conocimiento y de
conformación de equipos efectivos dentro de las
Organizaciones.
 Reconoce el valor de los procesos formales pero hace
prevalecer la interacción entre individuos, procesos y
herramientas, piezas de software utilizable,
colaboración con el cliente y la respuesta al cambio
 El desarrollo con SCRUM es rápido y exige pruebas e
integración continuas, buenas prácticas de
codificación, etc. El uso de otros métodos como XP
pueden ayudar a mantener la calidad.
Conclusiones y
Recomendaciones

 SCRUM se concentra en que puede construirse y como

resolver problemas con los recursos disponibles.
 Bajo la guía de SCRUM se usan equipos multi-
funcionales que analizan los requerimientos desde
diferentes ópticas para incrementar la calidad del SW.
 El esquema de equipo plantea objetivos comunes.
Cada miembro debe realizar lo que pueda para
alcanzar el mejor incremento posible. Rompe la rigidez
de los roles que platea el desarrollo tradicional.
 SCRUM invierte menos tiempo planeando y definiendo
tareas y se centra más en el esfuerzo con el equipo de
desarrollo.
Cuando usar Scrum

 Los requerimientos no están claramente definidos

 El trabajo es entregado de manera incremental
 El trabajo es medido y controlado
 La productividad es maximizada en base a la
implementación de tecnologías conocidas
 La organización está comprometida con el proyecto y
está dispuesta a hacer cualquier cosa para asegurar
su éxito
 El proyecto es importante y nadie tiene confianza de
que un esquema de trabajo existente dará resultado
 La gestión y el control del proyecto tiene un enfoque
empírico
Cuando NO usar Scrum

 No existe un ambiente flexible

 La cultura de la organización no propicia este tipo de
ambientes de desarrollo
 Los equipos de desarrolladores son más de 10
 El costo es una variable muy sensible
 No existe soporte de la Gerencia
 No hay participación del cliente
 No existe entrenamiento formal
Gracias