Archivo de la etiqueta: scrum

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.

De que hablan los desarolladores cuando mencionan Scrum?

La semana pasada hablamos de metodologías ágiles como concepto general. Esta semana vamos a profundizar con Scrum, una metodología ágil entre muchas. El Scrum hace especial énfasis en el desarrollo de software para equipos (idealmente) de 3-9 desarrolladores (que curiosamente, o no, sigue la regla de las dos pizzas). Los equipos pequeños tienden a obtener una mejor productividad en general. Los meetings son más directos y requieren menos interacciones. Si cada miembro de un equipo tiene que mantenerse en contacto con los demás miembros el número de interacciones entre participantes se incrementa exponencialmente con el número de integrantes del grupo.

Los integrantes del grupo tienen un tiempo definido para finalizar las tareas asignadas. El tiempo asignado depende de cada equipo. Normalmente se sitúan en 15 días, aunque puede llegar hasta los 30. Estos intervalos de tiempo son comúnmente nombrados “sprints”. Pero para seguir la evolución de las tareas y re-planificar si es necesario, Scrum incorpora standup meetings. Estos meetings son reuniones diarias en las que la duración aproximada es de 15 minutos y se hacen de pie. Los standup meetings tienen el nombre en clave de scrum diario (daily scrum).

La idea principal de scrum se basa en la colaboración plena entre miembros del equipo para la construcción del producto, contrario a otras metodologías más tradicionales. Previamente cada individuo hacia su tarea asignada en base a los requerimientos hecho que incrementaba las probabilidades de fracaso estrepitosamente. Cualquier error de planificación o falta de detalle era pagado con creces ya que a menudo el proyecto tenía que ser desarrollado de nuevo y a menudo requería desechar buena parte del progreso. Lo que intenta hacer Scrum es evitar justamente todo esto. Scrum intenta adaptarse a los cambios con facilidad y poder desechar partes sin que el coste total del proyecto se incremente prohibitivamente.

Implícitamente Scrum reconoce que los clientes no saben lo que quieren y que sus necesidades evolucionan continuamente adaptándose a las nuevas tendencias. A menudo los cambios son impredecibles y consecuentemente imposibles de planificar. Con todo este en mente, Scrum crea un marco en el que la adaptabilidad permite responder a los cambios emergentes, nuevas tecnologías y cambios en el mercado.

 

Que son las metodologías de desarrollo ágiles?

Hace ya algunos años que las metodologías ágiles están de moda entre ingenieros, especialmente equipos de programadores. Muchos hablan Scrum, pero hay otras como XP (eXtrem Programming), kanban, V-model, waterfall model, modelo espiral, y un largo etc. Frecuentemente estas metodologías son usadas como onanismo teórico. Recursos humanos frecuentemente recurren a las palabras “trending” para atraer talento. Pero del dicho al hecho hay un trecho.

Los métodos agile de desarrollo de software se adaptan al proyecto. Los requerimientos y soluciones evolucionan gracias al esfuerzo colaborativo entre miembros del equipo interdisciplinar de desarrollo y el cliente. Su objetivo principal es la adaptación y flexibilidad para desarrollar soluciones, entregar productos antes de tiempo, y mejorar continuamente el producto. Para los que queráis leer más sobre los principios de los métodos ágiles lo podéis encontrar un manifesto online.

Ninguna de las metodologías es perfecta. Cada una tiene un foco especifico y un objetivo concreto. Cada uno de los marcos de desarrollo intenta solventar alguno de los problemas que los equipos tienen. Algunos con más éxito que otros, pero al final una parte importante del resultado depende de las personas. Cada empresa y cada equipo tiene su blueprint para enfrentarse a problemas. Por lo que cada equipo tiene que entender la metodología y adaptarla para mejorar el rendimiento y no al revés.