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

Creo que la respuesta depende de " quién priorizará los elementos atrasados" (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 backlog will todos los elementos para todos los proyectos, o un backlog por proyecto, y seleccione los elementos backlog de todos los proyectos cuando planifique un Sprint. En este caso, Scrum "funciona" bien.

Si cada proyecto tiene su responsable, entonces es probable que encontrar algunos problemas donde cada responsable - más o menos conscientemente-tratar de favorecer su proyecto(s). En mi humilde opinión, usted tendrá que tener un solo Propietario del Producto con la autoridad para resolver las prioridades por arbitraje.

Una regla que debe seguirse 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 tienes 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.) Me arrastraban fuera del equipo cuando ya no pueden contribuir. O mejor aún, haz que se entrenen 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 tu agenda. Considere esto: por simplicidades, 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 corriendo en paralelo, los terminarás todos a la vez y tomará 15 meses. Tu velocidad se pondrá cremosa porque solo puedes caber 1/5 de un mes de esfuerzo en un solo sprint. También estarás haciendo 5 reuniones de demostración al mismo tiempo. Así que el mejor de los casos escenario, usted entrega sus 5 proyectos en 15 meses y su competencia estará afirmando que podrían hacer el mismo trabajo en 3. Sus equipos que estimen la madurez sufrirán porque solo podrán considerar el 20% de su mano de obra disponible. Es posible que en realidad no pueda 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 autoorganizarse cuando una simple reasignación de tareas puede 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 5º proyecto en los mismos 15 meses, pero habría informado a su cliente de que su equipo tiene una demanda tal que tiene un retraso de 12 meses y que puede usar ese tiempo para refinar los objetivos de su proyecto. O si tienes un retraso constante, sabes que es es hora de empezar a contratar otro equipo. Su mejor proyecto, sin embargo, se termina en 3 meses con un cliente que ha visto mejoras rápidas durante el período activo. Usted es capaz de terminar ese proyecto un año antes y puede ponerlo en su curriculum vitae. Su velocidad de sprint se estabilizará durante ese período de tiempo y usted puede encontrar que golpea su zancada después de un proyecto o dos y son capaces de lograr más en un sprint dado.

Creo que ejecutar proyectos en serie es uno de los mayores obstáculos 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 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 en dominios y solo los asocio a un equipo según sea necesario. Dejar corren con sprint 0. Te sorprendería lo atractivo que es trabajar en la apariencia y el flujo de trabajo. También es bueno preparar a su cliente con el entendimiento de que cuando el desarrollo comienza en serio, su nivel de participación puede aumentar y que es importante que estén disponibles. Hágales saber el horario para que tengan mucho tiempo para lidiar con cosas como vacaciones y días festivos con mucha anticipación.

He estado en esta situación precisa.

Si tienes 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 el lado empresarial elija un solo 'priorizador' al que se le dé la responsabilidad de programar el trabajo. Esta es definitivamente la mejor solución.

Si (como es probablemente el caso) la empresa no quiere cambiar cómo ellos quieren priorizar las cosas (que sería demasiado conveniente) entonces se 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 me gustaría dividirlo en absoluto, pero creo que 2-3 equipos serían viables). Dividir más como Kenny sugiere, y tener equipos de una sola persona me parece algo inútil, ya que entonces ya no tienes un equipo, solo programadores individuales.

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

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 Liberaciones en su lugar. Esto se debe a que Los proyectos son cajas artificiales de trabajo que no producen ningún valor hasta que están terminados. Son contrarios al objetivo de Agile de entregar con frecuencia valor de envío. A Release está más en línea con Agile porque está orientado hacia la entrega de valor y porque su alcance puede reducirse o expandirse en función de lo que los equipos pueden entregar antes de la próxima Versión.

Existe un potencial término medio, en el que lo que antes se llamaba un Proyecto en su empresa ahora se vuelve a empaquetar como el Tema común Agile o Característica . El beneficio de este enfoque es que el Tema o la característica ahora se pueden implementar en partes de valor, como el propietario del producto lo considere conveniente.

Todavía existe la cuestión de que un equipo trabaje en múltiples Productos , y es una cuestión debido a preocupaciones legítimas sobre el conocimiento del dominio y las posibles habilidades técnicas. Pero Productos construidos con Agile, incluso múltiples Productos construidos por un solo equipo, están acumulando constantemente Release -able valor. En contraste, Los proyectos no valen nada hasta que terminan (y muchos no lo hacen).

Algo en 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 convenience que correr demasiado en paralelo no es eficiente.

Asumamos 5 proyectos cada uno de aproximadamente 3 meses para el equipo con 5 personas.

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

• 1/5 velocidad de entrega por proyecto da 15 meses de entrega para todos los proyectos
• Cada persona es experta, pero solo en sí misma proyecto
• No hay espíritu de equipo

Enfoque 2: 1 sprint por proyecto, proyectos de conmutación

• Cada 6º sprint trabaja en el proyecto
• Demasiado tiempo entre el trabajo del proyecto - valor incremental no regular para el proyecto (para el backlog de productos 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 un solo sprint

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

Enfoque 4: trabajo serializado recomendado

• El equipo trabaja en un proyecto tras otro
• Primer proyecto iniciado y entregado después de 3 meses
• El segundo proyecto comenzó después del 3er mes,entregado después del 6to mes
• ...
• el 5o proyecto comenzó después del mes 12, entregado después del mes 15 mes
• Equipo altamente centrado en el proyecto, la investigación intensiva y la colaboración con el cliente
• Todo el equipo tiene un buen conocimiento general sobre todos los proyectos
• No hay pérdida de tiempo en el cambio de contexto
• Requiere una buena cooperación de 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 de cambio de contexto, no completa colaboración en equipo, tiempo de entrega total muy largo de todos los proyectos, etc.

¿Y qué pasa con la preparación de 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 tengamos que delegar a personas solteras en sesiones de aseo separadas (no está involucrado el equipo completo).

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

Es por eso que no creo que scrum sea eficiente para múltiples proyectos en paralelo, es muy difícil emparejarlo en 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á scrum ser. Tal vez kanban es una alternativa solo para ver el progreso y el trabajo en equipo (no tan fuerte como en Scrum team)?

Saludos, Adam

Como dijo @Chris, un proyecto normal tiene subproyectos dentro. Solo tienes un atraso.

Piensa en un backlog con todos tus proyectos. Primer problema: ¿está asignando prioridades a tareas o proyectos? Prefiero un backlog por proyecto. Al menos tener claras las prioridades que tiene el propietario del producto.

Tener diferentes propietarios de productos, y debido al hecho de que esos propietarios de productos no van a ponerse de acuerdo sobre cuánto tiempo deben dar a cada proyecto. "Alguien" lo hará tener 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 está actualizando su proyecto (y también le paga bien). Hay un poco de cómo va a equilibrar su equipo para A tener su un mes (tiempo de desarrollador), y no dejar de B de llenar su bolsillo.

En el caso del software interno (una empresa, mil proyectos). Los diferentes propietarios de los productos deben ponerse de acuerdo sobre el tiempo que se les concede. No viven aislados, sino en el mismo barco que usted (gerente del proyecto"S"). Le harán la vida más fácil al poder posponer algunas tareas, pero al mismo tiempo nunca debe olvidar sus necesidades.

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

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

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

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

• Hay un propietario de producto y un backlog de producto por equipo. El propietario del producto no tiene que ser una sola persona, pero esta "entidad" del propietario del producto está a cargo del backlog del producto.
• El backlog de productos tiene las historias de usuario de cada proyecto (todos los proyectos aquí). Cada historia de usuario tiene un esfuerzo/puntos de historia (responsabilidad del equipo) y un valor de negocio (responsabilidad del propietario del producto).
• Tenemos un "producto backlog grooming " cumplir con 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 ni debería importarnos) e incluye algunas historias nuevas. En esta reunión se explican las nuevas historias y se actualizan los esfuerzos. Esta reunión dura aproximadamente una hora (excepto la primera vez, alrededor de 4 horas).
• Cuando vamos a planificar un nuevo sprint abrimos el backlog de productos, pedimos las historias por ROI (esto es valor / esfuerzo del negocio) y planifique historias hasta que el tiempo haya pasado.

Y eso es todo. Puedo decir que esto funciona bastante bien. Utilizamos un par de hojas de cálculo de Google (el backlog de productos y el backlog de sprint, ambos con gráficos y cosas) 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 sprint backlog y redmine. Pero no encuentro ninguna herramienta en línea para hacer esto completamente en línea. Echo de menos un backlog de productos en redmine (no hay otros trabajos semánticos para mí), un solo tablero en jira, más historias en taiga, etc