Trabajo como scrum master en un lugar donde tenemos dos productos distintos. Y estos productos tienen submódulos:
Product A: (The bigger product)
Submodule A.1
Submodule A.2
Submodule A.3
etc.
Product B: (The smaller product)
Submodule B.1
Submodule B.2
Submodule B.3
etc.
Ahora mismo tenemos dos equipos. Equipo del producto A (formado por 12 desarrolladores) y equipo del producto B (formado por 3 desarrolladores)
Y también tenemos dos evaluadores que en realidad no forman parte de estos equipos y tienen una acumulación diferente.
En nuestros equipos tenemos un proceso de revisión de código que se realiza antes de que se resuelva un problema. Por lo tanto, un código que no haya sido revisado por un compañero no se puede marcar como hecho.
Sé que 12 desarrolladores es mucho para un equipo Scrum y 3 desarrolladores es un número pequeño para un equipo Scrum. Debido a esto y por algunas otras razones, nos enfrentamos a algunos problemas.
1) El equipo del Producto B se mueve a un ritmo lento y pierde demasiado tiempo en los problemas. Las revisiones de código no se realizan a fondo y los códigos con errores se marcan como completados. El equipo B en realidad no se parece mucho a un equipo, cada uno tiene sus propios objetivos. Esto se debe a que un desarrollador siempre está trabajando en las funciones principales y en el nivel del sistema operativo. El otro desarrollador siempre está trabajando en el lado de la interfaz de usuario (en realidad, no es un diseñador de interfaz de usuario, sino un desarrollador de back-end) y el otro desarrollador se unió al equipo recientemente y está trabajando en formas e investigando cómo hacer que el producto funcione con más actuación.
Entonces, el desarrollador que trabaja en el nivel del sistema operativo está revisando los códigos de la interfaz de usuario. El desarrollador de la interfaz de usuario está revisando los códigos de nivel del sistema operativo. En realidad, no tienen la experiencia para revisar el código de los demás y realmente no saben o no están realmente interesados en lo que otro está haciendo.
2) Producto Un equipo es un gran equipo y el producto es un gran producto. Consta de varios (como 10) submódulos. Todos los submódulos son módulos distintos en el lado del servidor (a veces usan bibliotecas comunes y archivos conf comunes, módulos, etc. pero generalmente distintos) pero todos comparten la misma GUI (se usa una aplicación java swing para administrar todos estos módulos) Así que 2 desarrolladores siempre están trabajando en la GUI, algunos desarrolladores trabajan en la mayoría de los módulos en el backend. Y algunos desarrolladores siempre están trabajando en el mismo submódulo (por ej.: Submódulo A.1 y Submódulo A.2) Entonces esos muchachos tienen mucha experiencia en ese módulo, pero no saben mucho sobre el resto del producto. Mientras que los otros desarrolladores conocen gran parte del producto excepto por esos submódulos (Submódulo A.1 y Submódulo A.2)
En realidad, todos nuestros desarrolladores son buenos desarrolladores que pueden manejar cualquier cosa que les arrojes. Pero, por supuesto, algunos de ellos son mejores en el lado de la interfaz de usuario, mientras que otros son mejores en el lado del backend. Algunos han adquirido mucha experiencia en un módulo específico, por lo que un trabajo en ese módulo específico siempre lo realiza esa persona específica. Esto conduce a espectáculos de un solo hombre, el fracaso y el éxito se vuelven suyos, no de los equipos.
Entonces, mi pregunta principal es ¿cómo debemos formar equipos y acumulaciones? Ahora mismo tenemos dos equipos (producto A y producto B) y dos backlogs (Producto A y Product B backlog). ¿Deberíamos mantener esto?
Estamos planeando crear equipos como el equipo del sistema operativo, el equipo de la plataforma, el equipo de interfaz, el equipo de arquitectura, el equipo de implementación, el equipo de prueba, el equipo de seguridad y el equipo de documentación. En realidad, ni siquiera sé cómo sucederá esto, ni siquiera tenemos tanto desarrollador. Tal vez una persona estará en varios equipos, no lo sé. Y si creamos equipos como este, ¿cómo deberíamos formar los backlogs?
Pero creo que este tipo de estructura de equipo está en contra del scrum, porque los equipos de scrum deben ser multifuncionales. Todos los tipos de experiencia deben estar en equipos.
O deberíamos crear nuevos equipos al comienzo de cada sprint según las necesidades del sprint. Pero, ¿cómo será esto? (¿Quién asistirá a qué reunión de planificación de sprint?)
PD: Los desarrolladores del Producto A y del Producto B tienen la habilidad suficiente para trabajar en el otro producto.
Y de acuerdo con la estructura del equipo, recomendará cuántos scrum masters deberíamos tener. ¿Un scrum master es suficiente o cada equipo debe tener sus propios scrum masters?
Estás haciendo muchas preguntas aquí:
equipos componentes (plataforma, front-end...): Tienes razón, eso va en contra de Scrum. Si quieres perder tiempo con la entrega, haz esto :-)
miembros compartidos del equipo También va en contra de Scrum. La multitarea ralentiza a las personas, les hace perder el enfoque. Bien por mala calidad :-)
¿Cómo lidiar con un equipo realmente grande y realmente pequeño? La solución obvia es cambiar a los miembros del equipo. Solo haz que no lo pidas. Aborda el problema con los equipos. Tal vez a algunos de los equipos grandes les gustaría ayudar en el equipo pequeño. Esto puede ser para una cantidad limitada de sprints o permanente. Podría ser una especie de año sabático.
Algunas personas trabajan en lo mismo todo el tiempo: ¿Recuerdas al trabajador en forma de T? Está bien si algunos miembros del equipo son realmente buenos en una cosa y la hacen mucho. Pero si lo haces exclusivamente te encuentras con cuellos de botella. Inspirar al especialista a enseñar y compartir sus conocimientos. Seguirán siendo especialistas, pero otros pueden y deben ayudar.
¿Cuántos atrasos? Máximo uno por producto, independiente del número de equipos.
Nueva estructura de equipo en cada sprint: estado allí hecho eso, no funciona. Un equipo necesita tiempo para formarse. Construir nuevos equipos en cada sprint hace equipos realmente malos. Un efecto extra es que después de un tiempo todo el mundo ve un poco de todo pero no tiene una comprensión más profunda de nada.
Cuántos Scrum Masters: Con eso es necesario emitir un Scrum Master por equipo.
Respuesta muy tardía. No te ayudará a ti, pero tal vez a alguien más.
Equipo del producto A (formado por 12 desarrolladores) y equipo del producto B (formado por 3 desarrolladores)
El equipo A es demasiado grande para una comunicación efectiva. El equipo B podría funcionar en teoría, pero es muy pequeño.
porque un desarrollador siempre está trabajando en las funciones principales y en el nivel del sistema operativo
No deberías tener una 'característica principal'. Sus características deben ofrecer valor para el usuario final. Cualquier 'característica central' que necesite 'características de interfaz de usuario' para ser realmente utilizada, no está entregando valor. Es una tarea técnica, no una característica.
Idealmente, sus desarrolladores trabajarían juntos en la misma función y, por lo general, desde su propia perspectiva (interfaz de usuario central), pero con el mismo valor para el usuario en mente.
En tu caso yo mezclaría los equipos. Primero, el backlog debe contener historias de usuarios (entregar valor al usuario); no 'cree esta función de interfaz de usuario que aún requiere que se construya XYZ antes de que funcione'.
Los llamaría juntos (los 15); dígales el atraso; y pídales que se organicen en torno al trabajo. * Formen equipos ustedes mismos * Que nadie se quede atrás * Ningún equipo menor de 4 ni mayor de 7 * Cada equipo debe tener las capacidades para hacer el trabajo.
Terminarás con 3 equipos y cada uno puede tener un área de enfoque diferente. El equipo 1 puede enfocarse en el Producto A, y los equipos 2 y 3 pueden trabajar en el producto A + B en ambos.