¿Cómo coordinar el tiempo de los desarrolladores entre dos proyectos diferentes en Scrum?

Este problema es tan antiguo como el scrum. Hay una solución, pero no te gustará.

• Poner nuevas tareas en el backlog.
• No interrumpas a los desarrolladores.
• Espera el próximo sprint.

Poner a tus desarrolladores en más de un scrum, tener dos trabajos pendientes o asignar solo un porcentaje de su tiempo al sprint, todo funciona contra lo que el scrum está tratando de lograr, es decir, un flujo constante de tareas completadas.

Si prueba ese tipo de cosas, básicamente vuelve a las metodologías de desarrollo 'caos' o 'JFDI' con todos sus problemas asociados, por ejemplo,

• El desarrollador tiene diez tareas sobre la marcha al mismo tiempo. Nadie sabe en qué están trabajando o cuándo se terminará.
• Tiempo desconocido para finalizar el proyecto, porque depende de lo que otros proyectos estén sucediendo al mismo tiempo.
• No hay una vista coherente de la prioridad del proyecto. Otros gerentes desvían a los desarrolladores a sus proyectos favoritos.

Por supuesto, la respuesta habitual a este consejo es "¡Pero no puedo hacer eso! ¡La empresa necesita que se solucionen esos errores de producción lo antes posible!"

Pero eso no es realmente cierto.

Si realmente tiene tantos errores reales que están afectando el negocio hasta este punto, entonces necesita ser profesional y mejorar sus pruebas. Solo trabaje en errores y pruebas automatizadas hasta que los haya arreglado todos. Contrate a un equipo de control de calidad y pruebe el infierno de todos los nuevos lanzamientos.

Lo que es más probable es uno de los siguientes:

• Los errores son problemas operativos, se están quedando sin espacio en disco, sin DR, sin copias de seguridad, sin conmutación por error, etc. Obtenga un equipo OPS.

• Los errores son usuarios que no entienden cómo debería funcionar el sistema "¡Esto sucedió! ¿Es un error?". Obtenga un servicio de asistencia y forme a sus usuarios, escriba la documentación.

• Miedo a la reversión. Lanzó una nueva función y rompió algo, no intente apresurarse a solucionarlo. Regrese a la versión anterior y coloque los errores en el registro.

Aquí solo trato de pensar fuera de la caja.

Como podría no ser posible hacer que el propietario del producto vea las cosas a su manera. Aún puede haber errores críticos que simplemente no pueden esperar, reunirse con los clientes donde se necesita asistencia del desarrollador, etc., donde debe sacar a un desarrollador del sprint por un tiempo.

¿Por qué no intentas anticipar esto y usarlo para tu ventaja?

Necesitarás un equipo de 5 o más para que sea realista.

Pero, ¿por qué no eliminar a un desarrollador por cada sprint (rotando entre los desarrolladores, cada uno tiene su turno)?

Como es probable que no haya suficientes errores para usar un desarrollador completo para las correcciones, hay otros problemas o tareas que se pueden hacer.

• Ejecutar pruebas para identificar cuellos de botella de rendimiento o problemas de escalabilidad
• Mantener el sistema de compilación
• Reuniones con clientes
• Investigación de nuevos marcos / bibliotecas
• Explorar las funciones de idioma que te gustaría usar
• Leyendo sobre temas de seguridad
• Mantenimiento de la base de datos
• Mantenimiento del servidor

La velocidad del equipo puede aumentar, el estrés puede disminuir, los conflictos con la administración pueden disminuir, en realidad se obtiene tiempo para mejorar su conocimiento.

Una "solución efectiva para administrar el esfuerzo del desarrollador por problemas de producción verdaderamente esenciales que he usado es el" enfoque de Batman ".

El aspecto costoso de la responsabilidad de soporte de producción al desarrollar una nueva funcionalidad es el cambio de contexto, por lo que debe tratar de limitar eso.

Con la participación del equipo, cree una lista de los miembros del equipo y haga un ciclo para que cada día, una nueva persona sea declarada "Batman" en la reunión de pie y responda a los problemas de producción esenciales ese día. El resto del equipo puede mantenerse enfocado en el desarrollo sin tener que cambiar de contexto y todos tienen una parte justa del dolor del apoyo. Con un equipo de 5, es un día a la semana donde un desarrollador puede ser interrumpido y 4 días de tiempo de desarrollo ininterrumpido y predecible.

Esto tiene la ventaja de que el conocimiento / experiencia se comparte entre el equipo, por lo que no hay una persona responsable de solucionar problemas particulares y convertirse en un punto único de falla y división justa de los problemas de soporte.