Ingeniería de SoftwareProcesos Ágiles - SCRUM
Alejandro Pacheco Masdíaz
Temas
• Modelo Tradicional de Desarrollo de Software• ¿Qué es SCRUM?• Comentarios Finales
Esquema tradicional cascada
3
Ciclo de vida de software Análisis
Diseño
Construcción
Pruebas integradas
Pruebas aceptación
Despliegue
Operación y Mantenimiento
Ciclo de vida de software
Análisis DiseñoConstrucción y
Pruebas Unitarias
Pruebas Integradas
Pruebas Aceptación Despliegue Operación y
Mantenimiento
meses
Complejidad en proyectos
4
Tecnología
Requ
erim
ient
os
Claros
PocoClaros
Conocida Desconocida
Anarquía
ComplejoComplicado
ComplicadoSimple
Clasificación de complejidad en proyectos de desarrollo
• Cuando los requerimientos están muy claros y la tecnología es conocida (se tiene el expertise en la misma) el proyecto es simple.
• La dimensión “personas” agrega otro factor de complejidad.
Errores de estimación
5
• El eje horizontal contiene hitos típicos de proyectos.
• El eje vertical contiene el grado de error que se ha encontrado en estimaciones realizadas por especialistas en estimación para distintas etapas de proyectos.
• Al principio de un proyecto, la estimación está entre un 25% y 400% del valor real. Por ejemplo, un proyecto estimado en 20 semanas puede durar entre 5 y 80.
• La exactitud en la estimación depende del nivel de refinamiento en la definición del software, mientras más refinada está la definición (más a la derecha en el gráfico), más exacta es la estimación. Por lo tanto, para una etapa del proyecto, aunque se cuente con más tiempo para refinar la estimación, no se mejora la exactitud.
Cono de Incertidumbre
Hitos
Definición inicial del producto
Definición del producto
aprobada
Levantamiento
requerimientos completo
Diseño interfaz de operación
completo
Diseño detallado completo
Software aceptado
Variabilidad de la estimación
4x
0,25x
2x
0,5x
0,67x
0,8x
1,0x
1,25x
1,5x
Control Predictivo vs Empírico
6
Recomendado cuando: Se conoce y entiende cómo opera el proceso. Es posible predecir el comportamiento del proceso.
Se basa en contar con modelo definido del proceso y determinar la entrada necesaria para obtener un comportamiento dado.
Modelo definido
Recomendado cuando el proceso es demasiado complicado para el Modelo Definido.
Se basa en el monitoreo continuo del proceso y en la adaptación del control.
Empírico
ConsideracionesMétodo
El desarrollo de Software es un proceso y como tal puede ser “controlado” para obtener un resultado esperado a partir de un objetivo dado.Las técnicas para controlar procesos se pueden clasificar en dos grandes grupos: modelo definido (predictivo) y empírico:
Qué usar en Desarrollo?
7
Tecnología
Requ
erim
ient
os
Claros
PocoClaros
Conocida Desconocida
Anarquía
ComplejoComplicado
ComplicadoSimple
• Dada la naturaleza no determinística de los procesos de desarrollo de software, es más adecuado un mecanismo de control empírico, basado en el monitoreo y adaptación continua.
• SCRUM es un método empírico para gestionar proyectos de desarrollo, que da muy buenos resultados en entornos complejos.
Control Empírico SCRUM
Temas
• Modelo Tradicional de Desarrollo de Software• ¿Qué es SCRUM?• Comentarios Finales
¿Qué es Scrum?1. Scrum es un proceso empírico para gestionar y controlar el proceso de desarrollo (se
usa para gestionar proyectos complejos desde 1990).2. Scrum entrega funcionalidad de negocio cada 30 días.3. Scrum es una envoltura a prácticas ya existentes de ingeniería de software.4. Scrum permite desarrollar sistemas y productos de manera iterativa e incremental,
donde los requerimientos varían rápidamente.5. Scrum es una forma de mejorar la comunicación y maximizar la cooperación.6. Scrum es una forma de detectar y eliminar los impedimentos que aparecen cuando se
desarrollan productos.7. Scrum permite maximizar la productividad.8. Scrum es escalable a grandes proyectos.9. Scrum cumple con CMM3 e ISO 9001.
9
Actores
10
Resto (chickens)
• Stakeholders.• Otros usuarios.• Personas de otros
equipos.• Etc.
• El concepto de “cerdos” y “gallinas” viene de la diferencia entre comprometerse y participar: Cuando se elaboran huevos con tocino, la gallina participa, pero el cerdo se compromete.
Equipo Scrum (pigs)
Equipo
ProductOwner
ScrumMaster
Roles y responsabilidades
11
“Pincha y corta” en todo lo que tenga relación con los requerimientos. Define las características del producto. Gestiona las características y releases del proyecto para optimizar el ROI. Prioriza los requerimientos de acuerdo al valor para el negocio. Inspecciona los incrementos y realiza adaptaciones al proyecto. Puede cambiar los requerimientos y las prioridades en cada Sprint (ciclo).
Product Owner
Multifuncional, siete más/menos dos personas. Selecciona los objetivos de cada iteración y especifica el trabajo a realizar. Se compromete con lo que puede completar en cada iteración. Tiene la autoridad para hacer cualquier cosa dentro de las guías y estándares existentes para cumplir con los objetivos
de la iteración. Se gestiona a sí mismo. Colabora con el Product Owner para maximizar el valor para el negocio. Realiza demos del resultado del trabajo al Product Owner.
Equipo
ResponsabilidadesRol
Se asegura que el equipo es completamente funcional, productivo y que mejora la calidad. Promueve la estrecha colaboración entre todos los roles y funciones. Además, elimina impedimentos que surgen
en el proceso. Protege al equipo de interferencias externas. Se asegura que se sigue el proceso. Le enseña al Product Owner y al equipo cómo cumplir con su rol.
Scrum Master
Proceso SCRUM
12
Flujo de proceso SCRUM
Product BacklogRequerimientos priorizados que emergen en el proceso
Product Backlog seleccionado
Sprint Backlog (Tareas)
Sprint(30 días)
Producto potencialmente
Instalable en producción
Daily Scrum
Cada24h
Sprint Planning (parte 2)
SprintRetrospective
Sprint Planning (parte 1)
Sprint Review
Mejoras al proceso
Scrum Master
ProductOwner
Product BacklogSprint BacklogBurndown
Visión
Estimación de ROI, plan de releases, hitos
Planificación
ObservacionesModificaciones al Product Backlog
No hay cambios(ni duración ni entregable)
Product Owner
13
• El Product Owner es responsable de la visión de qué debe ser producido para maximizar el valor de negocio.
• El Product Owner obtiene información de los clientes, usuarios finales, equipo, managers, stakeholders, ejecutivos, expertos de la industria, etc.
• El Product Owner transforma esto en una lista simple de qué debe ser producido, priorizado en base al valor de negocio y riesgo.
• La lista es llamada Product Backlog.
Product Backlog
14
• El Product Backlog es la lista maestra de características, funcionalidades y otros trabajos requeridos, priorizados en base al valor de negocio y riesgo, a juicio del Product Owner.
• Los ítems de mayor prioridad deben ser completados por el equipo lo antes posible.
• El Product Backlog es continuamente revisado (se agregan, quitan y modifican ítems) por el Product Owner, para maximizar el éxito para el negocio de los esfuerzos del equipo.
Product Backlog
15
Se registran y priorizan todos los requerimientos Funcionales y No Funcionales
Equipo
16
• El tamaño ideal en Scrum es 7 +/- 2.
• El equipo es cross-functional. Tiene todas las habilidades para producir un producto terminado (diseñadores, codificadores, testers, etc.) y todos contribuyen basados en sus competencias, más que en el cargo.
• El equipo es auto-organizado y auto-gestionado. Es responsable de comprometerse y auto-gestionarse para cumplir el objetivo (o acercarse lo más posible). Scrum provee herramientas para ayudar a esto.
Sprint
17
• El equipo trabaja en un periodo fijo de tiempo, llamado Sprint.
• Los Sprints duran entre 1 y 4 semanas.
• Los Sprints ocurren uno después de otro, sin down-times entre ellos. Es muy importante trabajar de manera sostenida.
• El equipo y el Product Owner deciden con anticipación el largo de los Sprints.
Sprint Planning
18
• Antes de cada Sprint, el equipo selecciona con qué requerimientos del Product Backlog se comprometerá para el final del Sprint, empezando por los de mayor prioridad.
• El equipo crea un plan a nivel de tareas para cumplir el compromiso. Esta lista de tareas se llama Sprint Backlog.
• El equipo trabaja para crear una asignación inicial de tareas y compara el total de horas estimadas con el total de horas disponibles, para asegurarse que el compromiso es razonable.
• Cada uno de los integrantes del equipo participa, independiente de su experiencia.
Sprint Planning (2)
19
• Es muy importante que el Product Owner no presione al equipo para que se comprometa con más de lo que ellos encuentran razonable. Si hay presión, el equipo se sobre-comprometerá y los requerimientos no se completarán o tendrán baja calidad o el equipo se “quemará” luego de varios sprints.
• Muchos managers al principio se preocupan de que el equipo se sub-comprometa. En realidad, a la mayoría de los equipos les ocurre lo contrario: les puede tomar varios sprints para aprender a no sobre-comprometerse.
Modificaciones al Sprint
20
• Durante el sprint, lo que el equipo comprometió a entregar no cambia y el final de sprint no cambia.
• Esto permite que el equipo haga y mantenga compromisos, enfoca al equipo y provee estabilidad durante el Sprint. Además, entrena al Product Owner a pensar claramente en lo que está en el Product Backlog.
• Aunque el Product Owner no puede realizar cambios en el sprint, sí puede realizar todos los cambios que estime conveniente en el Product Backlog antes de empezar el siguiente Sprint.
Daily Scrum
21
• Cada día, el equipo tiene una reunión de 15 minutos para actualizar entre ellos el progreso y exponer impedimentos. Normalmente, estas reuniones se realizan de pie, para fomentar la brevedad.
• Cada miembro del equipo expone 3 cosas: qué hizo entre la reunión anterior y ésta, qué realizará entre esta reunión y la siguiente, y qué impedimentos tiene para completar su trabajo.
• El Scrum Master anota los impedimentos y luego ayuda a resolverlos.
• Otros (chickens) pueden asistir a la reunión, pero no hablan. Esta reunión no es para monitorear al equipo.
Control de avance
22
• Cada día, el equipo actualiza tablas y gráficos simples que hacen visible cómo están progresando hacia el cumplimiento de los objetivos del Sprint.
• El Sprint Backlog lista todas las tareas y las horas remanentes para cada una. El gráfico de quemado de horas muestra el total de horas remanentes para completar todas las tareas.
• Estas tablas y gráficos ayudan a que el equipo se auto-gestione y entreguen lo que se comprometieron para el final del Sprint.
Sprint Backlog
23
El Sprint Backlog evoluciona dentro del Sprint.Para cada tarea del Sprint Backlog, se registran diariamente las horas faltantes para completar la tarea (ETC: Estimated To Complete).
Quemado (burndown) de horas
24
Horas estimadas que faltan para terminar las tareas del Sprint Backlog.
Quemado teórico de horas. Se asume un consumo uniforme.
Scrum Master
25
• El Scrum Master es un nuevo rol. Puede ser cumplido por un Jefe de Proyecto o miembro del equipo.
• El Scrum Master sirve al equipo (ayudándoles a eliminar los impedimentos que se detectan), protege al equipo (de cualquier interferencia externa) y enseña y guía acerca del uso de Scrum.
• Sin un Scrum Master, el equipo tiene un alto riesgo de fracasar.
Producto
26
• El objetivo del equipo es completar al 100% lo que ellos se comprometieron, idealmente un incremento de un producto potencialmente “vendible” o instalable en producción.
• Debe cumplir el concepto de “Done” acordado con el Product Owner. Para software, significa funcionalidad que ha sido diseñada, completamente implementada y completamente testeada, sin mayores defectos.
• Muy pocos equipos pueden producir un producto potencialmente vendible al final del Sprint 1, pero a medida que avanzan se acercan más a este objetivo.
Sprint Review
27
• Al final del Sprint, el Product Owner, Equipo, Scrum Master y Stakeholders se reúnen para ver una demo de lo que el equipo ha producido.
• El Product Owner obtiene feedback de todos con el objetivo de mejorar lo que se construyó.
• El feedback es incorporado al Product Backlog.
• Si un producto no cumple con el concepto de “Done”, entonces no se muestra en esta reunión.
Sprint Retrospective
28
• El equipo, Product Owner y Scrum Master se reúnen al final de cada Sprint para revisar la forma de trabajo y ven maneras de mejorar la eficiencia.
• Éste es un mecanismo de mejora continua donde se detectan problemas y se resuelven o escalan.
Tiempos
29
Flujo de proceso ScrumSprint (30 días)
PlanningSprint Planning
(8h)Daily work
(1 día)
Daily Scrum(15 min)
Sprint Review(4h)
Sprint Retrospective
(4h)
VisiónEstimación de ROI, plan de releases, hitos
Temas
• Modelo Tradicional de Desarrollo de Software• ¿Qué es SCRUM?• Comentarios Finales
Desarrollo ágilDesarrollo cascada
Cambiando el paradigma
31
Desarrollo cascada versus desarrollo ágil
Cumplimiento del planMedición de éxito Respuesta al cambio, código funcionando
Comando y controlCultura de gestión Liderazgo, colaborativo
Grande y al principioRequerimientos y Diseño
Continuo, emergente, just-in-time
Codificar todos los requerimientos, probar despuésCodificación Codificación y pruebas unitarias,
entrega periódica
Grandes, planificadas, al finalPruebas y QA Continuo, concurrente, probar temprano
Pert, Gantt, recursos y plazos estimadosPlanificación Planificaciones de 2 niveles, alcance
estimado
Cambiando el paradigma
32
Dirigido al Plan (tradicional) versus Dirigido al Valor (ágil)
Dirigido al Plan
Dirigido al
Valor
Estimado
Fijo
RequerimientosRecursos Fecha
Requerimientos Recursos Fecha
Cascada/Tradicional Ágil
• En el método tradicional, los Requerimientos son fijos y se estiman los recursos y la fecha (plazo). Está orientado a cumplir un plan.
• En los métodos ágiles los recursos y la fecha (plazo) son fijos y se estiman los requerimientos que maximizan el valor al negocio y que pueden ser implementados en esos plazos con esos recursos.
Scrum es un proceso continuo
33
Requeri-
mientos emergentes
Sistema
emergente
Releases
34
SCRUM SCRUM
Scrum junto a otras prácticasScrum sirve de envoltorio a otras prácticas de Ingeniería de Software
Otras prácticas de desarrollo,
por ejemplo XP.
Test Driven Programming
Proceso de Desarrollo para proyecto específico
• Scrum se puede complementar con otras prácticas de desarrollo, siempre que no quiebren el proceso de Scrum. Por ejemplo: integración continua, test driven programming, pair programming, no overtime, user stories, etc.
• El conjunto resultante conforma un proceso de desarrollo robusto: control adaptivo y prácticas para reducir riesgo y aumentar calidad.
Integración continua, pair programming, etc.
Velocidad
35
Consumo de ítems del Product Backlog por sprint
Ítems remanentes del Product Backlog, a medida que avanzan los Sprints
Proyección lineal de la velocidad del equipo
Se puede proyectar cuándo se terminarán los ítems del Product Backlog
Proyecto SCRUM
Proyecto tradicional
Planificación continua
36
Planificación Desarrollo Estabilización
P P D E P D E P D E P D E P D E
“Done”• El equipo y el Product
Owner definen el concepto de “Done”.
• Ítems del Product Backlog que no estén “done” no deben ser mostrados en Sprint Review.
37
Ejemplo de “done”:• Diseñado.• Refactorizado.• Codificado.• Revisión de código.• Revisión de diseño.• Pruebas Unitarias.• Pruebas Integradas.• Pruebas de carga.• Pruebas de seguridad.• Pruebas de aceptación.• Documentado.
Proyecto Scrum
Proyecto tradicional
Concepto del “Done”
38
Done
Proceso de desarrollo tradicional (Cascada) Done
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 … Sprint N
Done Done Done Done Done Done Done Done
Múltiples equipos de desarrolloEscalabilidad de Scrum Daily Scrums
Sprint 1
Sprint 2
Sprint 3Scrum of Scrums
39
Descomposición del trabajo
40
• Trabajo es descompuesto por objetivos.
• Se reporta para hacer seguimiento del progreso en alcanzar objetivos.
S1
S1.1 S1.2 S1.3
S131
S132
S1321
S1322
S1323
S133
S134
S1341
S1342
S1.4 S1.5 S1.6
Interacción entre equipos
41
Integration Scrum team 1
Equipo
ProductOwner
ScrumMaster
Integration Scrum team 1.1
EquipoProductOwner
ScrumMaster
Integration Scrum team 1.2
EquipoProductOwner
ScrumMaster
Preguntas