Scrum - Desarrolladores que trabajan fuera de Sprint

12

El equipo de Scrum

3 x desarrolladores
2 x probadores
1 x analista de pruebas de automatización

No somos un equipo multifuncional porque los desarrolladores no prueban y los evaluadores no se desarrollan. Creo que esta es la raíz del problema.

Actualmente hacemos sprints de dos semanas.

Al comienzo del sprint, todos están ocupados, los desarrolladores están comenzando el trabajo de desarrollo y los evaluadores están preparando la prueba (escribiendo casos de prueba, etc.)

Una vez que los evaluadores hayan terminado su preparación, ahora esperan que se complete el trabajo de desarrollo O que el trabajo de desarrollo esté completo y los desarrolladores estén esperando comentarios / errores.

Los desarrolladores tienen picazón en los pies aquí y comienzan a trabajar en elementos en la cartera de pedidos que están fuera del sprint actual. Esto ha creado un efecto extraño por el cual siempre estamos desarrollando los próximos sprints en el sprint actual. Para mí esto no se siente bien.

Desde el punto de vista de la gerencia, preferirían que los desarrolladores trabajen antes que sentarse en sus escritorios sin hacer nada, pero al mismo tiempo siento que el objetivo y el enfoque del equipo scrum deberían estar únicamente en el sprint actual. Desearía que nuestro equipo fuera multifuncional, pero desafortunadamente no es posible. Los evaluadores no tienen las habilidades necesarias para realizar el trabajo de desarrollo y la mayoría de los desarrolladores tienen la opinión de que las pruebas están por debajo de ellos.

¿Se considera esto un problema en scrum? ¿Hay una solución para esto? ¿Scrum solo funciona con equipos multifuncionales?

Me gustaría conocer las experiencias de otras personas con esto si es posible :)

agile scrum

— fml
fuente

3

Estoy de acuerdo con la gerencia. Tener gente sentada por un período arbitrario de dos semanas es una idea terrible. Quizás las responsabilidades de su equipo son demasiado rígidas; En equipos tan pequeños, no es raro que todos los miembros del equipo sean "multifuncionales", lo que les permite saltar donde sea necesario en el sprint actual.

— Robert Harvey

... o quizás no estás poniendo suficiente en tus sprints para mantener al equipo ocupado durante dos semanas.

— Blrfl

3

¿Es práctico el desarrollo de un par híbrido / mashup de prueba? En cierto sentido, el proceso es el mismo que el ciclo de prueba de la unidad; escribe un poco de prueba un poco. No teníamos esto formalmente, pero los evaluadores tenían la costumbre de venir a nosotros directamente cuando se encontró un error o dos. No nos comunicamos a través de informes formales de errores. Cuando "mi probador" terminó la prueba, ya había terminado de arreglarlo. Al ser una aplicación web, la reparación se hizo eficiente. Pero al menos experimenta. Y, francamente, incluso si no es mejor o peor, mgt percibirá menos tiempo de espera individual.

— radarbob

3

¿El trabajo que se planeó inicialmente para un sprint generalmente se completa con suficiente calidad? ¿O también te quedan historias a medio terminar de la planificación original?

— Bart van Ingen Schenau

2

Podrías mantener tu proceso pero llamarlo 'kanban' en lugar de 'scrum', y luego no tienes que preocuparte si tu proceso está bien con scrum. / algo sarcástico, pero no realmente

— Eric King

16

Ese es un problema bastante común, causado por la tubería . 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:

Si sus desarrolladores trabajan una iteración por adelantado, se están adelantando a su reunión de planificación. Su gerente de producto y el equipo deben analizar qué es lo más valioso para la próxima iteración correctamente. Los desarrolladores no deben realizar la priorización de manera efectiva porque no tienen nada mejor que hacer.
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 trabajando en silos. Incluso con un enfoque de cascada pura, aún necesitaría "tirar cosas sobre la pared" y esperar comentarios.
También tiene el problema de que a menudo 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 ineficiente, especialmente si trabajan por adelantado , porque necesitan cambiar de contexto.

Claramente, esta situación tiene un costo muy real: el equipo no está colaborando. Me encontré 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 funcionó muy bien para mí son estas dos herramientas:

Haga hincapié en el principio de que todo el equipo es responsable de hacer las cosas. Rechace las historias "dev done", ya que son una forma para que los desarrolladores digan "ya no es mi problema", lo cual no es constructivo y evidentemente falso. Si un equipo no entrega una historia que aceptaron, es todo el equipo el que no entregó.
Para ocupar el tiempo de los desarrolladores y el control de calidad, emparejarlos . Esta es, con mucho, la mejor manera de compartir experiencia y 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 probadores y los desarrolladores puedan intercambiar trabajos, podrán trabajar en equipo y resolver el problema internamente, en lugar de culparse mutuamente.

— Sklivvz
fuente

1

Gracias por su respuesta. Realmente me gusta la idea de combinar el desarrollador y el recurso de control de calidad juntos. Voy a sugerir esto en nuestra próxima reunión y espero que podamos probar esto en el próximo sprint. ¡Actualizaré la pregunta y te haré saber cómo va!

— fml

@Sklivvz Esto sucede más a menudo que solo cuando hay un departamento de control de calidad. Sucede cada vez que el control de calidad es un rol que solo "ciertas personas" pueden desempeñar. En lugar de que el recurso inactivo recoja la "siguiente" tarea de alta prioridad, el desarrollador se queda inactivo, luego retoma más trabajo mientras el control de calidad reacciona perpetuamente a la salida del desarrollador.

— Edwin Buck el

1

Si no estaba claro antes, la "tarea de alta prioridad siguiente sería 'reducir el retraso de control de calidad por lo que los artículos pueden ser enviados' no a la siguiente tarea de alta prioridad el desarrollo de la cartera de pedidos.

— Edwin Buck

1

El consejo, como que todo el equipo es responsable, aunque suene bien, en realidad, no sirve al equipo. Sugiere que todos son intercambiables y es una falta de que todos no contribuyan. Esto está mal. Cada persona en el SDLC tiene un rol particular y ha pasado AÑOS perfeccionando sus habilidades. Pedirle a un ingeniero de software que pruebe es perjudicial para la calidad, ya que no tiene la experiencia necesaria para probar la calidad y probablemente hará un intento poco entusiasta. Incluso si el ingeniero de control de calidad los asesora, la tutoría tomaría tiempo lejos de las pruebas y haría que el trabajo llevara aún más tiempo.

— Chuck Conway

1

@ChuckConway nadie sugiere lo que dices. El emparejamiento no es sustituir o mentorear. Idealmente, confía en el equipo para encontrar la mejor manera de minimizar el tiempo de inactividad, y eso solo puede comenzar con las personas que comprenden los roles y las necesidades de los demás. Los mejores y más eficientes equipos se auto organizan (cierto o no, es un principio básico de agile).

— Sklivvz

2

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

siempre estamos desarrollando los próximos sprints en el sprint actual

Whoa! Esto técnicamente no es posible en Scrum. No sabe qué elementos de la cartera de pedidos estará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.

— Martin Maat
fuente

3

El problema con declaraciones como "¡Whoa! Esto técnicamente no es posible en Scrum" y "... nuevas formas creativas que las organizaciones inventan para sabotear Scrum" es que implican que hay una forma correcta de "hacer Scrum". Para que haya una forma correcta, Scrum debe ser proscriptivo, es decir, poner los procesos antes que las personas. Scrum, por lo tanto, no es un proceso ágil si hay una forma correcta de hacer scrum.

— David Arno

@David Arno Eso es bueno, básicamente estás diciendo que cualquier metodología es, por definición, no ágil. Incluso el manifiesto ágil. Solo el caos puro e impredecible sería ágil. Pero espera ... ¿quién me dice que sea caótico? En serio ahora: el ágil adagio "personas antes de los procesos" está ahí para resolver conflictos. Si uno tiene que elegir, debe hacer lo que tiene sentido, no necesariamente lo que dicen las reglas. Me parece que el equipo de OP podría seguir el libro de Scrum sin problemas. Y tal vez lo hacen, la pregunta clave parece ser cuán transparentes son.

— Martin Maat

1

@DavidArno en realidad, eso solo implica que hay formas específicas incorrectas de hacer Scrum, y eso parece indiscutible. Por ejemplo, cualquier cosa que contradiga el Manifiesto Ágil parece objetivamente incorrecta.

— Sklivvz

1

Scrum optimiza para el equipo , no para el individuo. El objetivo principal de scrum es que el equipo se vuelva eficiente. Si los desarrolladores están comenzando 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 puede planificar suficiente trabajo para llenar la primavera.

Si los desarrolladores se han quedado sin tareas de desarrollo, deberían participar y ayudar a los evaluadores o los escritores de tecnología o los diseñadores, cualquier persona del equipo. No necesariamente tienen que escribir pruebas reales (aunque deberían hacerlo ), pero aún pueden participar en el proceso de prueba. Pueden escribir scripts que ayuden a los probadores a ser más eficientes, o simplemente pueden discutir con los probadores cuáles son sus desafíos y ayudarlos a superar esos desafíos (por ejemplo: agregar atributos de identificación a los elementos de la página web, proporcionar enlaces o API que los probadores puede usar en sus pruebas, etc.).

Creo que el corazón del problema es que si sus desarrolladores no siempre están trabajando en el sprint actual, todavía no están trabajando en equipo. Su scrum master debería tomar nota y trabajar para lograr 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 ayudarlos a comprender cómo funciona scrum para que puedan ayudar a apoyar y alentar a los equipos de desarrollo en lugar de subvertirlos.

— Bryan Oakley
fuente

0

Creo que el problema clave aquí es el siguiente:

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

La forma en que manejamos esto en nuestra empresa es que les 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 mediante pruebas. Se les debe señalar que si aceptan participar en las pruebas, entonces 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).

Señale 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 codificaron realmente funciona.

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

De cualquier manera, hacer algo que no estaba planeado al comienzo del sprint es un gran no-no. Es mejor no hacer nada, que hacer algo que no fue planeado. La funcionalidad que escriben en esos casos probablemente no cumple con los criterios de DoD (definición de hecho), ya que probablemente no se haya probado bien, ya que los evaluadores estaban ocupados probando lo que se planeó originalmente. 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 finalmente, abandonando el equipo debido a eso.

— Vladimir Stokic
fuente

Yo diría que los programadores están probando el código, simplemente no crean pruebas automatizadas. Hay una gran diferencia

— JeffO

En este caso particular, estoy dispuesto a apostar que la única prueba que hacen estos programadores es la del IDE. No muchos desarrolladores realmente incorporan la solución en un paquete de instalación, implementan el paquete desde cero como lo haría el usuario final y luego prueban la solución. Esto en la mayoría de los casos no es suficiente y es una razón para el deterioro significativo de la calidad.

— Vladimir Stokic

0

En teoría, todos los miembros de un equipo SCRUM deben tener el mismo conocimiento, para que cada miembro pueda tomar todas las tareas de cualquier otro miembro. 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 gerencia quiere aceptar.

Según mi experiencia, podrías hacer varias cosas:

No hagas el equipo demasiado pequeño. Si, por ejemplo, tiene 4 desarrolladores y 4 evaluadores, es mucho más fácil trasladar una tarea a otro desarrollador o evaluador 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 una teoría 100% SCRUM, pero primero debe mantener el desarrollo funcionando. SCRUM es solo una caja de herramientas.

— bernie
fuente

0

Parece que necesitas desychronizar a tu equipo. Como eso:

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

Si entendí la prueba de automatización, los chicos tienen que comenzar unos días antes.

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

— Lucas
fuente