¿Cómo compartir desarrolladores entre múltiples proyectos ágiles?

  1. 5 productos en 4 plataformas
  2. ~100 implementaciones de proyectos en diferentes etapas (Donde un proyecto es un conjunto de productos personalizados para el cliente).
  3. 15 desarrolladores + 5 QA's
  4. Enjambre de pequeñas tareas claras/CR's/Stories de 8 a 100 horas de tamaño, fáciles de estimar ya que son simples y más o menos similares.
  5. El flujo de nuevas historias para proyectos y productos es impredecible

Cuál es la mejor práctica para tal situación. Estoy omitiendo intencionalmente mi solución para buscar una solución alternativa.

En los comentarios, está diciendo que no tiene ningún problema y que su sistema (sea el que sea) funciona bien. Si está bien y no hay problema, entonces esta no es una pregunta sobre el tema para PMSE. Si hay un problema, al menos debe considerar la posibilidad de que los profesionales ágiles experimentados puedan brindarle buenos consejos sobre cómo resolver el problema de implementación del marco tal como lo ha publicado . PMSE sigue un formato de preguntas y respuestas; no es un foro de discusión, ni un lugar para generar ideas abstractas para problemas que no tiene, o para adivinar cuál podría ser realmente su problema.

Respuestas (2)

TL;DR

¿Cómo compartir desarrolladores entre múltiples proyectos ágiles?

tu no Hacerlo es inherentemente no ágil.

Esto huele a un problema X/Y, donde X (el verdadero problema) probablemente sea un mandato ejecutivo para "hacer más con menos" sin priorizar proyectos basados ​​tanto en el valor comercial como en las limitaciones de recursos. Sin embargo, es posible que usted o su organización hayan decidido resolver por Y buscando una panacea que haga posible lo imposible.

No hay bala de plata. ¡Asegúrate de resolver para X, en lugar de Y!

Sus opciones generales

En una práctica ágil, generalmente puede elegir entre:

  1. Equipos fijos y multifuncionales que trabajan en diferentes proyectos, pero solo uno a la vez.
  2. Equipos basados ​​en productos, donde los equipos se forman en torno a cada producto. Tenga en cuenta que cada producto tendrá su propio Product Backlog por separado, y cada equipo trabajará desde exactamente un Product Backlog.
  3. Equipos basados ​​en funciones, donde los equipos se forman en torno a funciones (en lugar de proyectos), que pueden compartir un solo Product Backlog o tener un backlog por equipo de funciones.

La forma en que delinea proyectos, productos y características puede complicar esto, pero la distinción entre un solo producto con muchas características y múltiples productos debe ser su principio rector. Mucho depende de conceptualizar correctamente el proyecto y no tener miedo de separar proyectos relacionados cuando ya no encajan dentro de los límites de un solo producto o equipo.

Debe abordar las limitaciones de recursos.

En todos los casos, realmente no puede hacer lo que parece estar tratando de hacer, que es esparcir la mantequilla de maní cada vez más fina sin ajustar sus limitaciones de recursos. Específicamente:

  1. 20 miembros del equipo no son suficientes para soportar 100 proyectos simultáneos. ¡Un equipo, un proyecto! es una regla estricta con todos los marcos ágiles.
  2. A menos que haya hecho un mejor trabajo al abstraer su arquitectura o crear equipos interfuncionales de lo que ha descrito aquí, no tiene cinco productos, ¡tiene veinte! Como regla general, 5 products * 4 platforms = 20 product backlogs.
    • Esto requeriría al menos 20 equipos a menos que priorice y secuencie los entregables.
    • También puede considerar equipos multifuncionales que puedan crear un producto a partir de un trabajo pendiente que se dirija a múltiples plataformas (piense en PhoneGap como ejemplo), pero aún no tiene suficiente personal para cinco de esos equipos.

También hay otros problemas con su enfoque conceptual, pero todos se reducen al hecho de que está tratando de hacer demasiado con muy poco. No importa cómo estructure sus proyectos, no puede hacerlos todos al mismo tiempo con los recursos que tiene. Debe agregar recursos, priorizar el uso de sus recursos disponibles o (idealmente) hacer ambas cosas.

En realidad, dicho equipo funciona desde hace años en la configuración que mencioné y con bastante éxito. Un desarrollador, un proyecto simplemente no funciona, ya que no hay nada que hacer para un desarrollador en un proyecto, y la cantidad de nuevas historias puede cambiar de manera impredecible en una semana. Actualmente, es un trabajo pendiente para cada cliente, para todos los productos en todas las plataformas.

CodeGnome da una gran respuesta y es 100% correcto, tú no.

La herramienta número 1 que he usado para explicar por qué, a la gerencia, es un ejercicio de diez minutos que requiere nada más que una hoja de papel en blanco y un bolígrafo. Yo lo llamo el "Juego de letras multitarea", seguro que tiene otros nombres.

Para jugar:

  1. Pida a cada persona que coloque una hoja de papel en blanco frente a su paisaje (de lado, de modo que sea más ancho que alto).
  2. Dibuja tres columnas iguales.
  3. Dibuja una línea horizontal a unas dos pulgadas de la parte superior.

Ahora tiene seis cajas, tres pequeñas en la parte superior y tres largas en la parte inferior. 4. Etiquete las casillas pequeñas "1", "A" e "I" (Número romano 1) 5. Explique el ejercicio

"Tu trabajo es crear caracteres. Cada columna representa un producto diferente, los números, las letras y los números romanos. Cada producto consta de los primeros diez caracteres de la secuencia, AJ, 1-10 y números romanos 1-X"

  1. Explique la primera ronda:

"En la primera ronda queremos asegurarnos de que estamos trabajando en todo para que todo se haga lo más rápido posible. Así que trabajarás de izquierda a derecha, escribiendo "A", luego "1" y luego el número romano 1 antes de continuar. Continúe con "B", "2" y el número romano 2. Cuando haya terminado toda la página, levante la mano.

  1. Con un cronómetro listo, dígales que comiencen. Empieza a cronometrar. Cuando la primera persona levante la mano, presiona el cronómetro de vueltas. Cuando la mayoría de la sala esté levantando la mano, detenga el cronómetro.

    En general, la primera persona terminará en algún lugar alrededor de 25-30 segundos y todos terminarán antes de que hayan transcurrido 40 segundos.

  2. Registre los resultados en un lugar bien visible.

  3. Explique las reglas para la segunda ronda.

    "Esta vez queremos centrarnos en un solo producto a la vez. Así que comience haciendo A a J, luego pase a los números y luego a los numerales.

  4. Colóquese donde pueda ver fácilmente las páginas de varios participantes. Con el cronómetro listo, dígales que comiencen.

  5. Escanee a los participantes y, tan pronto como vea que alguien se mueve a la columna de números, presione el cronómetro de vueltas. Cuando la mayor parte de la habitación esté lista, detenga el temporizador.

    Generalmente, la primera persona terminará la primera columna en 4 a 6 segundos y toda la sala se terminará en menos de 30 segundos. El tiempo total para la ronda 2 casi siempre será menor que el tiempo que le tomó a la persona más rápida en completar la ronda 1.

  6. Registra los resultados y reflexiona sobre lo que sucede cuando te enfocas en una sola cosa a la vez.

Interesante juego, pero nada que ver con una situación en la que la demanda de producto y proyecto es impredecible.
Alexander- Tu primer número no tiene nada que ver con el trabajo o los proyectos. Ya sea que esté realizando múltiples tareas en proyectos, historias de usuarios o tareas, causará un problema. Mirando su respuesta a CodeGnome, parece que podría beneficiarse de un flujo de trabajo Kanban sobre Scrum. En cualquier caso, aún necesita que las personas aprendan a concentrarse en un "elemento" a la vez, ya sea un proyecto, una historia o una tarea.
No hay problema de prioridad, ya que se mantiene un sistema de prioridad en toda la cartera. Los desarrolladores siempre trabajan en un problema a la vez en función de los principales prioridades que se negocian en función de las expectativas y el valor del cliente. Sí, hay un tablero kanban, el problema es que es demasiado grande para ser observado o filtrado para ver la vista de helicóptero de una tubería de entrega. Otro problema aquí, ya que los prios están cambiando, por lo que el tiempo de entrega no es una métrica confiable. También podemos operar con una velocidad semanal/mensual bastante precisa, ya que hay CD con producción después de la fase de control de calidad. Y la mayoría de los problemas son independientes.