Archivo de la etiqueta: ágil

SCORE: Usando metodologías ágiles para gestionar equipos de investigación

Con la introducción al agile creé el primer post de la serie, seguido de los post explicando las distintas facetas del Scrum (con los roles y el flujo de trabajo) hoy vengo con una aplicación directa para los equipos de investigación. Los grupos de investigación son grupos de gente que trabajan en el plano de las ideas. Al igual que los desarrolladores de software al final del día no crean ningún producto tangible solo ideas, información, conocimiento, pero nada que puedas tocar.

Hace ya bastantes años algunos de los grupos de investigadores de la universidad de Maryland (USA) decidieron implementar una nueva metodología para la supervisión de sus estudiantes, ya sean de grado, máster, doctorado o post-doc. Una metodología que se adaptara a las necesidades de cada individuo y no a las del título que ostentasen.

Esta implementación vino dada debido a la falta de tiempo que empezaban a sufrir los profesores. Con el incremento de estudiantes y responsabilidades cada vez tenían menos tiempo para dedicar a los estudiantes. Así que decidieron crear e implementar la metodología SCORE. Score proviene de SCrum fOr REsearch.

La idea principal consiste en reducir la carga de meetings a los que los miembros del grupo están sujetos sin comprometer la calidad del trabajo. Para conseguir optimizar el tiempo que pasan los profesores con sus alumnos crearon dos tipos de meetings. 15min meeting y los 1 on 1 meeting on demand.

  • Los 15min meetings tienen sitio tres veces por semana y como indica su nombre duran 15 minutos. Estos meetings, al igual que scrum, se hacen de pie para asegurar la brevedad de este. Durante este tiempo es requerido que todos los miembros del grupo acudan presencialmente y a modo excepcional lo hagan por videoconferencia. En el meeting todos los asistentes tienen que responder a tres preguntas:
    1. Que has hecho des de tu último meeting?
    2. Que problemas te has encontrado?
    3. Que quieres hacer para el próximo meeting?

    Al ser meetings tan frecuentes no pasa nada si algunas veces se responde que no ha habido resultados significativos.

  • El segundo tipo de meetings son los 1 on 1 meetings on demand. Que traducido sería meetings a título individual pero que se tiene que pedir cita. Con este tipo de meetings la idea es intentar reducir los meetings periódicos que solo roban tiempo. No siempre se requiere la misma duración para un meeting. Algunas veces los meetings precisan 15min y otras 2h porque la tarea es más compleja. Al pedir el meeting ya sabes de lo que se va a hablar y no va a ser una pérdida de tiempo.

Los estudiantes parecen bastante satisfechos con la nueva organización del laboratorio. Los profesores también parecen satisfechos con el resultado. Y a mi personalmente me parece interesante que hayan suprimido el meeting semanal que muchos grupos tienen en los que se presenta a lo grande.

 

Referencias:

Que flujo de trabajo tiene scrum?

Siguiendo los posts anteriores en los que hablaba a modo general de las metodologías ágiles, luego en específico de scrum, y de sus roles. Esta semana toca hablar del flujo de trabajo de scrum. El flujo de trabajo (el workflow) son los pasos que sistemáticamente siguen los integrantes del equipo. En el caso de Scrum se puede decir que hay dos grandes partes. El sprint y el scrum diario. El segundo se repite a diario, como el nombre indica, para avanzar a la compleción satisfactoria del primero, el sprint.

 

File:Scrum process.svg

Sprint

Un sprint o iteración es una unidad básica de de tiempo de desarrollo en Scrum. No confundir con los code-sprints, estos son eventos no recurrentes para colaborar intensamente en un periodo te tiempo concreto. Un sprint en scrum tiene una duración especifica, conocida de antemano. Normalmente los sprints duran dos semanas aunque las hay de un mes. La duración se mantiene constante en cada equipo y en teoría es optimizada para un mejor rendimiento adaptándose a las circunstáncialas.

Cada sprint se empieza definiendo la lista de tareas (sprint backlog). En el proceso de definición de tareas se estima el tiempo en el que un integrante del equipo tarda en realizar cada tarea y la carga de trabajo general para el equipo. Una vez los días han pasado y el sprint se ha terminado se hace una retrospectiva en la que se define que se entrega a los clientes y se analiza lo que se puede mejorar para las próximas iteraciones (sprints).

Scrum diario

El scrum diario es un meeting informal pero con unas reglas marcadas. Se empieza siempre a la misma hora (aunque falte gente), se hace de pie (para evitar que se alargue innecesariamente) y esta limitado a 15min. Durante este tiempo cada miembro del equipo tiene que responder a tres preguntas

  • Que hice ayer que ayude al equipo a alcanzar el objetivo del sprint?
  • Que voy a hacer hoy que ayude a alcanzar el objetivo del sprint?
  • Hay alguna cosa que dificulte a mi o al equipo la tarea de completar satisfactoriamente el sprint?

Una dificultad puede ser dependencias que van retrasadas, riesgos, una suposición incorrecta, etc.

 

Que roles tiene Scrum?

Ya llevo un par de posts explicando que son las metodologías ágiles y que es scrum en especifico. En esta entrada voy a exponer los distintos roles que tiene un equipo de scrum. Por el bien de la simplicidad Scrum solo considera tres roles.

Product owner (dueño de producto)

El dueño de producto representa a las partes interesadas (stakeholders = los clientes y consumidores principalmente). Su principal tarea es crear una hoja de ruta para que el equipo entregue el mayor valor posible. Es el encargado de diseñar el producto teniendo el cliente en mente. Diseña las historias de usuario (user stories), las pone en la cola de tares y las prioriza dependiendo en la importancia y sus interrelaciones. Este rol no se puede llevar a cabo conjuntamente con el de scrum master ya que el jefe de producto es el encargado de lidiar con los clientes mientas que el scrum master es el encargado de de decidir el camino para la implementación técnica. En resumen, el dueño de producto es el proxy entre los desarrolladores y los clientes, por lo tanto este rol requiere buenas habilidades de comunicación.

Desarrollador

Como ya indica el nombre, el desarrollador es el encargado de desarrollar el producto. Los desarrolladores son los encargados de implementar partes de producto en cada sprint que puedan ser entregadas al cliente. Como subcategorías encontraríamos los desarrolladores (máquinas biológicas que transforman café en lineas de código), los testers, arquitectos de software, analistas, diseñadores, etc.

Scrum master

Es principalmente el encargado de quitar los impedimentos que tengan los miembros de su equipo (los desarrolladores) al implementar el entregable. Es el encargado de facilitar los meetings, evitar distracciones, y asegurarse que se siguen las reglas acordadas para la metodología. También es el encargado de asegurarse de cumplir con las fechas de entrega y ayudar al equipo a mejorar y superarse día a día. Por decirlo de otro modo es el encargado de manejar el backend del equipo, manejarse internamente.