Cómo organizar el trabajo para un equipo que entrega 3 productos conectados pero distintos y mantenerse ágil

7

Somos un equipo responsable de 3 productos:

  • 2 productos están en desarrollo activo de nuevas funcionalidades y se están moviendo rápido, por lo que el trabajo allí podría clasificarse como proyecto
  • El producto
  • 3 rd está vivo y activo y aquí el trabajo implica BAU 1 y mantenimiento

Uno de los productos es nuevo y con una gran promesa para el negocio, por lo que el trabajo siempre estará en plena marcha. También es el proyecto más atractivo para los miembros del equipo.

El segundo producto se está desarrollando, pero el trabajo tiene una prioridad ligeramente inferior y, por lo tanto, va a ir y venir.

El trabajo en el BAU en el producto 3 rd será mayormente silencioso, con breves ráfagas de actividad para solucionar los problemas informados y ayudar en la implementación.

Hasta ahora, la planificación del trabajo fue muy ad hoc y queremos brindar mayor planificación, previsibilidad y cierto seguimiento con todos los beneficios, pero principalmente, para que el equipo se mantenga motivado debido a la entrega del valor real, mientras que el negocio aumenta. previsibilidad y calidad.

Entonces, la pregunta como se indica en el título es:
¿Cómo administrar un trabajo tan diverso y cambiante, pero agrega el proceso suficiente para mantener los objetivos de mayor predictibilidad, calidad del software y satisfacción en el trabajo?

Creemos que tenemos las siguientes opciones:

  1. Dos Scrums separados para administrar los dos productos en desarrollo activo y un tablero Kanban para extraer los elementos BAU para el tercer producto. Las personas rotarían entre los 3 para dar a todos un poco de suavidad (proyectos nuevos vs. trabajo de BAU). Las desventajas son las diversas combinaciones que afectan incluso a una noción muy aproximada de la capacidad y velocidad del equipo, estimaciones fluctuantes.
  2. Un Scrum con todo el trabajo en los 3 proyectos que se realizan. De esta manera, nos mantendremos en un equipo de la misma capacidad, la misma capacidad promediada para estimar, y la rotación de suave a aproximada estaría sucediendo en base a la historia de cada usuario. No estamos seguros de que las herramientas que usamos (Jira) apoyen de esta manera, pero parece una opción mucho mejor para acomodar ese entorno empresarial tan complejo.

Creo que estamos más interesados en la opción 2, pero ¿alguien vería algún problema obvio y trampas que podamos haber pasado por alto?

¡Cualquier sugerencia constructiva y sugerencias muy apreciadas!

N.B. Sabemos cuán específica y única es esta situación e idealmente, todos trabajaríamos en un proyecto / producto con un trabajo pendiente bien preparado, una gran hoja de ruta y una empresa capaz de crear un entorno de entrega ideal, pero estas cosas están fuera de nuestro control.

1: Negocios como siempre

    
pregunta diginoise 24.07.2017 - 19:16

3 respuestas

2

Opción 2 con un propietario de producto dedicado para cada uno de los proyectos. Cada propietario del producto debe acordar durante la Planificación de Sprint que el sprint capturará suficientes entregables para su proyecto. El apalancamiento en las negociaciones se realizará en función de la orden de proyecto prioritaria acordada para ese sprint.

Equilibre una tarea menos interesante con una más interesante cuando sea posible. Alternativamente, si las tareas de BAU son realmente aburridas, asigne créditos con una recompensa de una tarde libre para cualquiera que acumule un número acordado de esos créditos. A la larga, la devolución pagará con creces el costo de las tardes adjudicadas.

    
respondido por el RLMiller 27.07.2017 - 03:14
1

Agregar equipos Scrum adicionales es una función de la cantidad de posiciones de equipo de desarrollo que tiene, no de los productos en los que está trabajando. Un equipo de desarrollo no debe tener más de nueve personas, por lo que si tiene 20 miembros del equipo de desarrollo, podría ser apropiado dividir a las personas en equipos Scrum de productos separados. Sin embargo, hacer Scrum of Scrum no es trivial, y debe tener un proceso bien establecido y las posiciones de soporte necesarias en su lugar antes de siquiera considerarlo.

Si tienes 9 o pocas personas en tu equipo de desarrollo, tener 3 productos no es una razón para dividir al equipo. La forma en que todo esto funciona es engañosamente simple. Primero, todo va en el backlog. Realmente no importa si es para productos separados o no; Todo el trabajo que debe ser realizado por el equipo. Puede usar etiquetas, áreas, épicas, etc. para distinguir a qué producto pertenece un PBI particular si lo desea, pero no importa.

Segundo, a todo se le asigna un valor de negocio. Por lo general, el valor comercial seguirá el mismo formato que los puntos de la historia para su esfuerzo, con una secuencia Fibonacci modificada (1, 2, 3, 5, 8, 13, 21, 40, 80, 120, etc.), pero generalmente agregue dos ceros al final para 1) diferenciarlo del esfuerzo y 2) hacer que se vea como dinero. Es no dinero, pero a los tipos de empresas les gusta ver cosas como 1300 en lugar de 13 por algo como valor empresarial. Sin embargo, eso es solo una convención, eres libre de manejarlo como quieras, igual que con esfuerzo. El punto es que necesita una escala de valor comercial y necesita asignar PBI a esa escala.

En tercer lugar, usted prioriza el retraso basado en este valor comercial. Cuanto mayor sea el valor comercial que tiene un PBI, más intrínsecamente valioso será para la organización y, por lo tanto, mayor prioridad tendrá para la organización. Como nota al margen, es por esta razón que me gusta recomendar que los equipos de Scrum traten todo como un PBI, incluidos errores, deudas técnicas, etc. Un error no es intrínsecamente más valioso porque es un error, pero el rojo fuerte que suele aparecer. junto con un estado de "error" tiende a implicar que se debe corregir de inmediato. A la inversa, hay una tendencia a evitar el pago de la deuda técnica, incluso si la organización tiene un gran valor para hacerlo, simplemente porque implica que no es tan importante como las características de palabra clave que se incluyen en los folletos de marketing. Cuando todo es un PBI y se le asigna un valor comercial, entonces siempre está trabajando en las cosas que son más valiosas para el negocio, independientemente de si es una característica, un error, una deuda tecnológica y si es para el Producto A, B o C.

Lo que me lleva a: cuarto, trabajar en los elementos con el mayor valor comercial en cada sprint. No importa qué producto es para ese momento. Si su producto de "mantenimiento" tiene algo que debe hacerse con un gran valor para el negocio, aparece al frente y en el centro, mientras que si su producto nuevo y llamativo tiene algo como un artículo propuesto con poco o ningún valor comercial, va al final de la pila, como debería, a pesar de que es para el producto en el que todos quieren trabajar.

En caso de que no sea del todo obvio a través de la repetición, aquí hay un poco más: valor de negocio, valor de negocio, valor de negocio. Se trata de todos sobre el valor comercial. Si estás trabajando en cosas que no aportan valor a la organización, estás perdiendo el tiempo. Período. En cualquier momento, durante cualquier carrera, siempre debe estar trabajando en el PBI que tenga el mayor valor para la organización, independientemente de qué tipo de cosa sea o de qué producto sea parte.

Luego, cuando se trata de que sus desarrolladores quieran trabajar en funciones "atractivas" y no quieran realizar trabajos de mantenimiento, bien, bienvenidos al mundo del desarrollo de software. Eso describe a cada desarrollador nunca. Desafortunadamente, siempre hay que hacer un trabajo duro y alguien tiene que hacerlo. Lo mejor que puedes hacer es intentar girarlo, así que si el Desarrollador A trabajó en un producto de mantenimiento PBI en el último sprint, el Desarrollador B tendrá que hacer este sprint, mientras que el Desarrollador A tendrá un problema como un producto llamativo PBI. Difunde el dolor, por así decirlo.

    
respondido por el Chris Pratt 27.07.2017 - 18:18
0

Es una situación común y creo que la mayoría de las empresas la administran con:

3: Haz un equipo dedicado por proyecto + uno para BAU

Lo que es excelente para la administración pero no tan bueno para los desarrolladores atrapados en BAU

El problema al que te enfrentarás con 1 es que los miembros rotativos del equipo reducen la velocidad y las personas se vuelven perezosas en las tareas difíciles si saben que van a rotar.

El problema que enfrentará con 2 es que el progreso en los proyectos está limitado por el volumen de trabajo de BAU y el error de prioridad del día. ADEMÁS, tenderá a dividirse naturalmente en equipos con personas que eligen tareas relacionadas con el área que conocen.

Mi solución es FINALIZAR los proyectos, es decir, detener el trabajo de BAU y pasar a la siguiente cosa.

Es muy difícil para una empresa hacer esto porque siempre hay clientes existentes, internos y externos, que desean nuevas funciones.

Pero desde un punto de vista técnico, en algún momento, simplemente está convirtiendo esa pieza original de software en una bola de barro gigante. debería ser una mejor inversión para hacer una v2 o algo nuevo.

    
respondido por el Ewan 25.07.2017 - 22:14

Lea otras preguntas en las etiquetas