Scrum - Desarrolladores que trabajan fuera de Sprint

Es un problema bastante común, causado por canalización . El equipo es multifuncional, pero, por supuesto, hay silos internos que disminuyen el rendimiento.

En primer lugar, me gustaría señalar un par de cosas que creo que son importantes:

1. Si sus desarrolladores trabajan una iteración por adelantado, están anticipando su reunión de planificación. Su gerente de producto y el equipo necesitan discutir qué es lo más valioso para la próxima iteración correctamente. Los desarrolladores no deben hacer la asignación de prioridades de manera efectiva porque no tienen nada mejor que hacer.

2. No importa cómo divida y organice las iteraciones, realmente no puede mantener a todos ocupados todo el tiempo y tener un solo equipo con una sola reunión de planificación siempre que su equipo tenga especialistas que trabajen en silos. Incluso con un enfoque de cascada pura, todavía necesitarías "tirar cosas por la pared" y esperar comentarios.

3. También tiene el problema de que, con frecuencia, una sola historia debe tener una fase de desarrollo, seguida de una fase de prueba, seguida de una fase de corrección de errores, seguida de ... esto realmente puede hacer que su equipo sea ineficaz. especialmente si trabajan por adelantado, porque necesitan cambiar de contexto.

Claramente, hay un costo muy real en esta situación: el equipo no está colaborando. Me he encontrado con esto cada vez que había un equipo de control de calidad involucrado, así que tuve un poco de tiempo para experimentar diferentes soluciones.

Lo que me funcionó muy bien son estas dos herramientas:

1. Enfatice el principio de que todo el equipo es responsable de hacer las cosas. Rechace las historias de "dev done", ya que son una forma para que los desarrolladores digan "ya no es mi problema", lo que no es constructivo y es evidentemente falso. Si un equipo no entrega una historia que aceptaron, es todo el equipo el que no entregó.

2. Para ocupar el tiempo tanto de los desarrolladores como del control de calidad, emparejalos . Esta es, con mucho, la mejor manera de compartir la experiencia y el conocimiento de dominio que puede elegir. Los desarrolladores pueden ayudar a los evaluadores a automatizar sus tareas. Los evaluadores pueden mostrar a los desarrolladores dónde es importante probar el código porque es frágil. Ambos colaboran y trabajan más rápido que no.

Usando estas dos técnicas, el equipo debería tener menos silos y más rendimiento. Si bien es poco probable que los evaluadores y los desarrolladores puedan intercambiar trabajos, podrán trabajar en equipo y resolver el problema internamente, en lugar de culparse unos a otros.

No hay ningún problema con la forma en que está trabajando en relación con SCRUM y los sprints, siempre y cuando quede registrado en el momento de la evaluación, el trabajo del desarrollador se completó en menos tiempo (y cuánto menos tiempo) que el planificado. Esto permitirá que el equipo adquiera más puntos de historia para el próximo sprint. Después de todo, el punto de los sprints es mejorar en la planificación. Obviamente, todavía tienes margen de mejora.

  

siempre estamos desarrollando el próximo trabajo de sprints en el sprint actual

Whoa! Esto no es técnicamente posible en Scrum. No sabe qué elementos de la cartera de pedidos se incluirán en el próximo sprint, que se establecerá al comienzo del próximo sprint en una sesión de planificación de sprint.

Sigue siendo interesante aprender sobre nuevas formas creativas que las organizaciones inventan para sabotear Scrum.

Scrum optimiza para el equipo , no para el individuo. Todo el punto del scrum es que el equipo sea eficiente. Si los desarrolladores están empezando a trabajar en cosas fuera del sprint actual, están perjudicando al equipo. También muestra que está fallando un poco en su proceso de planificación, si no planifica el trabajo suficiente para completar la primavera.

Si los desarrolladores se han quedado sin tareas de desarrollo, deberían colaborar y ayudar a los evaluadores, a los escritores técnicos o a los diseñadores, cualquiera en el equipo. No necesariamente tienen que escribir pruebas reales (aunque, deberían ), pero aún pueden participar en el proceso de prueba. Pueden escribir secuencias de comandos que ayudan a los evaluadores a ser más eficientes, o simplemente pueden hablar con los evaluadores sobre cuáles son sus desafíos y ayudarlos a superar esos desafíos (por ejemplo: agregar atributos de identificación a elementos de la página web, proporcionar enlaces o API que los probadores puede utilizar en sus pruebas, etc).

Creo que el meollo del problema es que si los desarrolladores no siempre están trabajando en el sprint actual, todavía no están trabajando en equipo. Su maestro de scrum debe tomar nota y trabajar para que el equipo trabaje como una unidad en lugar de una colección de individuos.

También sugiero que este es un problema de gestión. Si están presionando a los desarrolladores para que se mantengan ocupados, entonces no han aceptado completamente el scrum. Esta es otra cosa con la que el scrum master puede ayudar. Pueden trabajar con la administración para ayudarles a comprender cómo funciona el scrum para que puedan ayudar a apoyar y alentar a los equipos de desarrollo en lugar de subvertirlos.

Creo que el problema clave aquí es el siguiente:

  

la mayoría de los desarrolladores opinan que las pruebas están por debajo de ellos

La forma en que manejamos esto en nuestra compañía es que preguntamos a los desarrolladores cómo pueden decir que realmente terminaron su trabajo si no pueden probarlo. Por supuesto, la única forma de demostrarlo es demostrar que el código que escribieron realmente funciona, y esto se hace a través de pruebas. Se les debe indicar que si aceptan participar en las pruebas, las pruebas se realizarán más rápido y tendrán más tiempo para codificar funcionalidades adicionales (que también deberán probarse).

Indique que probar su código no está por debajo del nivel de los desarrolladores. Es una parte integral del proceso de desarrollo. No se puede separar de la simple codificación. Cualquiera puede codificar. No todos pueden codificar y probar que lo que ellos codificaron realmente funciona.

Otra forma de mantener a los desarrolladores ocupados es hacer que trabajen en la codificación de pruebas automatizadas para las funcionalidades que desarrollaron en el sprint. Esas pruebas podrían utilizarse para pruebas de regresión que se realizarían periódicamente.

De cualquier manera, hacer algo que no fue planeado al comienzo del sprint es un gran no-no. Es mejor no hacer nada, que hacer algo que no fue planeado. Lo más probable es que la funcionalidad que escriben en esos casos no cumpla con los criterios del DoD (Definition of Done), ya que probablemente no se haya probado bien, ya que los evaluadores estaban ocupados al probar lo que originalmente se planeó. Esta es una forma segura de introducir errores y deteriorar la calidad del producto, que luego envía al equipo a una espiral descendente de problemas de regresión y cambio de contexto, lo que resulta en estrés, velocidad reducida y, por último, abandono del equipo.

En teoría, todos los miembros de un equipo SCRUM deben tener el mismo conocimiento, de modo que cada miembro pueda tomar todas las tareas de los demás miembros. Si no, debes difundir el conocimiento.

Pero en la práctica siempre hay algún tipo de especialización. El software puede ser complejo, el miembro del equipo tiene diferentes habilidades, etc. La división del equipo en desarrolladores y evaluadores es solo un ejemplo (muy común) de especialización.

Difundir el conocimiento puede llevar más tiempo del que la administración desea aceptar.

Según mi experiencia, puedes hacer varias cosas:

• No hagas que el equipo sea demasiado pequeño. Si, por ejemplo, tiene 4 desarrolladores y 4 probadores, es mucho más fácil trasladar una tarea a otro desarrollador o probador que tener solo 3/2 como en este ejemplo.
• Intenta dividir las tareas más grandes. Si tiene tareas más pequeñas, será más flexible.
• Defina algunas tareas opcionales que podrían realizarse si queda tiempo.

Es posible que estas sugerencias no sean 100% SCRUM, pero primero debes mantener el desarrollo en funcionamiento. SCRUM es solo una caja de herramientas.

Parece que necesitas desychronizar a tu equipo. Así:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

Si entendiera la automatización de pruebas, los muchachos deben comenzar unos días antes.

Pero siento un problema en su equipo: tengo un problema con los desarrolladores que no prueba su propio código. Si los chicos de prueba preparan la prueba sin revisar el código, probablemente solo estén haciendo pruebas de caja negra que no tienen en cuenta los puntos de decisión del programa desarrollado. ¿Está satisfecho con la calidad de su software?