¿Cómo gestiona SCRUM un entorno en el que se comparten los miembros del equipo?

13

Bueno, las preguntas se dijeron por sí mismas. En mi lugar de trabajo, esos casos ocurren, pero también, muchos libros de Agile promueven trabajar en el mismo lugar de trabajo y concentrarse en el proyecto actual para acelerar el ritmo de trabajo.

Tal vez no estoy tan informado sobre el tema, tal vez no es tan estricto, pero es por eso que quería saber qué propone Agile en casos como esos.

¿Cualquiera?

Xanathos
fuente
1
¿Qué quieres decir con compartido? ¿Quiere decir que alguien puede pasar de un equipo a otro o que alguien puede estar trabajando en varios equipos a la vez? Esto afectaría mi respuesta.
pdr

Respuestas:

6

En la metodología Scrum simplemente afecta la estimación.

Asignaría el factor de enfoque para esa persona en función de la asignación de su tiempo a cada proyecto.

Entonces, si estoy trabajando en el Proyecto A y el Proyecto B por igual, el Proyecto A calcularía los recursos de esta manera:

Proyecto A : factor de enfoque del equipo del 70%
Sam: 10 días, asignación del 100% (7 después del factor de enfoque)
Joe: 10 días, asignación del 100% (7 después del factor de enfoque)
Yo: 10 días, asignación del 50% (3.5 después del factor de enfoque) )
Total: 25 días * 70% factor de enfoque = 17.5 velocidad proyectada

También puede calcular el factor de enfoque por separado para los miembros del equipo a tiempo completo y para los miembros del equipo a tiempo parcial en lugar de hacerlo una vez para todo el equipo, debido a la menor eficiencia de la división de proyectos. En este caso, usaría mi factor de enfoque del proyecto del 50% y lo multiplicaría por una asignación personal del 50% para el 25%, o la velocidad proyectada de 2.5 días .

Lo bien que esto funcione en la práctica será un factor de qué tan bien sabe de antemano cuánto tiempo pasará un recurso compartido en cada proyecto y qué tan bien Scrum está trabajando para usted de otras maneras.

Nicole
fuente
2
Mi problema al hacerlo de esta manera es que no tiene en cuenta el cambio de tareas muy bien. Por ejemplo, considere un sprint de 2 semanas (10 días). Tener un desarrollador con un factor de enfoque del 50%, donde lo consigas durante 5 días seguidos, es muy diferente a tener un desarrollador cada dos horas durante 10 días. El primero es mucho más productivo. Un ejemplo extremo, pero entiendes mi punto.
Brook
@Brook Estás hablando del factor de enfoque (1 medición por persona), que es diferente de la asignación del proyecto (en este caso, división 50/50). El factor de enfoque es el% de un día ideal que vale su día real . Por lo general, es aproximadamente del 70-80%, pero para alguien que divide proyectos, probablemente sería menos (lo que abordé en la respuesta). Depende de cierta consistencia en el tiempo. Si no puede tener consistencia, realmente ni siquiera debería estar haciendo Scrum.
Nicole
la parte de consistencia fue realmente mi punto. Si tienes un equipo en el que constantemente atraen a las personas en 10 direcciones diferentes, y no puedes cambiar eso, Scrum no te ayudará.
Brook el
@Brook: es un buen punto y me ayudaste a pensarlo de una manera que no tenía originalmente. Parece que estamos de acuerdo.
Nicole
1
@NickC Esto parece plausible de hacer. Por lo menos, soy consciente de que los miembros del equipo se pueden cambiar cada vez, afortunadamente no sucede tanto. El lugar de trabajo sigue siendo el mismo siempre, solo que el tiempo dado al proyecto es a veces la mitad de la capacidad del miembro del equipo (porque el miembro del equipo está haciendo tareas de 2 proyectos diferentes). Pero esto parece apropiado para calcular la velocidad de diferentes proyectos como mínimo. Gracias por la referencia
Xanathos
10

En mi experiencia en Scrum, la velocidad solo se puede predecir si el proyecto y el equipo siguen siendo los mismos y dedicados. Si alguna de estas cosas cambia, entonces no puedes usar cálculos de velocidad de sprints anteriores para hacer tu estimación. Puedes intentarlo, pero te irás mucho más de lo que normalmente lo harías.

En general, definitivamente debes tratar de mantener al equipo igual y dedicado al MENOS durante un sprint, más si puedes.

Arroyo
fuente
2
Si de hecho! Intentar compartir miembros entre proyectos solo da como resultado que todos los proyectos involucrados se retrasen. No tiene sentido dividir a las personas así y pensar que las cosas se completarán más rápido.
Martin Wickman el
+1 para el sentido común, simplemente no puede asignar a tres mujeres a un embarazo para hacerlo en tres meses. Tiene más sentido dedicar a las personas a una tarea específica.
maple_shaft
Creo que este es un "pilar central" de Scrum, en realidad. El cartel parece mezclar contexto cuando se pregunta "¿qué dice ágil en esta situación" (vs Scrum) ¿Hay una (no Scrum) respuesta ágil ...
Al Biglan
1

En mi opinión, esto afectará muy mal a todos los proyectos. No se trata solo de estimar o planificar. Sí, puede decir que si los miembros del equipo están asignados a tres proyectos y tienen una asignación del 33% para cada proyecto, usted sabe todo lo que necesita y ya está, pero eso no es cierto.

El cambio de contexto es muy costoso. También es imposible mantener un compromiso total con múltiples proyectos paralelos, de modo que el 33% de los porcentajes de tiempo del desarrollador están muy lejos del 33% cuando el desarrollador se asigna a un solo proyecto.

Otro lugar donde esto falla totalmente es la comunicación. ¿Qué sucede si un miembro del equipo que trabaja actualmente en el proyecto A debe comunicar algo con un miembro del equipo que trabajó en el proyecto A ayer pero que actualmente trabaja en el proyecto B? Eso es un impedimento para ambos porque el primero necesita información pero el segundo se concentra en un proyecto completamente diferente y cualquier pregunta para el proyecto A simplemente lo perturba. Scrum master del proyecto A quiere que su desarrollador obtenga información lo más rápido posible y Scrum master del proyecto B no quiere que su miembro del equipo se vea molesto por nada que no esté relacionado con el proyecto B. Si desea evitar esto, debe planificar todo Desarrolladores del equipo para trabajar en el mismo proyecto en los mismos días, lo cual es una gran complicación para todo el proceso de planificación y algo que debe evitarse por completo.

También debe planificar todas las reuniones para que no choquen. También debe comprender que la reunión es realmente un desperdicio y, por eso, debe haber un número mínimo requerido de reuniones lo más corto posible para mantener el control sobre el proceso. Pero si tiene un miembro del equipo trabajando en tres proyectos, debe participar en todas las reuniones para esos tres proyectos => tres veces más reuniones donde el desarrollador no produce ningún valor comercial.

Como conclusión ágil también se trata de reducir el desperdicio (sí, es del enfoque Lean) y compartir los miembros del equipo entre los equipos es una de las peores fallas en términos de introducir desperdicios y reducir la productividad. Supongo que el valor comercial entregado para la asignación del 33% a un solo proyecto será igual al valor comercial entregado del 10-16% de la asignación a tiempo completo. Eso significa que el desarrollador no solo participará 1/3 de tiempo en el proyecto, sino que durante ese tiempo su productividad estará entre 1/3 y 1/2.

Ladislav Mrnka
fuente
1

SCRUM se basa en tener un equipo comprometido sin miembros compartidos, por lo tanto, podría estar preguntando:

Dado que nos han dicho que debemos hacer verdadero == falso, ¿cómo hacemos x

Si no es SCRUM, ¡no lo llames SCRUM!

Ian
fuente
0

La pregunta clave es sobre el compromiso del miembro del equipo con el proyecto. Idealmente, un miembro del equipo debe estar totalmente comprometido con el éxito del proyecto. Esto no significa que su tiempo esté totalmente dedicado al proyecto, sino que esté disponible para hacer cualquier tarea que se requiera para el proyecto cuando esté trabajando en el proyecto.

A menudo, con personal que solo trabaja a tiempo parcial en un proyecto, solo está involucrado por un alcance limitado de compromiso. Por ejemplo, puede tener una persona que solo optimice la base de datos.

En ese caso, a menudo es mejor tratar a esa persona como un "recurso" en lugar de como un miembro del equipo. El equipo decide qué cantidad de ese recurso querrán en un Sprint en particular, y les da un conjunto muy específico de tareas para completar para el Sprint. A veces es mejor si el Equipo tiene un miembro del equipo en particular responsable de ese recurso, y harán las actualizaciones de estado y los informes de impedimentos para ese recurso en el Scrum diario.

Dave
fuente
0

Creo que uno de los aspectos centrales de Scrum es mantener al equipo enfocado en una cosa a la vez (un proyecto, una historia, una tarea ...)

Usted preguntó "qué propone Agile" en la situación en la que no puede asignar los recursos a un proyecto ... Puede considerar probar uno de:

  • Mantenga un gran tablero Kanban que abarque los múltiples proyectos. Como un proyecto tiene una necesidad, se agrega a la pizarra, ya que las personas tienen capacidad, extraen las historias clave. El problema es que todos los proyectos se gestionan juntos, lo que disminuye la previsibilidad general de cualquier proyecto. Dicho esto, la historia individual / los elementos Kanban serán extraídos y desarrollados por una persona o equipo enfocado. (Puede intentar crear equipos más pequeños de 4-5 personas para sacar del tablero Kanban
  • Solo asigne recursos comprometidos. Mantenga un grupo de recursos dedicados para un proyecto. Estos están protegidos como un equipo y las interrupciones se mantienen cerca de cero. También mantenga un "equipo de respuesta rápida" que no tenga una acumulación y no tenga un enfoque de proyecto / producto. A medida que surgen interrupciones, el equipo de respuesta rápida se ocupa de las interrupciones. Cuando no tienen interrupciones, pueden enfocarse en mejorar el sistema de compilación, agregar al marco de prueba de automatización, etc. Además, pueden ayudar con las revisiones de código / revisiones de diseño y la resolución de errores difíciles / desagradables que surgen. Gestiona el desarrollo como si este equipo no existiera. Todo lo que pueden hacer es tirar de la entrega. Rotar a las personas a través de este equipo para "mantenerlo fresco" (a la gente parece gustarle / odiar estar en el equipo de respuesta rápida ...)

¡espero que esto ayude!

Al Biglan
fuente