project management - fases - ¿Cómo funciona Scrum cuando tienes múltiples proyectos?

metodologia scrum fases (10)

Como dijo @Chris, un proyecto normal tiene subproyectos dentro. Sin embargo, solo tienes una acumulación.

Piense en una acumulación de todos sus proyectos. Primer problema: ¿asigna prioridades a tareas o proyectos? Prefiero una acumulación por proyecto. Al menos tener claras las prioridades que tiene el dueño del producto.

Tener diferentes propietarios de productos, y debido al hecho de que los propietarios de los productos no van a acordar cuánto tiempo deben dar a cada proyecto. "Alguien" tendrá que absorber la decisión sobre cómo gestionar las prioridades entre proyectos. Nota: los desarrolladores no deberían hacerlo.

Aquí viene nuestro gerente del proyecto "S" que equilibrará los recursos que los propietarios de productos necesitan y el tiempo que pueden dar los miembros del equipo. El propietario del producto A pagó un mes de trabajo, pero el propietario del producto B siempre está actualizando su proyecto (y también le está pagando bien). Hay alguna forma en que equilibrarás a tu equipo para que A tenga su mes (tiempo de desarrollador), y no dejes que B te llene los bolsillos.

En el caso del software interno (una empresa, mil proyectos). Los diferentes propietarios de productos deben acordar el tiempo que se les otorga. No viven aislados, sino en el mismo barco que usted (gerente del proyecto "S"). Le facilitarán la vida al posponer algunas tareas, pero al mismo tiempo, nunca debe olvidar sus necesidades.

Bueno, todavía estoy tratando de descubrir la mejor manera de hacer esto. Pero esto es lo que estamos presionando en este momento. Espero que ayude.

Estoy bastante bien informado sobre los beneficios y procesos de Scrum. Obtengo las ideas en el registro acumulado, los diagramas quemados, las iteraciones, el uso de historias de usuario y otros varios conceptos del "marco" de Scrum.

Con eso dicho ... Trabajo para una empresa de desarrollo web que maneja múltiples proyectos a la vez, con seis miembros del equipo que conforman el "equipo de producción".

¿Cómo funciona Scrum al tener múltiples proyectos? ¿Todavía planifica una iteración para un solo proyecto en un cierto período de tiempo y todo el equipo trabaja en él, y luego pasa al siguiente proyecto con una nueva iteración cuando se completa esa iteración? ¿O existe una forma "ágil" de gestionar proyectos múltiples con sus propias iteraciones con un solo equipo al mismo tiempo?

Creo que Anopres tenía razón: la mejor manera es evitar proyectos múltiples al mismo tiempo con scrum. Haga todo lo posible para conveniencia de que correr demasiado en paralelo no es eficiente.

Supongamos 5 proyectos cada uno de aproximadamente 3 meses para un equipo con 5 personas.

Enfoque 1: cada persona trabaja en un solo proyecto en equipo

La velocidad de entrega de 1/5 por proyecto brinda 15 meses de entrega para todos los proyectos
Cada persona es experta pero solo en su propio proyecto
Sin espíritu de equipo

Enfoque 2: 1 carrera por proyecto, proyectos de cambio

Cada 6to sprint trabaja en proyecto
Demasiado tiempo entre el trabajo del proyecto, no el valor incremental regular del proyecto (para el retraso acumulado del producto sí), fácil de olvidar, esfuerzo necesario para restaurar el contexto,
Primer proyecto entregado después de aproximadamente 12-13 meses (suponiendo 2 semanas de sprint)

Enfoque 3: 5 proyectos en sprint individual

Requiere demasiada división detallada de tareas solo para adaptarse al sprint
Muy poca construcción incremental por proyecto
Entrega del primer proyecto después de unos 12-15 meses

Método 4: recomendado: trabajo serializado

El equipo trabaja en un solo proyecto después del proyecto
Primer proyecto iniciado y entregado después de 3 meses
El segundo proyecto comenzó después del 3er mes, entregado después del 6º mes
...
El quinto proyecto comenzó después del 12º mes, entregado después del 15º mes
Equipo altamente enfocado en proyectos, investigación intensiva y colaboración con el cliente
Todo el equipo tiene un buen conocimiento general sobre todos los proyectos
Sin perder tiempo en el cambio de contexto
Exigir una buena cooperación del equipo (los conflictos pueden ralentizar la entrega).

Como puede ver, la solución 4 generalmente es mejor porque los proyectos se entregan mucho más rápido, el equipo trabaja en conjunto y es eficiente. Otros enfoques incluyen el tiempo perdido a partir del cambio de contexto, la falta de colaboración total del equipo, el tiempo de entrega total muy largo de todos los proyectos, etc.

¿Y qué hay de la preparación del backlog? Si el equipo trabaja en un solo proyecto a la vez, es simple: todos se unirán. Si hay varios proyectos, es posible que necesitemos delegar personas individuales en sesiones separadas de preparación (no se trata de un equipo completo).

Es importante convencer a los clientes de que comenzar el segundo proyecto después de 3 meses dará como resultado una entrega más rápida (después del 6º mes) en lugar de iniciarlo inmediatamente con todos los demás. Es una ilusión que ven los gerentes: comenzamos 5 proyectos a la vez, trabajamos duro y entregamos poco a poco. Al final, esto no es eficiente sin embargo.

Es por eso que no creo que el scrum sea eficiente para múltiples proyectos en paralelo, es muy complicado combinarlo en el framework y trabajar de acuerdo con las reglas de scrum. A veces puede ser bueno tener 2 proyectos para mantener a todas las personas ocupadas, pero cuantos más proyectos agreguemos, menos eficiente será el scrum. Quizás kanban es una alternativa solo para ver el progreso y el trabajo en equipo (¿no tan fuerte como en el equipo de Scrum)?

Saludos, Adam

Creo que la respuesta depende de " quién priorizará los elementos atrasados " (es decir, decida qué se debe hacer primero). Si se trata de una persona soltera, esta persona es el Propietario del producto para sus proyectos, y puede tener una sola acumulación de todos los elementos, o una acumulación por proyecto, y seleccionar los elementos atrasados de todos los proyectos cuando planifique un Sprint. En este caso, Scrum "funciona" bien.

Si cada proyecto tiene su responsabilidad, entonces es probable que encuentre algunos problemas en los que cada responsable, de forma más o menos consciente, trate de favorecer su (s) proyecto (s). En mi humilde opinión, deberá tener un Propietario de Producto solo con la autoridad para resolver las prioridades por arbitraje.

Una regla que se debe seguir en dicho contexto es nunca cambiar el contenido de Sprint durante el Sprint . Si es necesario, puede acortar la iteración a dos o tres semanas para reducir el riesgo de tener que agregar un elemento urgente en el Sprint actual.

Hay otra opinión sobre la que he estado leyendo últimamente, a saber, que en un entorno Ágil, el concepto de Proyecto podría ser contraproducente y podría eliminarse. De acuerdo con esta línea de pensamiento, la organización debería centrarse en las versiones en su lugar. Esto se debe a que los Proyectos son cajas de trabajo artificiales que no producen ningún valor hasta que se terminan. Son contrarios al objetivo de Agile de entregar con frecuencia el valor de envío. Una versión está más en línea con Agile porque está orientada a ofrecer valor y porque su alcance se puede reducir o ampliar en función de lo que los equipos puedan ofrecer antes de la próxima versión .

Existe un terreno intermedio potencial, en el que lo que antes se llamaba un proyecto en su empresa ahora se vuelve a empaquetar como el tema o característica Agile común. El beneficio de este enfoque es que el tema o característica ahora se puede implementar en piezas de valor, según lo considere el propietario del producto.

Todavía está la cuestión de que un equipo trabaje en múltiples Productos , y es una pregunta debido a preocupaciones legítimas sobre el conocimiento del dominio y las posibles habilidades técnicas. Pero los productos construidos con Agile, incluso los productos múltiples construidos por un solo equipo, están acumulando constantemente valor de capacidad. Por el contrario, los proyectos no valen nada hasta que terminan (y muchos no).

Algo sobre lo que pensar...

He estado en esta situación precisa.

Si tiene un propietario de producto en todos los proyectos, entonces Phillipe es absolutamente correcto; Un sprint con un equipo debería funcionar bien.

Si tiene más de un propietario de producto, lo ideal es que el lado comercial elija un solo "priorizador" al que se le otorgue la responsabilidad de programar el trabajo. Esta es definitivamente la mejor solución.

Si (como probablemente sea el caso) la empresa no quiere cambiar la forma en que quieren priorizar las cosas (que sería demasiado conveniente), entonces puede dividir el equipo., Y ejecutar dos sprints concurrentes. Sin embargo, con un equipo de seis, no lo dividiría en más de 3 equipos (no me gustaría dividirlo en absoluto, pero creo que 2-3 equipos serían factibles). Dividir más lejos como sugiere Kenny, y tener equipos de una sola persona me parece un tanto inútil, ya que entonces ya no tienes un equipo, solo programadores individuales.

Si está dividiendo el equipo, no he encontrado mucho valor en la fusión de los stand-ups, a menos que tenga sprints separados que trabajen en gran parte de la misma base de código, pero entonces ese puede ser un argumento para unir esos equipos con el propósito de el sprint.

Los miembros del equipo pueden dividir su tiempo entre proyectos de scrum, pero es mucho más productivo tener miembros del equipo completamente dedicados. Los miembros del equipo también pueden cambiar de una carrera a la siguiente, pero eso también reduce la productividad del equipo. Los proyectos con equipos más grandes se organizan como scrums múltiples, cada uno centrado en un aspecto diferente del desarrollo del producto, con una estrecha coordinación de sus esfuerzos.

Me gustaría contribuir. Esta es la forma en que lo hago:

Hay un propietario de producto y una cartera de pedidos de producto por equipo. El propietario del producto no tiene que ser una sola persona, pero esta "entidad" propietaria del producto está a cargo de la acumulación de productos.
La acumulación de productos tiene las historias de los usuarios de cada proyecto (todos los proyectos aquí). Cada historia de usuario tiene un esfuerzo / puntos de historia (responsabilidad del equipo) y un valor comercial (responsabilidad del propietario del producto).
Tenemos una reunión de "preparación del backlog del producto" cada sprint. Antes de esta reunión, el propietario del producto ha actualizado los valores comerciales de las historias (si necesitan algún cambio por cualquier razón comercial, que no nos importa o no) e incluye algunas historias nuevas. En esta reunión, se explican las nuevas historias y también se actualizan los esfuerzos. Esta reunión dura aproximadamente una hora (excepto la primera vez, aproximadamente 4 horas).
Cuando planifiquemos un nuevo sprint, abrimos la cartera de pedidos del producto, ordenamos las historias por ROI (esto es valor / esfuerzo comercial) y planificamos las historias hasta que se acabe el tiempo.

Y eso es. Puedo decir que esto funciona bastante bien. Usamos un par de hojas de cálculo de google (la acumulación de producto y las de retraso acumulado, ambas con gráficos y demás) para hacer esto, y redmine (con una semántica específica) para una organización en línea todos los días: tiempo, progreso de la tarea, etc.

El problema con este enfoque es que he duplicado las tareas en la hoja de cálculo de acumulación de sprints y redmine. Pero no encuentro ninguna herramienta en línea para hacer esto completamente en línea. Extraño una cartera de pedidos de productos en redmine (no hay otros trabajos semánticos para mí), una sola placa en jira, más historias en taiga, etcétera

Scrum realmente no dicta que deba trabajar en un producto autónomo. Simplemente indica que hay un montón de cosas que se deben hacer (la acumulación de productos), hay una cierta cantidad de tiempo de desarrollo disponible en la próxima iteración (calculada a partir de la velocidad del proyecto) y hay elementos seleccionados por el cliente. / negocio como la prioridad más grande de este conjunto de problemas / tareas que se realizará en la próxima iteración (la acumulación de sprints).

No hay ninguna razón para que el retraso acumulado del producto y el retraso acumulado tengan que ser del mismo proyecto, incluso en un solo proyecto habrá unidades de trabajo discretas que son como proyectos separados: la interfaz de usuario, la capa empresarial, el esquema de la base de datos, etc. El desarrollo de software empresarial en particular es así, donde tienes una cantidad de bases de código que todos tienen que progresar. El proceso de Scrum (reuniones, preguntas, diagrama de grabación, etc.) funciona tanto si es un proyecto como si es múltiple.

Dicho esto, en la práctica, a menudo es bueno que cada iteración tenga un tema principal: "hacer el módulo de informes" o "interfaz con la API del sistema XYZ", de modo que muchos de los problemas provienen de un proyecto o área y en el Al final de la iteración puede señalar un gran cuerpo de trabajo y colocar un tic en su contra.

Sugeriría ejecutar un Sprint para cada proyecto y tener 1 reunión standup diaria para manejar todos los resort / proyectos activos.

Tengo que estar en desacuerdo. Creo que es clave para el proceso tener un equipo enfocado en un solo proyecto durante un sprint. Si tiene algunos especialistas que no pueden contribuir con todo el proceso de desarrollo (autores de contenido, personas de gráficos, analistas de procesos de negocios, etc.) los eliminaría del equipo cuando ya no puedan contribuir. O mejor aún, capacítelos en algunas tareas diferentes para que puedan contribuir a cosas como las pruebas.

Otra cosa a tener en cuenta es que ejecutar proyectos en paralelo mata su agenda. Considere esto: para simplificar, digamos que tenemos 5 proyectos usando el mismo equipo y comenzando en la misma fecha. Cada proyecto necesita 3 meses de esfuerzo. En el mejor de los casos, en paralelo, los terminará todos a la vez y demorará 15 meses. Su velocidad se reducirá debido a que solo puede adaptarse a 1/5 de un mes de esfuerzo en un solo sprint. También realizarás 5 reuniones de demostración, todas al mismo tiempo. Entonces, en el mejor de los casos, entregará sus 5 proyectos en 15 meses y su competencia alegará que podrían hacer el mismo trabajo en 3. Los equipos que estiman la madurez sufrirán porque solo podrán considerar el 20% de su mano de obra disponible. Es posible que no pueda realizar algunas tareas en un solo sprint. Si tiene que cambiar la cantidad de proyectos que se están trabajando desde 5, su equipo tendrá que ajustar sus hábitos de estimación, lo que dañará la eficiencia de los equipos. Además, a su equipo le resultará difícil autoorganizarse cuando una simple reasignación de tareas pueda requerir la creación de un nuevo entorno de desarrollo antes de que pueda comenzar el trabajo.

Si tuviera que ejecutar los mismos 5 proyectos en serie, entregaría el 5to proyecto en los mismos 15 meses, pero habría informado a su cliente que su equipo tiene tanta demanda que tiene un retraso de 12 meses y que puede usar ese momento para refinar los objetivos de su proyecto. O si tiene un atraso constante, sabe que es hora de comenzar a contratar a otro equipo. Sin embargo, su mejor proyecto finaliza en 3 meses con un cliente que ha experimentado mejoras rápidas durante el período activo. Puedes terminar ese proyecto un año antes y puedes ponerlo en tu currículum. La velocidad de tu velocidad se estabilizará durante ese período de tiempo y es posible que encuentres que da un paso adelante después de uno o dos proyectos y logras más en un sprint dado.

Creo que ejecutar proyectos en serie es uno de los mayores obstáculos que una organización intenta adoptar. Es un cambio cultural importante asociado con la deconstrucción del rol de gerente de proyecto, pero los beneficios para el proceso de scrum son enormes.

Tenga en cuenta que TODO EL MUNDO no necesita ser un miembro completo del equipo. Pueden involucrar a su cliente en la sala de espera, preparándose para el proceso de desarrollo. Mantengo a mis analistas de negocios, arquitectos de redes y personas de diseño gráfico como expertos de dominio y solo los adjunto a un equipo según sea necesario. Deje que se ejecuten con Sprint 0. Se sorprenderá de lo atractivo que es trabajar en la apariencia y el flujo de trabajo. También es bueno preparar a su cliente con la comprensión de que cuando el desarrollo comienza en serio, su nivel de participación puede aumentar y que es importante que esté disponible. Hágales saber el horario para que tengan tiempo de sobra para ocuparse de cosas como vacaciones y días festivos con bastante anticipación.