¿Cómo supero un cuello de botella en el proceso de un equipo, cuando lo que la gente me dice no coincide con lo que veo?

Su equipo parece hacer un desarrollo en mini cascada dentro de cada sprint, lo cual es un antipatrón conocido, ya que no obtiene la colaboración dentro del equipo que hace que los métodos ágiles sean exitosos.

Además, Scrum solo tiene 3 "títulos de trabajo": propietario del producto, Scrum Master y miembro del equipo de desarrollo. No hay desarrolladores y evaluadores por separado, todos son miembros del Equipo de desarrollo por igual, aunque los miembros individuales pueden centrarse más en la implementación o las pruebas.

El equipo de desarrollo en su conjunto es responsable de brindar funcionalidad de acuerdo con sus estándares de calidad, lo que generalmente se representa mediante la obtención de tickets para "Terminado". Si hay un problema para hacer los tickets, todo el equipo de desarrollo debe ser responsable de eso. Si hay un retraso en la funcionalidad de prueba, entonces las personas que escribieron el código son igualmente responsables de resolver ese retraso que las personas que realizan las pruebas.

Como pensamiento final, asumo que al final de un sprint, todo el trabajo inconcluso pasa automáticamente al siguiente sprint, con algo de trabajo nuevo agregado para llenar la capacidad restante. Me pregunto cómo reaccionaría el equipo si el Product Owner comenzara la planificación de un nuevo sprint con

He tenido un cambio de prioridades. Todo el trabajo sin terminar que no pudimos entregar en el último sprint ya no es lo suficientemente importante para mí, por lo que dejaremos de trabajar en él y esas historias volverán a la cartera de pedidos hasta que vuelvan a ser relevantes. Ahora, este nuevo trabajo es en lo que quiero que comencemos a enfocarnos a partir de hoy.

Puede hablar con el propietario del producto para probar esto como un experimento y darle al equipo una sacudida de que el trabajo inconcluso realmente puede parecer un esfuerzo desperdiciado (donde inconcluso significa que el trabajo no está en la columna Terminado. Si la implementación está completa, pero la prueba no , entonces no está Hecho). El punto en el que esas historias inconclusas vuelven a ser relevantes podría ser el sprint posterior al que ejecuta este experimento, pero eso depende del PO.

Su problema no es que tenga desarrolladores y no desarrolladores (como llama al propietario del producto/análisis comercial, el diseñador y los evaluadores). Su problema es que estas personas tienen propiedad individual sobre su porción del pastel y no sobre todo el pastel .

Aquí hay algunas cosas de la Guía Scrum (énfasis mío):

• Los Equipos de Desarrollo son multifuncionales, con todas las habilidades como equipo necesarias para crear un Incremento de producto;
• Scrum no reconoce subequipos en el Equipo de desarrollo, independientemente de los dominios que deben abordarse, como pruebas, arquitectura, operaciones o análisis comercial ; y,
• Los miembros individuales del Equipo de desarrollo pueden tener habilidades especializadas y áreas de enfoque, pero la responsabilidad pertenece al Equipo de desarrollo como un todo .

Idealmente, cada miembro del equipo de desarrollo en Scrum podría ser un desarrollador de pila completa, pero si en realidad tiene desarrolladores y evaluadores, entonces no hay ningún problema. He trabajado con equipos en los que los desarrolladores escribieron el código y los evaluadores lo probaron, y en algunos equipos funcionó y en otros no. ¿Cuál fue la diferencia?

En los equipos que trabajaron bien juntos, la gente colaboró. Trabajaron juntos para mover cada historia a través del sprint a "Terminado". Los desarrolladores terminaron su trabajo e hicieron una entrega a los evaluadores. Explicaron lo que estaba pasando, cómo funcionaba, dónde buscar cosas en la base de datos, cómo crear datos de prueba, etc. Los desarrolladores y probadores tenían una buena comprensión de lo que se necesitaba construir después de las interacciones con el propietario del producto. Los evaluadores trabajaron en estrecha colaboración con los desarrolladores para preparar sus escenarios de prueba antes de recibir la entrega del desarrollo. Si alguien necesitaba ayuda de otra persona, la conseguía. Eran dueños de todo el trabajo, aunque se encargaban de diferentes etapas del trabajo (diseño, desarrollo, pruebas, etc.).

¿Te importa saber cómo se desarrollaron las cosas en los equipos que no colaboraron? Cada uno estaba haciendo lo suyo. Los desarrolladores desarrollaron. Probadores probados. El analista de negocios escribió los requisitos. Solo les importaba "su parte" y una vez que eso había terminado, lo arrojaron sobre la cerca a otros para que se ocuparan de eso a continuación. "He hecho mi parte, ahora es tu turno". En lugar de trabajar juntos para mover la pelota de un lado a otro de la cancha, simplemente rebotaron la pelota entre ellos hasta que alguien finalmente dijo "lo suficientemente bueno".

Su problema no es que las personas tengan diferentes habilidades y no sean multifuncionales. Tu problema es que sus habilidades no se complementan entre sí. Sus habilidades no se mezclan, se mantienen en capas .

Si pones a los desarrolladores a probar más y a los probadores a desarrollar más, la gente comenzará a odiarlo. Encuentre maneras de hacer que trabajen juntos. Cómo exactamente, no puedo decir. Depende de la dinámica del equipo. Es posible que deba experimentar con algunas cosas. Prueba algunas otras cosas. Mire la imagen completa y averigüe qué está pasando. Es posible que deba realizar un seguimiento de cada historia en el sprint individualmente y determinar a partir de ahí dónde están los puntos de fricción entre las personas. Entonces piensa cómo trabajar en eso.

Y tenga en cuenta que puede llevar algo de tiempo mejorar la forma en que las personas trabajan juntas. Dijiste que comenzaste como Scrum Master hace unos meses. ¿Cuánto tiempo han trabajado estas personas como lo hacen ahora? Así hacen las cosas. Pueden estar tan inmersos en su forma de hacer las cosas que no se dan cuenta de que podría haber mejores enfoques. Tú, en cambio, eres nuevo y ves los problemas. Trabaje con ellos para mejorar la comunicación y la colaboración primero, y luego todos pueden buscar formas de mejorar el proceso.

Ya estás haciendo muchas cosas buenas, pero también recomendaría lo siguiente:

• Reduzca la cantidad que aporta a cada sprint
• Continúe reduciéndolo hasta que desaparezca el cuello de botella de prueba y el equipo complete todo el trabajo que asignan a un sprint
• Refuerce continuamente el punto de que el trabajo del equipo es entregar elementos completos, no hacer mucha codificación.

Concentra mucho de tu esfuerzo en las retrospectivas. Habrá una tentación de culpar ("es culpa de los probadores", "es culpa de los desarrolladores"). Evite esto y concéntrese continuamente en hacer que el equipo trabaje de manera colaborativa.

No necesita resolver este problema, pero sí necesita ayudar al equipo a resolverlo. No lo harán hasta que empiecen a pensar y actuar como un equipo unificado.

Si el equipo es reacio a hacer cambios, sugiérales que hagan cosas como experimentos:

"¿Por qué no intentamos hacer X para el próximo sprint? Si no funciona, podemos volver a nuestra antigua forma de trabajar".

Otros comentarios aquí suenan todos verdaderos: demasiada cascada, no hay suficiente responsabilidad de equipo, etc. pero me gustaría enfatizar un punto que se hizo solo una vez en otras respuestas: está estableciendo metas absolutamente demasiado altas. TIENE que establecer objetivos pequeños que sean alcanzables, sin importar cuán lento sea. Si eso no se ajusta al cronograma comercial, el cronograma comercial no se puede cumplir con el personal existente y cuanto antes se cumpla, mejor. Alcanzar los objetivos a tiempo es divertido y adictivo y genera camaradería y espíritu de equipo. Fracasar en los objetivos una y otra vez convierte a todos en perdedores innecesariamente, y los perdedores no están motivados, no son productivos ni cooperan. Toma al mejor desarrollador o equipo del mundo, dale metas que no puedan cumplir y los habrás convertido en perdedores.

Ahora un nuevo punto: algunos códigos tardan el doble (o más) en probarse que en escribirse. ¿Alguna posibilidad de que ese sea el caso aquí? ¿Están en lo cierto los probadores en que el trabajo tarda tanto en probarse? ¿Eres capaz de incrustar literalmente y hacer algunas pruebas tú mismo y verlo desde adentro?

Si es así, quizás podría hacer que sus evaluadores descarguen todo lo posible. Por ejemplo, como desarrollador, escribo las pruebas unitarias y las completo con todas las pruebas que se me ocurren. Dado que el autor original siempre tiene puntos ciegos, tendría sentido pasar las pruebas unitarias al personal nuevo que puede encontrar problemas nuevos, pero en ese momento solo están agregando casos de prueba a un script existente.

De hecho, si el cliente de la solicitud del proyecto es técnico ("Necesito una API que haga XYZ"), podría decirse que el cliente podría estar escribiendo el arnés de prueba inicial y los casos de prueba, como una expresión concreta de lo que necesita. Los desarrolladores trabajan en el código hasta que pasa el script de prueba, y solo entonces pasan al control de calidad para estudiar las cosas que se pasan por alto. Al igual que mi punto anterior, esto da como resultado que los probadores tengan mucho menos trabajo por hacer, pero además les da a los desarrolladores un objetivo inicial concreto antes de enviar el código candidato para una prueba independiente.

(Como una variación, eso no descarga el trabajo de los evaluadores, pero evita que los desarrolladores envíen un código evidentemente inutilizable: haga que los evaluadores escriban los scripts de prueba primero y solicite a los desarrolladores que los aprueben antes de devolverlos a la prueba...)

La primera pregunta que me gustaría considerar en su posición es:

¿Se están viendo los problemas en la prueba porque el código no es confiable o porque no se entendieron los requisitos?

Es de suponer que los desarrolladores se están atascando al garantizar la corrección del código, pero en los siguientes dos escenarios:

• El desarrollador escribe lo que cree que debería funcionar, pero sigue encontrando defectos técnicos "obvios" cuando lo prueba, es decir, el problema es obvio cuando se llama la atención al lanzar una excepción.
• El desarrollador escribe lo que cree que es la implementación correcta para la historia, pero decide al probar que la historia en realidad no se cumple, o que la redacción y la intención de la historia no están lo suficientemente alineadas como para producir una característica que realmente se pueda usar.

...hay causas y remedios muy diferentes.

Por supuesto, si tiene mucha mala suerte, puede tener una gran cantidad de ambos.

Para el primer punto, las causas raíz pueden ser problemas como:

• Desarrolladores que no están lo suficientemente familiarizados con el marco o los patrones que se utilizan
• No hay suficientes herramientas automáticas (por ejemplo, eliminación de pelusa, pruebas de unidades) para reducir el trabajo manual, o no se comprende cómo se pretende usar las herramientas automáticas.
• Apresurarse debido a la percepción de la presión del tiempo y cometer errores por descuido
• Pobre disciplina de control de fuente que introduce conflictos ("¡sobrescribió mi código!")
• Arquitectura deficiente o inconsistente que dificulta la comprensión del flujo de la lógica de la aplicación. Esto podría manifestarse porque los miembros de su equipo actual, reunidos como usted mencionó de otras áreas, no pueden entender la intención del desarrollador original al escribir ciertas partes de la solución y les resulta difícil lograr que las nuevas características funcionen como esperaban.

Mientras que el segundo podría ser:

• El propietario del producto no es lo suficientemente específico al describir la historia o las hace demasiado generales y asume que se entiende su intención.
• No elaborar lo suficiente en el refinamiento para garantizar que los desarrolladores entiendan la intención
• No estar de acuerdo con un enfoque lo suficientemente definido para completar la historia, por lo que los desarrolladores entran en conflicto sobre cómo se debe implementar la historia.

Un equipo sin una visión de cómo se pueden mejorar estos problemas, probablemente no le dará estas respuestas, ya que en su mayor parte son una cuestión de grado. Para los puntos técnicos, es posible que se encuentre en una situación en la que los miembros del equipo hayan renunciado a tratar de explicar su punto de vista entre sí, o posiblemente a una persona en particular. Esto promovería un entorno donde la deuda técnica se acumula porque el equipo no está de acuerdo sobre cómo mantener una buena calidad de código.

Del mismo modo, para aquellos puntos relacionados con los requisitos, su descripción suena como si tuviera un propietario del producto que se niega a adaptar su forma de trabajar a las necesidades del equipo. Definitivamente podría analizar la redacción, la granularidad y la especificidad de las historias que produce el propietario de su producto, y su papel como experto en scrum le da una posición sólida para insistir en que se mejoren si faltan.

Desde el punto de vista de los desarrolladores, otras respuestas se concentran demasiado en las prácticas teóricas. Para tener respuestas concretas, es esencial saber a qué tipo de tareas se enfrentan los desarrolladores.

Además, la mayor parte del tiempo, el problema no es la tarea recuperada, sino alguna otra tarea en la cola de prueba.

Esa oración sugiere que hay una discrepancia entre lo que los desarrolladores piensan que deberían hacer y lo que el sprint piensa qué tareas deberían ser en este sprint.

Por ejemplo, actualmente estoy trabajando en un proyecto que es en gran medida una refactorización. Mis tareas son todas a nivel arquitectónico. Todos mis cambios son enormes y afectan a cerca de 100 archivos por función. Los errores que crea el probador son muy pequeños, algunos casos de uso oscuros o inconsistencias entre plataformas.

La cuestión es que, desde mi punto de vista, el proyecto no está en la etapa en la que puedo darme el lujo de trabajar durante horas en algún problema de esquina al azar. El código es tan parecido a un espagueti, que si empiezo a rastrear dónde se encuentra el error, encontraré que un elemento de datos en particular es parte de un objeto, que crea otro objeto y pasa los datos junto con otro nombre, que modifica el data y lo pasa a otro objeto con un tercer nombre diferente, que lo pasa modificado, que lo pasa... Tomará horas y horas corregir pequeños errores de esta manera. Primero tengo que hacer el trabajo de arquitectura.

Nuestras prácticas de boletos son muy flexibles, así que lo descubrimos. 1) Si hay algún pequeño error que pueda hacer junto con mis grandes tareas en una hora más o menos, lo haré. 2) Si el problema está en el código que aún no he refactorizado, moveré el error al backlog. 3) Otro desarrollador que no es responsable de la arquitectura, toma cualquier error que sea factible, pero que no se puede priorizar sobre los cambios de arquitectura.

Si su proyecto es como el nuestro, no creo que la culpa sea de los desarrolladores o probadores. Los evaluadores están haciendo un gran trabajo al encontrar los errores, pero no todos son relevantes para los desarrolladores. Los desarrolladores están haciendo un gran trabajo con el código, pero no pueden evitar pasar por alto los detalles. En este caso, parece que el problema es que el proceso es demasiado inflexible y el sprint tiene tareas que no pertenecen allí.

Realmente me gustan algunas de las otras respuestas, pero solo quería recordarles otra herramienta en la caja de herramientas: el límite de trabajo en progreso.

Establezca un límite en la columna 'listo para la prueba', así como en las columnas 'en prueba' y 'en desarrollo'. Esto significará que algunos desarrolladores no podrán realizar nuevas tareas y, por lo tanto, pueden estar más motivados para ayudar a los evaluadores a realizar sus tareas actuales. O simplemente pueden usar el tiempo extra para reforzar las pruebas unitarias, etc. para sus tareas en espera de probadores.

Combine esto con no agregar más tareas al sprint de las que el equipo puede hacer de manera confiable, y una retrospectiva regular para descubrir otros bloqueadores.

Una perspectiva de desarrollador

Muy simple...

¡Trabaja por delante!

Entregar e implementar funciones a lo largo del ciclo de sprint significa que las pruebas de control de calidad se realizarán durante todo el ciclo de sprint y los desarrolladores responderán a los comentarios de control de calidad desde el principio y tendrán tiempo para trabajar en los elementos del próximo sprint, ¡y así sucesivamente!

¿¡PERO CÓMO!?

¡Esta es en realidad una regla de scrum ágil que es más ignorada entre los maestros de scrum semiprofesionales! La regla es subestimar y

¡espéralo!

Siempre asuma una carga de trabajo por desarrollador que se realizará en MENOS DE días de ciclo de sprint para garantizar que se complete el trabajo MIENTRAS deja espacio para las pruebas.

Aquí hay un artículo completo sobre cómo pude vencer los problemas de las pruebas ágiles. ¡Resolví el problema del cuello de botella de las pruebas ágiles!

https://medium.com/@salibsamer/i-resolvió-scrum-sprint-end-testing-bottleneck-problem-bfd6222284a1