¿Cómo funciona Scrum cuando tienes varios proyectos? [cerrado]

Conozco bastante bien los beneficios y procesos de Scrum. Obtengo las ideas sobre el backlog, los gráficos de evolución, las iteraciones, el uso de historias de usuario y otros conceptos diversos del "marco" de Scrum.

Dicho esto ... trabajo para una empresa de desarrollo web que gestiona varios proyectos a la vez, con seis miembros del equipo que forman el "equipo de producción".

¿Cómo funciona Scrum teniendo múltiples proyectos? ¿Todavía solo programa una iteración para un solo proyecto en una cierta cantidad 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 hay una forma "ágil" de gestionar varios proyectos con sus propias iteraciones con un solo equipo al mismo tiempo?

Scrum realmente no dicta que tengas que trabajar en un producto autónomo. Simplemente indica que hay un montón de cosas que deben hacerse (la acumulación del producto), hay una cierta cantidad de tiempo de desarrollo disponible en la siguiente iteración (calculada a partir de la velocidad del proyecto) y hay elementos seleccionados por el cliente. / business tiene la mayor prioridad de este grupo de problemas / tareas que se realizarán en la próxima iteración (el backlog del sprint).

No hay ninguna razón por la que la acumulación de productos y la acumulación de sprints tengan que ser de un solo 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 tiene una serie de bases de código que deben progresar. El proceso de Scrum (reuniones, preguntas, tabla de grabación, etc.) funciona, ya sea en un proyecto o en varios.

Habiendo dicho eso, en la práctica a menudo es bueno que cada iteración tenga un tema principal: "hacer el módulo de informes" o "interactuar con la API del sistema XYZ", de modo que muchos de los problemas provengan de un proyecto o área y en el Al final de la iteración, puede señalar un gran volumen de trabajo y colocar una marca contra él.

Creo que la respuesta depende de " quién dará prioridad a los elementos de la cartera de pedidos " (es decir, decidir qué se debe hacer primero). Si se trata de una sola persona, entonces esta persona es el propietario del producto para sus proyectos, y puede tener un solo trabajo pendiente para todos los elementos de todos los proyectos, o un trabajo pendiente por proyecto, y puede seleccionar los elementos del trabajo pendiente de todos los proyectos cuando planifique una carrera. En este caso, Scrum "funciona" bien.

Si cada proyecto tiene su responsable, es probable que encuentre algunos problemas en los que cada responsable, más o menos conscientemente, tratará de favorecer su (s) proyecto (s). En mi humilde opinión, necesitará tener un propietario de producto solo con la autoridad para resolver las prioridades mediante arbitraje.

Una regla que se debe seguir en tal contexto es nunca cambiar el contenido del 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.

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 a todo el proceso de desarrollo (autores de contenido, gente de gráficos, analistas de procesos de negocio, etc.), los sacarí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: por simplicidad, 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, si se ejecuta en paralelo, los terminará todos de una vez y tardará 15 meses. Su velocidad se reducirá porque solo puede realizar 1/5 de un mes de esfuerzo en un solo sprint. También realizarás 5 reuniones de demostración al mismo tiempo. En el mejor de los casos, entregas tus 5 proyectos en 15 meses y tu competencia afirmará que podrían hacer el mismo trabajo en 3. Tus equipos que estiman la madurez sufrirán porque solo podrán considerar el 20% de su mano de obra disponible. Es posible que descubra que en realidad no puede realizar algunas tareas en un solo sprint. Si tiene que cambiar el número de proyectos que se están trabajando de 5, su equipo tendrá que ajustar sus hábitos de estimación, lo que dañará la eficiencia del equipo. Además, a su equipo le resultará difícil organizarse por sí mismo cuando una simple reasignación de tareas requiera poner en marcha 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 quinto proyecto en los mismos 15 meses, pero habría informado a su cliente de que su equipo tiene tanta demanda que tiene una acumulación de 12 meses y que puede usar ese momento para refinar los objetivos de su proyecto. O si tiene una acumulación constante, sabe que es hora de comenzar a contratar a otro equipo. Su mejor proyecto, sin embargo, está terminado en 3 meses con un cliente que ha visto mejoras rápidas durante el período activo. Puede terminar ese proyecto un año antes y puede incluirlo en su currículum. Su velocidad de sprint se estabilizará durante ese período de tiempo y es posible que descubra que alcanza su ritmo después de un proyecto o dos y puede lograr más en un sprint determinado.

Creo que ejecutar proyectos en serie es uno de los mayores obstáculos para una organización que intenta adoptar caras de scrum. 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 TODOS no necesitan 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 personal de diseño gráfico como expertos en el dominio y solo los adjunto a un equipo cuando sea necesario. Déjelos correr con el 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 entendiendo 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 suficiente tiempo para lidiar con cosas como vacaciones y días festivos con mucha anticipación.

He estado en esta situación precisa.

Si tiene un propietario de producto en todos los proyectos, Phillipe tiene toda la razón; Un sprint con un equipo debería funcionar bien.

Si tiene más de un propietario de producto, lo ideal es que la parte empresarial deba elegir un único "priorizador" a quien se le asigne 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 (eso sería demasiado conveniente), entonces puede dividir el equipo y ejecutar dos sprints simultáneos. Sin embargo, con un equipo de seis, no lo dividiría en más de 3 equipos (no quisiera dividirlo en absoluto, pero creo que 2-3 equipos serían factibles). Dividir más, como sugiere Kenny, y tener equipos de una sola persona me parece algo inútil, ya que entonces ya no tienes un equipo, solo programadores individuales.

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

Hay otra opinión sobre la que he estado leyendo últimamente, a saber, que en un entorno ágil el concepto de Proyecto puede ser contraproducente y podría eliminarse. Según esta línea de pensamiento, la organización debería centrarse en las versiones . Esto se debe a que los Proyectos son cajas de trabajo artificiales que no producen ningún valor hasta que se terminan. Son contrarias al objetivo de Agile de ofrecer valor de envío frecuente. 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 expandir en función de lo que los equipos puedan entregar antes de la próxima versión .

Existe un término medio 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 Ágil 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 oportuno el propietario del producto.

Todavía existe la cuestión de que un equipo trabaje en varios Productos , y es una cuestión debido a preocupaciones legítimas sobre el conocimiento del dominio y las posibles habilidades técnicas. Pero los productos creados con Agile, incluso varios productos creados por un solo equipo, acumulan constantemente valor de lanzamiento . Por el contrario, los proyectos no valen nada hasta que se terminan (y muchos no).

Algo sobre lo que pensar...

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

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

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

• 1/5 de velocidad de entrega por proyecto da 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 sprint por proyecto, cambiando proyectos

• Cada sexto sprint trabaja en un proyecto
• Demasiado tiempo entre el trabajo del proyecto: no es un valor incremental regular para el proyecto (para la acumulación de productos, sí), fácil de olvidar, se necesita esfuerzo para restaurar el contexto,
• Primer proyecto entregado después de aproximadamente 12-13 meses (asumiendo 2 semanas de sprint)

Enfoque 3: 5 proyectos en un solo sprint

• Requiere una división de tareas demasiado detallada solo para encajar en el sprint
• Muy poca construcción incremental por proyecto
• Entrega del primer proyecto después de unos 12-15 meses.

Enfoque 4: recomendado - Trabajo serializado

• El equipo trabaja en un solo proyecto tras proyecto
• Primer proyecto iniciado y entregado después de 3 meses
• El segundo proyecto comenzó después del tercer mes, se entregó después del sexto mes
• ...
• El quinto proyecto comenzó después del mes 12, se entregó después del mes 15
• 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.
• No pierda tiempo cambiando de contexto
• Requiere una buena cooperación del equipo (los conflictos pueden ralentizar la entrega).

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

¿Y qué hay de la preparación de los trabajos pendientes? Si el equipo trabaja en un solo proyecto a la vez, es simple: todos se unirán. Si hay varios proyectos, es posible que debamos delegar a personas solteras en sesiones de preparación separadas (no está involucrado todo el equipo).

Es importante convencer a los clientes de que comenzar el segundo proyecto después de 3 meses aún resultará en una entrega más rápida (después del sexto mes) en lugar de comenzar inmediatamente con todos los demás. Es una ilusión lo que ven los gerentes: comenzamos 5 proyectos a la vez, trabajamos duro y los entregamos poco a poco. Sin embargo, al final, esto no es eficaz.

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

Saludos, Adam

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

Piense en un backlog con todos sus proyectos. Primer problema: ¿estás asignando prioridades a tareas o proyectos? Prefiero un backlog por proyecto. Al menos para tener claras las prioridades que tiene el product owner.

Tener diferentes propietarios de productos, y debido a que esos propietarios de productos no se van a poner de acuerdo sobre cuánto tiempo deben dedicar 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 de proyecto "S" que equilibrará los recursos que los propietarios de productos necesitan y el tiempo que los miembros del equipo pueden dar. El propietario del producto A pagó por un mes de trabajo, pero el propietario del producto B siempre actualiza su proyecto (y también le paga bien). De alguna manera equilibrarás a tu equipo para que A tenga su mes (tiempo de desarrollador) y no impida 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 concede. No viven aislados, sino en el mismo barco que tú (director del proyecto "S"). Te facilitarán la vida al poder posponer algunas tareas, pero al mismo tiempo nunca debes olvidar sus necesidades.

Bueno, todavía estoy tratando de encontrar la mejor manera de hacer esto. Pero esto es lo que estamos impulsando ahora mismo. Espero que ayude.

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 un sprint al siguiente, pero eso también reduce la productividad del equipo. Los proyectos con equipos más grandes se organizan como múltiples scrums, cada uno centrado en un aspecto diferente del desarrollo del producto, con una estrecha coordinación de sus esfuerzos.

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

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

• Hay un propietario de producto y una cartera de productos por equipo. El propietario del producto no tiene que ser una sola persona, pero esta "entidad" del propietario del producto está a cargo de la acumulación del producto.
• La cartera de productos tiene las historias de usuario de cada proyecto (todos los proyectos aquí). Cada historia de usuario tiene puntos de esfuerzo / historia (responsabilidad del equipo) y un valor comercial (responsabilidad del propietario del producto).
• Tenemos una "preparación de la cartera de productos" que se adapta a 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 y no debería importarnos) e incluir algunas historias nuevas. En este encuentro se explican las nuevas historias y se actualizan los esfuerzos. Esta reunión dura aproximadamente una hora (excepto la primera vez, aproximadamente 4 horas).
• Cuando vamos a planificar un nuevo sprint, abrimos la cartera de productos, 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 (el backlog del producto y el backlog del sprint, ambos 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 la lista de trabajos pendientes del Sprint y en redmine. Pero no encuentro ninguna herramienta en línea para hacer esto completamente en línea. Extraño una cartera de productos en redmine (ninguna otra semántica funciona para mí), un solo tablero en jira, más historias en taiga, etcétera.