SCRUM. The art of doing twice the work in half the time. Sutherland, Jeff

SCRUM

The art of doing twice the work in half the time

¿Proyecto?

La definición clásica de proyecto: construcción de un resultado único, en unas fechas previstas y con unos recursos previstos de antemano.

➔ Entrega temprana de resultados ➔ Respuesta ágil y flexible

➔ Mercados que evolucionan rápidamente

Gestión ágil, no se formula sobre la necesidad de anticipación, sino sobre la de adaptación continua.

Nuevo Clásico

¿Qué es Scrum?

Scrum es una metodología ágil para gestionar proyectos de software, simple, que requiere de trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.

● Es un modo de desarrollo adaptable, antes que predictivo. ● Orientado a las personas, más que a los procesos.

● Emplea el modelo de construcción incremental basado en iteraciones y revisiones.

Nuestro escenario cambia

Nonaka y Takeuchi son los primeros en identificar estos nuevos entornos de producción a los que denominan “campos de scrum” en el artículo The New New Product

Develop-ment Game”.

https://hbr.org/1986/01/the-new-new-product-development-game

Características con las que se enfrentan las empresa que desarrollan con modelos de gestión ágil :

● Incertidumbre

● Auto-organización ● Control sutil

● Difusión del conocimiento

Manifiesto

ágil

Principios del Manifiesto Ágil

● Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

● Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

● Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

● Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

● Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

● El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

● El software funcionando es la medida principal de progreso.

● Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

● La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

● La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. ● Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

● A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Objetivos

La gestión ágil de proyectos no es una gestión de anticipación (requisitos, diseño, planificación y seguimiento) sino de adaptación (visión, exploración y adaptación).

La gestión ágil tiene como objetivos: ● Valor: Innovación

● Reducción de tiempo de desarrollo ● Agilidad y flexibilidad

¿Cómo funciona?

Se identifican 5 fases

A partir de una necesidad del cliente construye el producto de forma incremental.

Incrementa a través de

iteraciones breves llamadas

sprint.

Marco técnico de Scrum

Roles:

o El equipo scrum.

o El dueño del producto. o El Scrum Master.

Eventos:

o Sprint.

o Reunión de planificación del sprint.

o Scrum diario.

o Revisión del sprint.

o Retrospectiva del sprint.

Artefactos:

o Pila del producto. o Pila del sprint. o incremento.

Roles “cerdos” y los “pollos”

Un cerdo y un pollo van caminando por la carretera. El pollo le dice al cerdo: -Oye, ¿por qué no abrimos un restaurante?

El cerdo se vuelve y le responde:

-Buena idea, ¿cómo quieres que lo llamemos? El pollo se lo piensa y propone:

-¿Por qué no lo llamamos “Huevos con jamón”.

-No cuentes conmigo -responde el cerdo-. En ese caso, tú sólo estarías IMPLICADO, mientras que yo estaría realmente COMPROMETIDO.

Equipo

- Pequeños y auto-organizados - Multidisciplinar

- Colaborativos, comunicación transparente

- Puede existir una cabeza visible “Team Leader”

Product owner (cliente)

- Visión del producto/negocio - Historias de usuario - Marca prioridades Interesados - Usuarios de la aplicación - Clientes y vendedores - Gestores, directivos Scrum Manager (facilitador)

● ¿Quién debe participar en las demos del producto?

● ¿Planificamos? ¿Quién decide lo que “cuesta” hacer una tarea?

● ¿Quién se va a encargar de asignar las tareas a cada desarrollador? ● ¿Quién decidirá la arquitectura del sistema?

Artefactos

Product backlog (pila del producto) es la lista de requisitos de usuario que está en constante evolución durante el desarrollo del producto. Puede incluir

funcionalidades, mejoras, tecnología y corrección de errores.

Sprint backlog (pila del sprint) es lista de tareas que debe realizar el equipo durante el sprint para generar el incremento previsto.

Pila del producto

Incremento

Incremento es la parte de producto desarrollada en un sprint, y se debe encontrar completamente terminada, probada y en condiciones de ser usada

Eventos

Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central que genera el pulso de avance a ritmo de “tiempos prefijados” (time boxing).

Reunión de Planificación del sprint: reunión de trabajo que marca el inicio de cada sprint en la que se determina cuál es el objetivo del sprint y las tareas necesarias para conseguirlo.

Scrum diario: breve reunión diaria del equipo 10/15 minutos, en la que cada miembro responde a tres cuestiones: ¿Qué hice ayer? ¿Qué voy a hacer hoy? Cosas que puede necesitar, o impedimentos que deben eliminarse para poder realizar el trabajo.

Revisión del sprint: análisis e inspección del incremento generado, y adaptación de la pila del producto si resulta necesario.

Retrospectiva del sprint: revisión de lo sucedido durante el Sprint. Reunión en la que el equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el próximo sprint.

Planificación del sprint

● La forman el product owner, el equipo y el Scrum manager. ● Solo se planifica el sprint no todo el proyecto.

● Tiene dos partes:

○ 1ª parte (max. 4horas)

■ El product owner expone sus necesidades y da su visión del producto. ■ Se decide que elementos de la pila del producto se van a desarrollar. ○ 2ª parte

■ El equipo divide las historias de usuario en tareas. ■ El equipo estima las unidades de trabajo de cada tarea. ■ Propuesta de trabajo.

● Resultado:

○ Pila del sprint

○ Duración del sprint.

○ Fecha de la reunión de revisión ○ Objetivo del sprint

Rellenar

una tarea

Cómo se mide

Fibonacci

● Estimaciones solo en base a la serie de Fibonacci.

Estimación de póker

● Práctica ágil para realizar estimaciones y duración de tareas.

● El equipo emplea un juego de cartas para estimar.

Comienza

el sprint

Durante

el sprint

Durante

el sprint

Sprint.

¿Cómo trabajamos durante el sprint?

● Reunión diaria de seguimiento. Se hace de pie y dura 15 minutos.

● El Scrum master dirige la reunión y le hace a todos los miembros del equipo tres preguntas: ¿Qué hiciste ? ¿Qué vas a hacer en el próximo tiempo?

¿Problemas?

● Cada miembro del equipo selecciona una tarea y la pone en la zona “en proceso” (WIP), actualiza el tiempo pendiente o la marca como finalizada.

● El equipo refresca el gráfico de avance del sprint.

● El Scrum Manager comienza la gestión de necesidades e impedimentos identificados.

Scrum diario

● Lo forma el equipo y Scrum manager. ● Como mucho dura 15 minutos.

● Reunión de pie.

● Cada miembro del equipo responde a tres preguntas:

○ ¿Qué hice ayer?

○ ¿Qué voy a hacer hoy?

○ Cosas que puede necesitar, o impedimentos que deben eliminarse para poder realizar el trabajo.

Revisión del sprint

● La forman el product owner, el equipo y el scum manager y puede que algún interesado.

● Como mucho 4 horas.

● Se enseña el incremento al cliente. ● No necesita preparación.

Burn Down. Monitoriza el avance del sprint

Herramienta del equipo para gestionar y seguir el trabajo de cada sprint. Es una representación gráfica del avance del sprint.

Gráfico del producto o Burn-up

Herramienta de gestión y seguimiento para el propietario del producto. Presenta de un vistazo:

● Versiones de producto ● Funcionalidades

● Velocidad estimada ● Fechas probables para

cada versión

● Margen de error previsto en las estimaciones

Enlaces de interés

● Flexibilidad con Scrum CC by-nc Juan Palacio

http://www.scrummanager.net/files/scrum_manager.pdf

● https://hbr.org/1986/01/the-new-new-product-development-game

● http://navegapolis.com/

● http://agilemanifesto.org/iso/es/manifesto.html

1. ProductBackLog. Definir historias de usuario (requisitos del sistemas) 2. Planificación de un sprint. 2 semanas de duración

a. Seleccionar historias de usuario a desarrollar b. División en tareas

c. Estimación

3. Realizar sprint

a. Reunión diaria

b. Actualización de tareas y gráfico (Burn down)