Jesús Ramírez Guerrero

Como ya vimos hace unas entradas, Scrum es una metodología ideal para trabajar en un proyecto o producto con un PO (Producto Owner) y un equipo multidisciplinar asociado. El tamaño del equipo ideal se estima entre 7 y 20 personas (depende del proyecto), a menudo en España los equipos de informática de las empresas (Pymes) tratan varios proyectos con equipos pequeños, incluso a la vez realizan el mantenimiento de otros proyectos. Es por ello por lo que nos podrían venir varias preguntas a la mente:

• ¿Es aconsejable usar Scrum o una metodología Agile en estas situaciones?
• ¿Cómo lidiar con Scrum, en estos casos?

Para tratar de responder a estas preguntas desde luego habría que conocer la situación específica en cada equipo o empresa, aunque podría dar unas directrices, que ya se indican en Scum, pero que conviene recordar.

1. Scrum trata de coordinar equipos y establece una metodología de trabajo para UN proyecto con UN equipo. Es decir, si en nuestro caso con un sólo equipo tratamos varios proyectos, deberemos establecer VARIOS procesos Scrum con un mismo equipo.  No es lo ideal desde luego aunque sí posible, bajo mi experiencia es complicado y conlleva una complicada coordinación de tareas o retrasos en las mismas si se abordan varios proyectos al mismo tiempo. Como consejo, es buena idea asignar particiones de tiempo semanales a cada proyecto (repito es consejo personal).

   Ej: semana 1 -> Proyecto 1, semana 2 ->Proyecto 2, semanas 3 y 4 -> proyecto 3. Esto se realizará dependiendo de la prioridad o tamaño del proyecto.

   Aunque se lleven adelante varios proyectos, conviene separar el tiempo mensual (o semanal) para no liar a los desarrolladores y miembros del equipo. De esta manera no será más fácil la planificación.

2. Se debe llevar un Product Backlog por Producto o Proyecto. Por lo que una coordinación podría ser:
   Team: 2PO, 1 SM, 3 DEVs

   Product A (PO A):

   backlog item 1

   backlog item 2

   Product B (PO B):
   backlog item 3
   backlog item 4

   Sprint 1:

   backlog item 1
   backlog item 3

   Sprint 2:
   backlog item 2
   backlog item 4

   Siempre diferenciando cada Producto y distribuyendo Sprints de cada Proyecto.

3. En el caso de lidiar además con el mantenimiento de productos ya finalizados y desarrollados, cada equipo debe decidir cómo tratar este aspecto. Algunas formas de abordar esto suele ser:

• Rotación de recursos: Se trata de asignar una persona del equipo (la que esté más descargada de trabajo en el Sprint actual o la elegida por el equipo en una reunión) para trabajar durante un tiempo dando soporte a proyectos ya finalizados.
• Dedicación completa de parte del equipo: Es la más simple, se encarga un pequeño grupo de nuestro equipo al mantenimiento de los productos que lo requieran.

  Es muy complejo tratar con Scrum la mezcla de desarrollo + mantenimiento usando el mismo equipo de trabajo.

  Próximamente trataremos el problema contrario, ¿cómo abordar con Scrum y grupos de trabajo muy grandes?.

  Espero que os ayude, cualquier comentario o recomendación al respecto de lo visto será bienvenida.