Metodología ágil: Scrum

Post date: Jun 05, 2010 9:23:34 PM

Scrum, más que una metodología de desarrollo software, es una forma de auto-gestión de los equipos de programadores. Un grupo de programadores deciden cómo hacer sus tareas y cuánto van a tardar en ello. Scrum ayuda a que trabajen todos juntos, en la misma dirección, con un objetivo claro.

Al empezar el proyecto, el responsable del proyecto, que conoce lo que tiene que hacer, que no va a codificar y que está en contacto más estrecho con el cliente (Product Owner), debe crear una lista de funcionalidades o características (Product Backlog) que quiere que se implementen en el programa. Estas funcionalidades deben ser tangibles, y "cuadran" muy bien con los User Stories de la programación extrema (XP).

A lo largo del proyecto se podrán:

    • añadir más funcionalidades a esta lista, o

    • quitarlas, o

    • modificarlas.

Sólo el Product Owner podrá ordenarla y deberá mantenerla ordenada, de forma que las primeras funciones del Product Backlog se harán antes.

Sprint Planning Meeting y Spring Backlog

El primer día que empecemos a trabajar en el proyecto, se hace una reunión, en la que estarán el Product Owner y los programadores (Scrum Team) que van a participar en el proyecto. Esta reunión recibe el nombre de Sprint Planning Meeting.

En esa reunión se elige un plazo de tiempo (en función del proyecto, necesidades y demás):

    • Una semana

    • 15 días

    • Un mes

Una vez elegido ese plazo de tiempo, se toma el Product Backlog y se van mirando las tareas empezando por la primera. Se pregunta al Scrum Team ... ¿puede la primera tarea estar hecha dentro de una semana?. El Scrum Team la examina, descompone en subtareas si hace falta, estiman el tiempo que tardarán en hacerla y dicen "sí". Si dicen que no, habrá que descomponerla en tareas más sencillas hasta que digan "al menos" que sí a una de ellas.

Se toma la segunda tarea y se pregunta al Scrum Team ... ¿puede estar la primera y la segunda en una semana?. Vuelven a estimar y dicen "sí".

Se repite el proceso con las siguientes tareas hasta que el Scrum Team empiece a dudar si sí o si no va a estar todo eso. Si el Product Owner quiere que esté alguna tarea que no va a estar, puede cambiarla por otra que sí esté, o "reducir" el alcance de una de las que ha entrado para que entre otra. En fin, este es el momento de "negociar" entre los programadores y el jefe qué va a entrar o no en una semana. El jefe puede decidir el orden, intercambiar tareas, modificarlas o partirlas, pero los programadores tienen la última palabra de cuánto tiempo necesitan para cada tarea. El tiempo necesario para todas las tareas seleccionadas no puede superar una semana.

Una vez llegado a un acuerdo, esas funcionalidades se pasan a una nueva lista, llamada Sprint Backlog. Hemos quedado todos de acuerdo que dentro de una semana vamos a entregar al Product Owner una versión del programa que tenga TODAS las tareas del Srpint Backlog funcionando.

Daily Scrum Meeting y Scrum Master (Esto también se conoce como Stand-Up)

Después de la reunión anterior en la que se decide el Spring Backlog, nos vamos todos a trabajar. A partir de ese día, TODOS los días, preferiblemente a primera hora, el Scrum Team se reune y cada uno contesta a tres preguntas:

    • ¿Qué hiciste ayer?

    • ¿Qué vas a hacer hoy?

    • ¿Qué ayuda necesitas?

Uno de los programadores hace de moderador de la reunión y se le llama Scrum Master. Este NO es jefe de los demás, simplemente debe encargarse de que la reunión no dure más de un cuarto de hora/media hora y de que las ayudas/problemas que plantean los programadores se resuelvan a lo largo del día.

El Product Owner también debe colaborar en eso de "quitar obstáculos", estar disponible para consultas, etc.

La ayuda necesaria puede ser de cualquier tipo:

    • "no conozco este tema y necesito alguien que me ayude",

    • "necesitaría tener datos en la base de datos para hacer pruebas",

    • "necesito tener mi pc conectado al osciloscopio", etc.

En resumen: cualquier cosa que uno de los programadores considere que le facilita el trabajo debe ser tratada aquí.

En esta reunión también se aprovecha para volver a estimar el tiempo de las tareas en curso. Puede que una tarea, el primer día, se dijera que se iba a tardar ocho horas. Resulta que hoy, después de haber trabajado el día de ayer en ella, emerge un problema inesperado y hoy decidimos que vamos a tardar 10 horas más en resolverla. No pasa nada, se apunta y listo.

Después de varios días de reuniones se verá rápidamente de esta forma si vamos según lo previsto o nos vamos a pasar en tiempo. Nuestro Product Owner, además, puede verlo, sobre todo si vamos registrando en alguna herramienta como Rally o CA-Agile Vision el día a día indicando cuantas horas suponemos que nos quedan para acabar en el eje vertical y los días en el eje horizontal.

Importante: Aunque en teoría Scrum dice que la lista de tareas a hacer (Sprint Backlog) NO se toca, hay mucha gente que decide añadir o quitar tareas en caso de ir adelantados o retrasados. Lo importante es entregar a final de la semana una versión con determinadas funcionalidades implementadas.

Sprint Review y Sprint Retrospective

Scrum permite además seguir de forma clara el avance de las tareas a realizar, de forma que los "jefes" puedan ver día a día cómo progresa el trabajo.Sin embargo, Scrum no es una metodología de desarrollo, puesto que no indica qué se debe hacer para hacer el código. Debería, por tanto, complementarse con alguna otra metodología de desarrollo. Se lleva bien con las metodologías ágiles y en concreto, con la programación extrema (XP).Product Backlog y Product Owner

Ya ha pasado el primer Sprint. Si estimamos bien, tenemos nuestra versión del programa con todas las funcionalidades del Sprint Backlog. Si estimamos mal, quizás esta versión tenga alguna funcionalidad menos o alguna de más.Ahora se hace una reunión de aproximadamente un par de horas, llamada Sprint Review, a la que acude el Scrum Team, el Scrum Master, el Product Owner y cualquier otra persona interesada en el producto. En ella el Scrum Master enseña la versión a los demás. Los asistentes pueden dar opiniones, posibles mejoras, etc.Inmediatamente después, se hace otra reunión, llamada Sprint Restropective, en la que el Scrum Master, el Scrum Team y el Product Owner analizan qué cosas pueden mejorarse a la hora de trabajar para el siguiente Sprint, si la comunicación ha sido bueno o debe mejorarse, si hay algún problema que deba subsanarse. En general, con un ambiente distendido y espíritu constructivo, ver cómo se puede mejorar la forma de trabajo en el Sprint Backlog del siguiente mes.Y vuelta a empezar, otro Sprint Planning Meeting para ver qué funcionalidades va a tener la nueva versión del mes que viene, un nuevo Sprint Backlog... y ¡A colonizar el mercado! :)

Algunos detalles

Como vemos, Scrum no dice nada de si hacer o no hacer diseño, si hacer o no hacer Test Unitarios, si hacer o no hacer documentación, si trabajar en parejas o no, etc, etc.

Scrum únicamente nos indica cómo conseguir que todos trabajen con el mismo objetivo, a corto plazo y deja bastante visible como avanza el proyecto día a día.

Lo ideal es complementarlo con una metodología de desarrollo software ágil, como la programación extrema (XP).

http://www.proyectosagiles.org/

http://www.scrum.org/

http://www.dosideas.com/wiki/Scrum

http://www.scrum.org/storage/scrumguides/Gua%20sobre%20Scrum.pdf#view=fit

Roles en Scrum

En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas. El nombre de los grupos están inspirados en el chiste sobre un cerdo y una gallina:

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: "Hey, ¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice: "Buena idea, ¿cómo se llamaría el restaurante?" La gallina piensa un poco y contesta: "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el cerdo, "Yo estaría comprometido pero tú solamente estarías involucrada".

De esta forma, los cerdos están comprometidos a construir software de manera regular y frecuente, mientras que el resto son gallinas: interesados en el proyecto pero realmente irrelevantes porque, si éste falla, no son un cerdo, es decir, no son los que de manera comprometida ponen su propio pellejo (y carne) para sacar el proyecto adelante. Las necesidades, deseos, ideas e influencias de los roles gallina se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum.

Roles "Cerdo"

Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamón en el plato".

    • Product Owner: El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

    • ScrumMaster (o Facilitador): El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

    • Scrum Team (Equipo): El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc).

Roles "Gallina"

Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Análisis de la frase "Rol gallina": La gallina alimenta al proyecto "poniendo huevos", no se ve comprometida como el cerdo que va al matadero.

    • Usuarios: Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el bosque cuando no hay nadie ¿Hace ruido? Aqui la definicion sería Si el software no es usado ¿fue alguna vez escrito?.

    • Stakeholders (Clientes, Proveedores): Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del sprint.

    • Managers: Es la gente que establece el ambiente para el desarrollo del producto.

Reuniones en Scrum

Daily Scrum

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:

    • La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quién llega tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)

    • Todos son bienvenidos, pero solo los "cerdos" pueden hablar.

    • La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.

    • Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)

    • La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:

    • ¿Qué has hecho desde ayer?

    • ¿Qué es lo que estás planeando hacer hoy?

    • ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

Reunión de Planificación del Sprint (Sprint Planning Meeting)

Al inicio del ciclo Sprint, una “Reunión de Planificación del Sprint” se lleva a cabo.

    • Seleccionar que trabajo se hará

    • Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo.

    • Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint

    • Ocho horas como límite (para un Sprint de 15/30 días)

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”

Reunión de Revisión del Sprint (Sprint Review Meeting)

  • Revisar el trabajo que fue completado y no completado

  • Presentar el trabajo completado a los interesados (alias “demo”)

  • El trabajo incompleto no puede ser demostrado

  • Cuatro horas como límite (para un Sprint de 15/30 días)

Retrospectiva del Sprint (Sprint Retrospective)

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.

Documentos

  • Product backlog

  • Sprint backlog

  • Burn down chart

El burn down chart es un gráfico mostrado públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

La historia del Scrum

Jeff Suterland en 1993 trabajaba en Easel Corporation. Tras conocer el trabajo de Nonaka y Takeuchi, Jeff identificó paralelismos con la industria del software, y aplicó un modelo de desarrollo ágil, iterativo e incremental para desarrollar y mantener sistemas de software.

En 1996 lo presentó junto con Ken Schwaber como proceso formal para gestión del desarrollo de software en OOPSLA 96, con el nombre que Nonaka y Takeuchi habían dado a estos equipos de trabajo: "Scrum", por la comparación que hicieron con los equipos de Rugby.