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 :)
Respuestas:
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.
fuente
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.
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.
fuente
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.
fuente
Creo que el problema clave aquí es el siguiente:
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.
fuente
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:
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.
fuente
Parece que necesitas desychronizar a tu equipo. Como eso:
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?
fuente