mifergo

Introducción

Scrum es un proceso ágil que nos permite centrarnos en ofrecer el mayor valor de negocio en el menor tiempo.

Scrum es…

• Simple y minimalista
• Un marco de trabajo para la gestión de proyectos
• Soporta los valores y principios en el Manifiesto Agile
• Un planteamiento eficaz para gestionar la complejidad y el cambio
• Capacidad de adaptación para requisitos cambiantes o poco claros
• “Agile” en la naturaleza y la práctica
• Basado en el sentido común (pragmático)
• Menos documentación (”pocos y valiosos”)
• Liberar el producto pronto y a menudo (maximizar el ROI)
• Evita el caos, balanceando entre adaptación y la anticipación
• Promueve la comunicación frecuente y eficaz de los equipos
• Orientado al compromiso, la confianza y la responsabilidad
• Alienta a la difusión de conocimientos, la comprensión y la innovación
• Visibilidad diaria de los progresos y los obstáculos
• Un cambio de paradigma

¿Por qué usar Scrum?

• Aumento de la productividad
  • Según Rico (2008) con Scrum se aumenta la productividad entre un 14% y un 384% (88% de media).
  • Según Mah (2008) los proyectos Agile son un 16% más productivos.
• Reducción de coste
  • Según Rico (2008) la redución del coste fue desde el 10% al 70% (26% de media), gracias a reducir el re-trabajo.
• Aumenta el nivel de compromiso y la satisfación del empleado
• Reducción de las fechas de salida al mercado
  • Según Mah (2008) los productos de proyectos Agile salen un 37% antes que la media industrial.
• Aumenta el nivel de satisfacción de los interesados (clientes)
• Mayor calidad y mejora continua.

Resumen

• Scrum es un proceso ágil que nos permite centrarnos en ofrecer el mayor valor de negocio en el menor tiempo.
• Scrum nos permite rápida y repetidamente inspeccionar el software en el que se está trabajando actualmente (cada 1-4 semanas)
• El negocio fija las prioridades. Los equipos se auto-organizan para determinar la mejor manera de desarrollar las funcionalidades con más prioridad.
• En intervalos regulares (de 1 semana a 1 mes), cualquiera puede ver el software en el que se está trabajando y decidir entregarlo como está  o continuar para mejorarlo en el siguiente Sprint.

Valores Scrum

• Compromiso
• Foco
• Abierto
• Respeto
• Coraje

Esquema de Scrum

Los elementos

Pila de Producto (Product Backlog)

La pila de producto es el corazón de Scrum. Es donde empieza todo. La pila de producto es, básicamente, una lista priorizada de requisitos, o historias, o funcionalidades, o lo que sea. Cosas que el cliente quiere, descritas usando la terminología del cliente. Llamamos a esto historias, o a veces simplemente elementos de la Pila.

Es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo. Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto.

Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en la pila de producto.

A diferencia de un documento de requisitos del sistema, la pila de producto nunca se da por completo; está en continuo crecimiento y evolución.

Para comenzar el desarrollo se necesita una visión de los objetivos que se quieren conseguir con el producto, comprendida y conocida por todo el equipo, y elementos suficientes en la pila de producto para llevar a cabo el primer sprint.

Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:

• Identificador único de la funcionalidad o trabajo.
• Descripción de la funcionalidad.
• Prioridad.
• Estimación.

Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:

• Observaciones
• Criterio de validación
• Persona asignada
• Número de sprint o iteración en el que se realiza
• Módulo del sistema al que pertenece
• Etc.

Sprint (Iteración)

Cada iteración se programa mediante un intervalo de tiempo fijo para realizar una parte del producto (el intervalo) con garantías para que no haya distracciones al equipo de desarrollo y por otra parte que permita flexibilidad para adaptarse a cambios en los requisitos. Es lo que se llama “Sprint”.

El objetivo de un sprint debe ser entregar una parte del producto con ciertas funcionalidades que el cliente puede probar. De esta manera se implica al cliente en el desarrollo del producto, pudiendo este comprobar que lo que se está haciendo es lo que ha pedido además de comprender las dificultades que va teniendo el equipo a lo largo de la vida del proyecto.

Los sprints cortos les gustan a los clientes, porque pueden ir probando funcionalidades que se van acabando y dar su opinión al respecto.

Los sprints largos le gustan al equipo de desarrollo, pues así tiene más autonomía y menos cambios.

Se toma una duración compromiso entre el cliente y el equipo de desarrollo de tal manera que se consiga un equilibrio entre el trabajo realizado y la adaptabilidad al cambio. Suele ser entre 2 y 6 semanas.

Manteniendo la misma duración conseguimos un latido corporativo al que todo el mundo se acostumbra confortablemente.

Pila del Sprint (Sprint Backlog)

La pila del Sprint es la lista de tareas que se van a realizar en una iteración. Es la especificación de los requisitos de software necesarios para dar respuesta a las funcionalidades esperadas por el cliente.

Es la lista que descompone las funcionalidades de la pila de producto en las tareas necesarias para construir un incremento: una parte completa y operativa del producto.

En la pila del sprint se asigna a cada tarea la persona que la va a llevar a cabo, y se indica el tiempo de trabajo que se estima, aún falta para terminarla.

Es útil porque descompone el proyecto en tareas de tamaño adecuado para determinar el avance a diario; e identificar riesgos y problemas sin necesidad de procesos complejos de gestión.

El Incremento

El incremento es la parte de producto producida en una iteración, y tiene como característica que está completamente terminada y operativa: en condiciones de ser entregada al cliente final.

El incremento debe estar terminado y probado. Si el proyecto o el sistema requiere documentación, o procesos de validación y verificación documentados, o con niveles de independencia que implican procesos con terceros, éstos también tienen que estar realizados para considerar que el producto está “terminado”.

Las reuniones

La planificación de la Iteración

La planificación de la iteración es una reunión crítica, probablemente la más importante de Scrum.

Una planificación mal ejecutada puede arruinar por completo toda la iteración.

El propósito de la planificación de la iteración es proporcionar al equipo suficiente información como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas, y para ofrecer al dueño de Producto suficiente confianza como para permitírselo.

En esta reunión, tomando como base las prioridades y necesidades de negocio del cliente, se determinan cuáles y cómo van a ser las funcionalidades que se van a incorporar al producto con la próximo iteración.

En realidad esta reunión consiste en dos: En la primera, que puede tener una duración de una a cuatro horas, se decide qué elementos de la pila de producto se van a desarrollar. En la segunda se desglosan éstos para determinar las tareas necesarias, estimar el esfuerzo que necesita cada una y asignarlas a las personas del equipo.

La planificación de la iteración no debe durar más de un día.

Seguimiento de la Iteración (Daily Scrum)

Es una breve reunión diaria para dar repaso al avance de cada tarea, y al trabajo previsto para la jornada. Cada miembro del equipo responde a las siguientes preguntas:

1. Trabajo realizado desde la reunión anterior
2. Trabajo que se va a realizar hasta la próxima reunión
3. Impedimentos que se deben solventar para que pueda realizar el trabajo.

Revisión de la Iteración

Permite realizar el análisis y revisión del incremento generado. Esta reunión no debe tomarse como un “acontecimiento especial”, sino como la presentación normal de los resultados.

Los roles

Se destacan tres roles imporantes:

El dueño del producto (Product owner)

En el proyecto hay una persona, y sólo una, conocedora del entorno de negocio del cliente y de la visión del producto. Representa a todos los interesados en el producto final y es el responsable de la pila de producto.

El equipo

Todo el equipo de desarrollo, incluido el propietario del producto conoce la metodología Scrum, y son los auténticos responsables del resultado.

Es un equipo multidisciplinar que cubre todas las habilidades necesarias para generar el resultado.

Se auto-gestiona y auto-organiza, y dispone de atribuciones suficientes en la organización para tomar decisiones sobre cómo realizar su trabajo.

Scrum Master

En él recae la responsabilidad de funcionamiento del modelo.

La organización debe garantizar el funcionamiento de los procesos y metodologías que emplea, y en este aspecto Scrum no es una excepción.

Gráfica Burndown

Gráfica Burndown

Es una herramienta de seguimiento para el equipo, que muestra el avance del sprint día a día y revela de forma temprana posibles desviaciones.

Es un gráfico cartesiano que representa en el eje de abscisas los días laborables del sprint, y en el de coordenadas, la cantidad de esfuerzo estimada. Ver figura 4.

Primero, se traza una recta punteada que parte desde el día 1 del sprint con la cantidad de esfuerzo de todas las tareas estimadas y planificadas para es sprint y llega hasta el última día del sprint con una cantidad de esfuerzo 0. Esta línea es la evolución ideal del estado del proyecto.

Después, en la reunión diaria cada miembro del equipo al referirse al trabajo que realizó ayer, y el que tiene previsto hacer hoy, actualiza en la pila del sprint: si ha terminado alguna de las tareas en las que ha trabajado, o actualiza cuánto esfuerzo estima que le queda en cada una de las tareas que tiene asignadas. Se va trazando día a día la línea del estado del proyecto, según esta información.

De esta forma al final de la reunión la columna del día del sprint, muestra el esfuerzo que según el equipo falta para terminar sus tareas, y el equipo marca en el gráfico el punto que tiene como ordenada ese valor, y como abscisa la fecha del día.

Si la línea de estado del proyecto diverge de la ideal hacia encima, quiere decir que hay problemas y habrá tareas de la pila del sprint que no se podrán realizar. Sin embargo, si la línea diverge de la ideal hacia abajo, quiere decir que el equipo es capaz de desarrollar más trabajo y si no se aumenta la pila del sprint, se quedarán sin trabajo.