1. Presentación Marta Padilla2. Desarrollo Agile3. Agile Manifesto4. Agile y SCRUM5. Elementos de SCRUM

› Equipo y roles› Iteraciones fijas – Sprints› Reuniones› Artifacts

6. Preguntas

Background› Ingeniera superior en informática› Project Manager con base técnica› Experiencia internacional

Project manager en un entorno de desarrollo de software en GB› Involucrada en la definición y implantación de metodologías

de desarrollo y project management› Definición

Miembro del steering group para definir la implantación concreta en varios equipos de desarrollo

› Implantación Doble rol: SCRUM Master / Project Manager Coach para la posterior implantación en otros equipos

Consultora a través de empresa propia, fastzink› Project Management› Procesos, técnicas y metodología de desarrollo de software

Certificaciones: PMP Certified SCRUM Master

Grupo de tecnologías de desarrollo de software basadas en una serie de principios comunes:

› Desarrollo iterativo› Equipos que se auto-organizan› Equipos que priman la colaboración› Procesos adaptables con capacidad de respuesta al cambio, etc.

“Mientras que valoramos los conceptos de la derecha…

Personas e interacciones

Software que funciona

Colaboración con el cliente

Responder al cambio

Procesos y herramientas

Documentación comprensible

Negociación del contrato

Seguir el plan

valoramos AÚN MÁS los de la izquierda”

El término “Agile Development” se acuñó en 2001, junto con el llamado “Agile Manifesto”:

SCRUM es una metodología de desarrollo de software concreta que se engloba dentro de las metodologías ágiles (“Agile”).

No es la única: Existen otras metodologías como DSDM, XP, Evo, etc.

Metodologias ágiles

SCRUMDSDM

XP

SCRUM no define procesos y técnicas para desarrollar productos, sino que es un framework (esqueleto) que sienta unas bases en las cuales enmarcar procesos y técnicas de desarrollo concretas.

SCRUM…

Está basado en la teoría de control de procesos empíricos

Es iterativo e incremental Optimiza la predictibilidad y control de

riesgos

Se basa en 3 principios:

Transparencia: Todos los aspectos que influencian el resultado deben de ser visibles al cliente.

Inspección: Todos los aspectos del proceso deben de ser inspeccionados frecuentemente para detectar variaciones inaceptables en el mismo o en el producto resultante.

Adaptación: Si se detectan variaciones inaceptables, se deben tomar medidas para adaptar dichos procesos o dicho resultado.

Más adelante veremos cómo los “componentes” de SCRUM hacen posible que estos 3 principios se cumplan en todo momento.

Equipo y roles Iteraciones fijas – Sprints Reuniones

› Reunión de Release Planning› Reunión de Sprint Planning› Daily SCRUM (SCRUM diario)› Reunión de Sprint Review› Reunión de Sprint Retrospective

Artifacts› Product Backlog › Sprint Backlog › Gráficos de Release / Sprint Burndown

Equipo y Roles› En SCRUM existen 3 roles distintos:

SCRUM Master: Responsable de asegurar que la metodología SCRUM se entiende y se sigue.

Product Owner: Responsable de maximizar el valor de negocio de lo que el equipo hace.

Equipo: Los que realizan el trabajo (desarrolladores).

› Una observación acerca de cerdos y gallinas…

El SCRUM Master es responsable de asegurar que el equipo se adhiere a los valores de SCRUM, a sus practicas y a sus reglas.

Ayuda no sólo al equipo, sino a la organización en general a adoptar SCRUM.

Guía al equipo de SCRUM , conduciéndolo a ser más productivo y a crear productos de más alta calidad.

Enseña al equipo a ser más autosuficiente. El SCRUM Master no es el jefe de proyecto a

la manera tradicional, dictando las tareas explícitamente: El equipo se organiza por sí mismo en gran parte.

El Product Owner es el único responsable del Product Backlog y de asegurar el valor comercial del trabajo que el equipo realiza.

Mantiene el Product Backlog y asegura que sea visible a todo el mundo.

Gracias a él, todo el mundo sabe que tareas tienen la máxima prioridad, con lo que todos las personas implicadas pueden saber en qué se está trabajando.

Es una sola persona (no un comité).

Para que el Product Owner tenga éxito, toda la organización debe respetar sus decisiones:› Nadie tiene permiso para mandar al equipo trabajar con diferentes prioridades.

› De igual manera, el equipo no puede permitir escuchar a otras personas en la organización.

› Por eso es tan importante que el Product Backlog sea visible y que exista un único Product Owner.

Cada Sprint, el equipo transforma el Product Backlog en un incremento del producto final que esta potencialmente listo para una Release.

Los miembros del equipo deben de tener las habilidades necesarias para crear dicho incremento.

Aunque sean especialistas en ciertos aspectos (por ejemplo, desarrollador, testeador, administrador de red, etc.), deben de tener la actitud correcta y cuando sea necesario salir de su “zona cómoda”, ser capaces de hacerlo.

Los equipos se auto-organizan: Nadie (ni tan sólo el SCRUM Master) le dice al equipo cómo transformar el Product Backlog en un incremento del producto final que esta potencialmente listo para una Release; el equipo lo decide por sí solo. Las sinergias que se producen en el proceso aumentan la eficiencia y efectividad del equipo.

El tamaño ideal para un equipo es de siete personas (más – menos dos). Cuando hay menos de cinco, no hay mucha interacción y la productividad se resiente. Cuando el equipo es más grande, es muy complicado de manejar bajo el framework SCRUM.

Iteraciones fijas: Sprint› Es el “corazón” de SCRUM. › Dura de 1 mes a 15 días.› Duración fija durante la vida del proyecto

› Todos los Sprints tienen el mismo ciclo de vida.

› Todos los Sprint acaban con un incremento del producto final que está potencialmente listo para una Release.

› Cada sprint empieza inmediatamente después del anterior.

Durante el Sprint el SCRUM Master tiene que asegurar que no se realicen cambios que afecten a los objetivos del Sprint. La composición del equipo y la calidad del trabajo hecho permanecen constantes durante el Sprint.

Los Sprints consisten en: › Reunión de Sprint Planning› Desarrollo (trabajo) + SCRUM diario› Reunión de Sprint Review› Reunión de Sprint Retrospective

En SCRUM, el horizonte temporal del proyecto se reduce a un mes o a quince días (dependiendo de la duración del Sprint); por eso es adecuado para los productos complejos donde un “horizonte temporal más largo sea demasiado peligroso.

La predictibilidad del proyecto tiene que ser controlada al menos cada mes.

Sólo el Product Owner puede cancelar un Sprint.

Sólo si el objetivo del Sprint pasa a ser obsoleto. Por ejemplo, por un cambio de estrategia de la compañía, del mercado, etc. Debido a la corta duración del Sprint, casi nunca se da el caso de que deba cancelar un Sprint.

Las cancelaciones son “traumáticas” y consumen tiempo – Por eso sólo deben de ocurrir en las circunstancias mencionadas anteriormente.

Reuniones› Reunión de Release Planning› Reunión de Sprint Planning (kickoff)› Daily SCRUM (SCRUM diario)› Reunión de Sprint Review› Reunión de Sprint Retrospective

En la reunión de Release planning se establece el plan y los objetivos de la Release, además de decidir la estrategia que el equipo SCRUM y el resto de la organización van a seguir.

Básicamente se trata de contestar a las siguientes preguntas:› ¿ Cómo podemos transformar el objetivo en un producto de calidad, de la mejor manera posible ?

› ¿ Cómo podemos dejar al cliente satisfecho y conseguir un buen retorno de nuestra inversión ?

En la mayoría de organizaciones ya existe un proceso para planear Releases, en el que se definen los objetivos generales, que permanecen inalterables durante la vida del proyecto. En el caso de SCRUM, se suele utilizar 15-20% del tiempo que se utiliza en estos otros casos más tradicionales. Esto es porque se realiza planificación just-in-time: En cada Sprint y en cada SCRUM diario.

Si nos fijamos en los números finales, seguramente finalmente se pasará más tiempo planeando en esta nueva forma de planificación que en la tradicional.

También llamada “reunión de kick-off” para el Sprint, es en esta reunión que se planea la iteración. Se limita a 8 horas por Sprint, dividida en dos partes de 4 horas:› Durante la primera parte (el ¨Qué”) se decide que puntos del Product Backlog se van a trabajar en el Sprint El Product Owner presenta el Product Backlog priorizado y junto con el equipo se decide los puntos para el Sprint. Además del Product Backlog, se utilizan como inputs la capacidad y la productividad pasada del equipo.

› Durante la segunda (el “Cómo”), el equipo decide cómo se van a desarrollar dichos puntos.

› Son (generalmente) 4 horas en las que el equipo discute y decide cómo transformaran l os puntos descritos en el PBL en un incremento del producto listo para el cliente.

› Normalmente se empieza diseñando el trabajo, y al hacerlo, se identifican las tareas. Estas tareas son piezas de trabajo necesarias para convertir las descripciones abstractas del PBL en el producto final. Esta lista de tareas es lo que vamos a llamar Sprint Backlog (SBL).

El Sprint Review tieen lugar al final del Sprint. Limitado a 4 horas para Sprints de 1 mes, en general se estima que no supere el 5% del tiempo del Sprint.

Se discute con los actores involucrados en el proyecto (stakeholders) sobre lo que se ha realizado, y se discute sobre la dirección del proyecto en un futuro inmediato. Es una reunión informal en el que se presenta la funcionalidad realizada hasta el momento y en el que se fomenta la colaboración.

En general, se sigue un patrón del tipo:› El Product Owner identifica lo que se ha hecho y lo que no durante el Sprint.

› El equipo discute lo que ha ido bien y los que no, los problemas y cómo se solucionaron.

› El equipo realiza una demostración del trabajo hecho y contesta las posibles preguntas de los stakeholders presentes.

› El Product Owner discute el PBL actual y comenta los próximos milestones teniendo en cuenta las actuales métricas de velocidad del equipo.

› En general, el Sprint Review es muy útil para la próxima reunión de Sprint Planning.

Tiene lugar después del Sprint Review y antes del próximo Sprint Planning, estimado en 3 horas.

En él, el SCRUM Master alienta al equipo a revisar, dentro el framework SCRUM, los procesos de desarrollo y las prácticas actuales, para hacer que el próximo Sprint sea más productivo y más efectivo para todos.

El principal propósito de la reunión Retrospective es ver cómo fue el último Sprint en relación a los miembros del equipo, sus relaciones y interacciones, los procesos y las herramientas usadas.

Reunión diaria de 15 minutos, que tiene lugar en el mismo sitio y a la misma hora cada día. Durante la reunión (se aconseja que los miembros estén de pie, y por eso a veces se le llama “stand up meeting”), se cada miembro del equipo responde a las tres preguntas siguientes, fundamentales en SCRUM:

› En qué ha estado trabajando desde el último SCRUM diario.

› En qué va a trabajar hasta el próximo SCRUM diario.

› Qué obstáculos (si los hay) tiene para realizar dicho trabajo.

La reunión diaria de SCRUM mejora las comunicaciones entre el equipo, eliminando la necesidad de muchos otras reuniones. Sirve para identificar y eliminar obstáculos que impiden el avance en el desarrollo, hace patente la necesidad de tomar decisiones rápidas y homogeniza el nivel de conocimiento sobre el estado del proyecto entre todos los miembros del equipo.

El SCRUM Master es el responsable de …› Asegurar que la reunión tiene lugar› Conducir la reunión (la gente sea breve, todo el

mundo hable, etc.)› Asegurar que las “gallinas” no hablen en la reunión

ni interfieran en ella

Artifacts

› Product Backlog: Lista prioritizada de todo aquello que es necesario para completar el proyecto.

› Sprint Backlog: Lista de tareas que transforman el Product Backlog para 1 Sprint en un incremento del producto final que esta potencialmente listo para una Release.

› Gráficos de Burndown (Release burndown o Sprint burndown): Medidas del tiempo restante en la Release / Sprint. Mide los ítems restantes a través del tiempo de una Release / Sprint.

El Product Backlog contiene los requerimientos para el producto que el equipo va a desarrollar.

El Product Backlog es responsabilidad única y exclusivamente del Product Owner. Se encarga no sólo de su contenido, sino de su disponibilidad, visibilidad y priorización.

El Product Backlog nunca está completo; evoluciona a medida que el producto y el entorno donde dicho producto se enmarca evolucionan. Es dinámico, y siempre debe asegurar que el producto desarrollado sea apropiado, competitivo y útil.

Mientras el producto exista, el Product Backlog existe.

Representa todo aquello necesario para desarrollar y lanzar un producto con éxito:› Funciones, tecnologías, modificaciones, mejoras, resolución de defectos, etc.

Cada punto del Product Backlog debe tener:› Descripción› Prioridad

Depende del riesgo, valor aportado y necesidad› Estimación (preliminar)

Calculada inicialmente durante la reunión de Release Planning, y refinadas a medida que el mismo Producto Backlog es revisado.

Responsabilidad del equipo. Está ordenado por prioridad, determinando

así las actividades de desarrollo inmediatas.

Consiste en las tareas que el equipo reqliza durante 1 Sprint para transformar los requerimientos del Product Backlog en un incremento acabdo.

Las tareas deben de ser simples.

El equipo es el encargado de actualizar el Sprint Backlog . Puesto que las tareas son unidades pequeñas (tareas simples), es posible que acaben apareciendo tareas nuevas o algunas desaparezcan durante el Sprint.

El Sprint Backlog es una imagen a tiempo real del trabajo que el quipo planea acabar durante un Sprint, y es propiedad exclusiva de éste equipo.

El gráfico Sprint Backlog Burndown muestra la cantidad de trabajo aún por realizar en un Sprint.

Se crea sumando las estimaciones del tiempo del Sprint Backlog aún por hacer, cada día.

Es un gráfico de línea, con el que el equipo mide la evolución para completar un Sprint. Sólo se consideran dos variables:› Trabajo aún por realizar› Fecha

El gráfico Release Burndown suma el tiempo aún por realizar del Product Backlog. Las unidades de tiempo suelen ser Sprints.

Hemos visto los elementos de SCRUM que se pueden considerar como “reglas”, pensadas para dar coherencia al desarrollo de un proyecto.

Pero, de todas formas, las reglas son muy flexibles y cuando el equipo se encuentra en una situación que los elementos anteriores no cubren explícitamente, SCRUM aboga por usar la creatividad y encontrar una forma nueva… usando el método empírico, que es el corazón mismo de SCRUM. › Inspección - Adaptación

3 puntos de inspección / adaptación:

Daily SCRUM – Inspeccionamos el progreso del Sprint y hacemos adaptaciones para el siguiente día de trabajo.

Sprint Review – Inspeccionamos el progreso hacia la Release y hacemos adaptaciones para el siguiente Sprint.

Sprint Retrospective – Inspeccionamos el pasado Sprint y hacemos adaptaciones para mejorar el siguiente.

Como hemos visto, SCRUM se basa en entregar incrementos del producto final, potencialmente listos para una Release, al final de cada Sprint.

Es decir, estos incrementos deben de ser estar “acabados” – el cliente podría usarlos si así lo requiriera.

Cada incremento debe de aportar nueva funcionalidad respecto a Sprints anteriores, y debe de estar completamente probado (asegurando que todos los incrementos acabados hasta la fecha funcionan).