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