¿Cómo funciona Scrum cuando tienes múltiples proyectos? [cerrado]

Question

Soy bastante leído en los beneficios y procesos de Scrum. Obtengo las ideas sobre el trabajo acumulado, los gráficos de quemado, las iteraciones, el uso de historias de usuarios y otros conceptos del Scrum " framework " ;.

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

¿Cómo funciona Scrum con tener múltiples proyectos? ¿Sigues programando una iteración para un solo proyecto en una cierta cantidad de tiempo y todo el equipo trabaja en él, y luego pasas al siguiente proyecto con una nueva iteración cuando se completa esa iteración? ¿O hay un " ágil " ¿Cómo gestionar múltiples proyectos con sus propias iteraciones con un solo equipo al mismo tiempo?

Answer 1

Scrum realmente no dicta que tengas que trabajar en el único producto autocontenido. Simplemente indica que hay un montón de cosas que se deben hacer (la reserva del producto), hay una cierta cantidad de tiempo de desarrollo disponible en la siguiente iteración (resuelta 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 registro de sprint).

No hay ninguna razón por la que el trabajo acumulado y el trabajo acumulado de Sprint deban 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 tiene un número de bases de código que todos tienen que estar progresando. El proceso Scrum (reuniones, preguntas, gráficos de quema, etc.) funciona si se trata de un proyecto o de 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 informe " o " interfaz con la API del sistema XYZ " - de modo que muchos de los problemas provienen de un proyecto o área y al final de la iteración puede señalar un gran volumen de trabajo y colocar un tic en contra.

Answer 2

Creo que la respuesta depende de " quién dará prioridad a los elementos del trabajo pendiente " (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 atrasado para todos los elementos de todos los proyectos, o un trabajo atrasado por proyecto, y selecciona los elementos de la lista de todos los proyectos cuando planifica. un sprint. En este caso, Scrum " funciona " multa.

Si cada proyecto tiene su responsabilidad, entonces es probable que encuentre algunos problemas donde cada responsable, más o menos conscientemente, intente favorecer su (s) proyecto (s). En mi humilde opinión, deberá tener un solo Propietario del producto con la autoridad para establecer las prioridades mediante arbitraje.

Una regla que debe seguirse 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.

Answer 3

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, 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 con cosas como las pruebas.

Otra cosa a tener en cuenta es que la ejecución de proyectos en paralelo destruye su programación. Considere esto: por simplicidad, digamos que tenemos 5 proyectos con el mismo equipo y comenzando en la misma fecha. Cada proyecto requiere 3 meses de esfuerzo. En el mejor de los casos, en paralelo, los terminará todos a la vez y tomará 15 meses. Su velocidad se reducirá porque solo puede ajustar 1/5 de un mes de esfuerzo en un solo sprint. También harás 5 reuniones de demostración al mismo tiempo. Así que, en el mejor de los casos, entregue sus 5 proyectos en 15 meses y su competencia afirmará que podrían hacer el mismo trabajo en 3. Sus equipos que estiman la madurez sufrirán porque solo podrán considerar el 20% de su trabajo disponible. Es posible que descubras que realmente no puedes 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 que dañarán la eficiencia de los equipos. Además, a su equipo le resultará difícil auto-organizarse cuando una simple reasignación de tareas puede requerir 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 atraso de 12 meses y eso Puedes usar ese tiempo para refinar los objetivos de tu proyecto. O si tiene un retraso constante, sabe que es hora de comenzar a contratar a otro equipo. Sin embargo, su mejor proyecto se termina 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 ponerlo en tu currículum. Su velocidad de sprint se estabilizará durante ese período de tiempo y es posible que alcance su ritmo después de un proyecto o dos y que pueda 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 rostros de scrum. Es un cambio cultural importante asociado a 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 miembros de todo el 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 adjunto a un equipo según sea necesario. Deje que corran con sprint 0. Se sorprendería de lo atractivo que resulta trabajar con 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 suficiente tiempo para lidiar con cosas como vacaciones y días festivos con mucha antelación.

Answer 4

He estado en esta situación precisa.

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

Si tiene más de un propietario de producto, idealmente, la parte comercial debe elegir un único 'priorizador' a quien se le asigna la responsabilidad de programar el trabajo. Esta es definitivamente la mejor solución.

Si (como es probablemente el caso) la empresa no quiere cambiar la forma en que desean priorizar las cosas (eso sería demasiado conveniente), entonces puede dividir el equipo y ejecutar dos carreras al mismo tiempo. 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 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ás dividiendo al equipo, no he encontrado mucho valor en amalgamar los stand-ups, a menos que tengas sprints separados trabajando en gran parte del mismo código, pero ese puede ser un argumento para amalgamar a esos equipos para El propósito del sprint.

Answer 5

He estado leyendo sobre otra opinión últimamente, a saber, que en un entorno Agile el concepto de Proyecto podría ser contraproducente y podría eliminarse. Según esta línea de pensamiento, la organización debería centrarse en Lanzamientos en su lugar. Esto se debe a que Projects son cajas de trabajo artificiales que no producen ningún valor hasta que están terminadas. Son contrarios a la meta de Agile de entregar con frecuencia valor enviable. Una versión está más en línea con Agile porque está orientada hacia la entrega de valor y porque su alcance se puede reducir o expandir en función de lo que los equipos pueden ofrecer antes de la próxima versión .

Hay un punto intermedio potencial, en el que lo que antes se llamaba Proyecto en su empresa ahora se vuelve a empaquetar como el tema Agile o Característica . El beneficio de este enfoque es que el Tema o Característica ahora se puede implementar en piezas de valor, según lo considere adecuado el propietario del producto.

Todavía existe la pregunta de un equipo que trabaja 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 creados con Agile, incluso los múltiples Productos creados por un solo equipo, están acumulando constantemente el valor de Release . En contraste, los Proyectos no valen nada hasta que terminan (y muchos no).

Algo en que pensar ...

Answer 6

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 que la ejecución en paralelo no sea eficiente.

Supongamos 5 proyectos cada 3 meses para un equipo con 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 por proyecto, cambio de proyectos

• Cada 6to trabajo de sprint en el proyecto
• demasiado tiempo entre el trabajo del proyecto: no es un valor incremental regular para el proyecto (para la cartera 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 carrera)

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 otro
• El primer proyecto comenzó y se entregó después de 3 meses
• El segundo proyecto comenzó después del 3er mes, entregado después del 6to mes
• ...
• El quinto proyecto comenzó después del 12 ° mes y se entregó después del 15 ° mes
• Equipo altamente enfocado en el proyecto, investigación intensiva y 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
• Requieren una buena cooperación del equipo (los conflictos pueden demorar la entrega).

Como ve, 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 pérdida de tiempo desde el cambio de contexto, sin la colaboración total del equipo, tiempo de entrega total muy largo de todos los proyectos, etc.

¿Y qué pasa con la preparación de la cartera? 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 a sesiones de aseo personal (no se trata de un equipo completo).

Es importante convencer a los clientes de que comenzar el segundo proyecto después de 3 meses todavía dará como resultado una entrega más rápida (después del sexto mes) en lugar de si lo comenzamos 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. 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 hacerlo coincidir con el marco 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 añadamos, el scrum menos eficiente será. ¿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, Adán

Answer 7

Como dijo @Chris, un proyecto normal tiene sub proyectos dentro. Sin embargo, solo tienes un atraso.

Piensa en un backlog con todos tus proyectos. Primer problema: ¿estás 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 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 proyecto " S " gerente que equilibrará los recursos que necesitan los propietarios de productos y el tiempo que los miembros del equipo pueden dedicar. El propietario del producto A pagó por un mes de trabajo, pero el propietario del producto B siempre está actualizando su proyecto (y le paga bien). Hay algunas formas de equilibrar a su equipo para que A tenga su mes (tiempo de desarrollador) y no impida que B llene sus bolsillos.

En el caso de software interno (una empresa, mil proyectos). Los diferentes propietarios de los productos deben acordar el tiempo que se les da. No viven aislados, sino en el mismo barco que usted (proyecto " S " manager). Te harán la vida más fácil, pudiendo posponer algunas tareas, pero al mismo tiempo nunca debes olvidar sus necesidades.

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

Answer 8

Los miembros del equipo pueden dividir su tiempo entre proyectos scrum, pero es mucho más Es productivo tener miembros del equipo totalmente dedicados. Los miembros del equipo también pueden cambiar de uno. corre a la 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 enfocado en un aspecto diferente del producto desarrollo, con una estrecha coordinación de sus esfuerzos.

Answer 9

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

Answer 10

Me gustaría contribuir. Así es como 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 el propietario de este producto " entidad " está a cargo de la cartera de productos.
• La cartera 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 comercial (responsabilidad del propietario del producto).
• Tenemos un " preparación de la cartera de productos " reuniendo 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 motivo comercial, que no nos importa y no nos debe importar) e incluye algunas historias nuevas. En esta reunión se explican las nuevas historias y se actualizan también 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 pedidos del producto, ordenamos las historias por ROI (esto es valor / esfuerzo empresarial) y planificamos las historias hasta que el tiempo se haya acabado.

Y eso es todo. Puedo decir que esto funciona bastante bien. Usamos un par de hojas de cálculo de Google (la cartera de productos y la 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 tareas, etc.

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