SCRUM para un equipo en MÚLTIPLES proyectos

11-12-2008 Luis Artola

No puedo decir que en mi empresa utilicemos SCRUM para desarrollar software. Pero sí que nos inspiramos en él para hacerlo (y que vamos adoptando “costumbres” de SCRUM y pensamos seguir haciéndolo, poquito a poquito). Uno de nuestros principales problemas a la hora de hacer SCRUM es que éste plantea un escenario de varias personas (equipo) en un sólo proyecto. Sin embargo, normalmente en nuestro caso ocurre lo contrario: una persona, varios proyectos.

He encontrado pocos artículos que comenten ésta situación. El más interesante es éste.

¿Alguna experiencia con éste escenario? ¿Cómo lo solucionáis?

Etiquetas:

15 Comentarios

  • 1. Enrique Place  |  diciembre 11th, 2008 at 2:36 pm

    Luis, el problema es que SCRUM es gestión de equipos, tú no tienes un equipo ;-)

    Aunque lo que puede servir es para la organización de tareas, pendientes y avances, ya que asumo que este pobre esclavo.. perdón, persona, tiene que coordinarse con un jefe (o más).

    PD: mi pésame al desarrollador. ;-)

  • 2. Luis Artola  |  diciembre 11th, 2008 at 7:00 pm

    jajaja. Enrique:”una persona varios proyectos”, no me refiero a que sólo haya una persona… XDD

    Lo que pasa es que muchas veces tenemos que tener varios proyectos a la vez. Intento que no sean más de dos XDD. Por eso quiero que SCRUM me ayude a gestionar mejor la situación cuando el equipo tiene que enfrentarse a más de un proyecto a la vez. A veces, sólo con cambiar de proyecto, ya se está perdiendo más tiempo….

  • 3. Enrique Place  |  diciembre 11th, 2008 at 10:40 pm

    Ahhh, ok ;-)

    El tema es que -justamente- tener una persona en varios proyectos general el costo de “switch” cada vez que cambia de proyecto, lo cual es muy alto (no somos máquinas, no podemos ejecutar procesos en paralelo).

    Podrían manejar un proyecto por 1/2 día, pero igual, no es lo mismo pasar 1 día entero en un solo proyecto (se es más productivo).

    De la misma forma, tienen que tener bien defina una “plataforma de desarrollo” tal que todo lo que se desarrolle siempre sea una sola vez y posteriormente reuso. Cuando se generaliza los procesos y el código, luego es hacer lo mismo pero en distintos contextos, buscando estandarizar lo más posible.

    Priorizar es imaginar un conjunto de camellos que solo pueden pasar por la puerta 1 a la vez, al tener que -obligado- hacer una fila uno detrás de otro, logras definir prioridades reales.

    Aquí veo lo mismo, la mejor productividad será más alta si tienes dos semanas para desarrollar y dos proyectos de 1 semana, que se haga uno y luego el otro, a que esté cambiando dia a dia o medio día.

    Y ni te digo que habría que tener roles que se especialicen en temas para -nuevamente- no tener que “switchear” entre distintos temas.

    ¿Cuantas personas/roles tienes es tu equipo?

  • 4. Joserra  |  diciembre 12th, 2008 at 9:00 am

    Nosotros nos lo estamos planteando también. Yo creo, aún sabiendo los problemas que comenta Enrique, que una posibilidad es hacer un product backlog que tenga tareas de diferentes proyectos. Y es ahí donde priorizas entre proyectos.

  • 5. Luis Artola  |  diciembre 12th, 2008 at 9:51 am

    Joserra, ¡esperaba tu comentario en éste asunto! ¡has tardado casi 24 horas! :-D :-D

    Supongo que un product backlog común por prioridades es lo lógico (aunque el backlog ya no será del “product”, sino que más bien será una pila de tareas… ), tampoco sé muy bien qué pasa con los iteration backlogs… ¿un iteration backlog para cada product? ¿y si la iteration de los proyectos no tienen la misma duración?

    Reconozco que el escenario real es menos complejo, pero es por rizar el rizo… :-D

    Enrique,
    el coste de switch es lo peor de todo. ¿no crees? Me debo de estar haciendo mayor, porque cada vez me cuesta más concentrarme cuando cambio de proyecto varias veces al día… :-/ Mi equipo es de tres programadores conmigo incluido, que hago de jefe de proyecto también. En algunos proyectos, cuando el cliente es medianamente proactivo y joven (no muy a menudo, la verdad) lo integramos en el proyecto como Product Owner. Sino, las veces de Product Owner las hace nuestro comercial técnico, o yo mismo también… Evidentemente en un equipo así tampoco hace falta matarse para seguir scrum al dedillo, pero cada vez estamos incorporando más “costumbres de scrum” que nos facilitan la vida.

    Creo que el mayor cambiazo ha sido en vez de “planificar un alcance y a ver cuánto tiempo tardamos en hacerlo”, “planificar un tiempo (p.ej. iteraciones de dos semanas) y, en todo caso, modificar el alcance de la iteración”… Para nosotros ha sido un cambio total.

  • 6. Joserra  |  diciembre 12th, 2008 at 11:53 am

    Jeje, he estado desconectado un día por problemas personales y ya me echan de menos… :D
    El product backlog, ciertamente se convertiría en un multi-product-backlog. Te da la visión de las prioridades entre proyectos, que es muy interesante, por que solo cabe un camello por la puerta.
    El sprint lo planificas igual que antes, solo que puede haber historias de usuario o tareas de más de un proyecto. La duración de las iteraciones no depende del proyecto!!! no podrías estar involucrado en iteraciones diferentes al mismo tiempo. Cada iteración haces lo que peudas según la prioridad de los proyectos.

  • 7. Luis Artola  |  diciembre 12th, 2008 at 12:14 pm

    “la duración de las iteraciones no depende del proyecto” –> touchez. Ahí me has dado… ¡muy bien lo tengo mucho más claro!

    oye,¿y qué herramienta utilizar para gestionar los backlogs? A mí el excel no me ha funcionado muy bien. Y eso que mucha gente lo usa. Utilizo un wiki sencillito. Tengo entendido que utilizáis Jira, verdad? qué tal la experiencia?

  • 8. Joserra  |  diciembre 12th, 2008 at 1:44 pm

    Yo soy un fan de JIRA :) así que no me hagas mucho caso.
    En realidad intentamos llevarlo de manera visible todo en la pizarra, con los míticos post-it. JIRA es el refuerzo para que no se pierda nada, controlar las horas de manera sencilla, mantener comentarios y trazabilidad.

  • 9. Miguel  |  diciembre 14th, 2008 at 7:57 pm

    En mi empresa tenemos exactamente el mismo tipo de situacion, unos 15 tecnicos para 35 proyectos. Llevamos un excel para cada uno de los proyectos con el backlog.
    Para planificarlo se ponen todas las tareas y segun los recursos se indica un dia de finalización. Cada semana (no cada dia como scrum) se repasa y se ve si se sigue (es ciertamente complicado cuando cada persona tiene minimo 2 proyectos). La fecha de cada sprint es fija, con lo que si a alguna tarea no se llega se saca del sprint y se mete en el siguiente. Es importante añadir las tareas de pruebas y documentación, que siempre se olvidan.

    El tema de hacer un backlog de diferentes proyectos no lo vemos escalable. Lo que hacemos es otro excel y agregar los sprint de cada proyecto, asi se pueden asigar prioridades entre proyectos facilmente.

    Saludos!

  • 10. Luis Artola  |  diciembre 15th, 2008 at 9:01 am

    Muy interesante Miguel. Un backlog para cada proyecto, pero un sólo backlog de sprint (sin olvidar documentación y pruebas).

    Supongo que cada uno debe adaptarlo a la realidad de su empresa (35 proyectos en un sólo backlog podría ser un poco infernal si.. :-D )
    Vuestros 15 técnicos: ¿forman un sólo equipo? ¿los tenéis divididos por equipos que son siempre iguales o rotan? Me parece otra cuestión interesante…

  • 11. Juan  |  diciembre 30th, 2008 at 9:57 pm

    Hola!
    Qué charla tan interesante.
    Siento no haberla visto antes.
    Tenéis mucha razón: la verdad es que, en la mayoría de las empresas de por aquí, lo de equipos de 5 ó 6 personas dedicadas a un proyecto es muy raro (o desconocido).
    Aquí es más normal, dedicar una persona a cada proyecto, y que haga lo que pueda, y además se le interrumpe para que “switchee en multi-tarea” si surge alguna tarea de mantenimiento con otro proyecto que también hizo, o que él conoce.

    Ahora no me puedo quejar (o no mucho), pero en los 5 años que llevé el departamento de otra empresa (50-60 programadores)… los proyectos más grandes nunca tuvieron más de 3 personas (aunque eran operaciones comerciales de facturación más que respetable, pero ese es otro tema), y el “switcheo” y las emergencias eran la norma.

    No se si os puede servir, porque cada empresa tiene sus cosas, pero apuntaría: compartir con el resto (comercial, gerencia…) la necesidad de respetar iteraciones y no interrumpirlas. Una plataforma técnica homogénea usada en todos los proeyctos (motor de integración continua, control de código y plataforma de pre-producción para dejar los incrementos “terminados” y que se puedan validar al final de cada iteración). Coordinación de sprints por grupos de 4 a 6 personas (estén en 3, 4 o 6 proyectos, pero NO una persona en varios): pero tratando igualmente las historias que se van a hacer, su descomposición y estimación al inicio, porque todas las aportaciones de unos a otros, sugerencias de enfoque de cada historia… se comparten igual en equipo. Quizá pueda ser un criterio para agrupar estos equipos, el que tengan el mismo comercial, para que sea el mismo propietario de producto en el sprint y pueda decidir qué historias de sus cuentas de proyectos va a tener. Esto obliga a que los proyectos de cada grupo vayan a hacer un sprint de igual duración….

    Desde luego, no es fácil.

    Un saludo, y lo mejor para 2009!.

  • 12. Luis Artola  |  diciembre 31st, 2008 at 9:04 am

    Hola Juan,

    encantado de verte por aquí! :-D

    Entiendo que los consejos que das van en la dirección de homogeneizar todos los proyectos lo máximo posible de tal manera que el cambio entre ellos suponga el menor tedio para el desarrollador. Como dices, no es fácil, pero creo que vale la pena ingeniárselas para intentarlo :-D

  • 13. Miguel  |  enero 10th, 2009 at 6:53 pm

    Luis, los tecnicos suelen formar equipos de generalmente 2, que normalmente llevan varios proyectos juntos, así se suelen cubrir unos a otros, y en general se ayudan en varias cosas.
    Por supuesto los equipos rotan, pero se hace caoticamente, ya que cuando un miembro del equipo se queda libre, puede compartir proyecto con otro compañero.

    Juan comenta 2 cosas interesantes. 1.- Compartir con los comerciales el respeto por los sprints. A veces es duro ya que tienes que pelearlo, pero se van dando cuenta que aunque a veces les demos tortas, se les proporciona una seguridad de fechas y calidad que antes no tenian, y despues de un tiempo son ellos los que te obligan a llevar la metodologia.

    2.-Fundamental la coordinacion para descomposicion, estimacion y final de sprint. Mucho cuidado con acumular sprints para una persona, ya que no podra llegar a todos.

    Saludos!

  • 14. Emilio Bravo  |  enero 20th, 2009 at 11:15 am

    Hola, espero no llegar muy tarde :-D .
    Nosotros usamos la misma técnica que ha comentado Miguel. Tenemos un backlog para cada proyecto y es en la pila del Sprint donde vamos metiendo lo que cabe de cada proyecto.
    Para la gestión de los proyectos usamos Jira acompañado del correspondiente tablón.
    Para la comunicación con la gerencia(comerciales)seria conveniente poner un “guardian” que fuera el único canal de comunicación con el equipo, de esta manera tenemos controladas las posibles interrupciones.

    Saludos.

  • 15. Luis Artola  |  enero 21st, 2009 at 11:32 am

    Hola Emilio,

    para nada llegas tarde! Lo que comentas de los “guardianes” o “responsables” me parece básico. Siempre tiene que haber una sola voz, y más si es cara al cliente… ;-)

    me apunto tu blog!

Comenta el articulo:

Requerido

Requerido,