Los QA obtienen todo el trabajo al final del Sprint

No debe considerar el desarrollo y las pruebas como actividades secuenciales dentro del sprint, o sucede lo que describe. El desarrollo y las pruebas deben ocurrir juntos como una colaboración entre desarrolladores y evaluadores. Requiere un cambio en la forma de trabajar. Vea más detalles aquí: ¿Qué hace un equipo de control de calidad durante la fase de desarrollo de un sprint en Agile Scrum?

Hasta que introduzca este tipo de cambio, al menos debe dividir los PBI en pequeñas historias que desarrolle y pruebe de inmediato, en lugar de esperar hasta el final del sprint (es decir, reducir al máximo la distancia entre las actividades de desarrollo y prueba) .

Sí. Una regla general común para un sprint de dos semanas es que la mayoría de los elementos del backlog deben tardar de 2 a 3 días en completarse, incluido el control de calidad, la implementación, etc. Sin embargo, esto es solo sabiduría para equipos experimentados, no una regla estricta. También llevará tiempo llegar allí. Si el equipo está acostumbrado a que un elemento pendiente tarde 2 semanas completas en completarse, no van a saltar a 2 días de inmediato.

Hay tres prácticas que consideraría para ayudar a su equipo:

1. Desglose de los elementos de la cartera de pedidos en retrospectiva. Es común que el equipo no sepa cómo desglosar los elementos pendientes cuando comienzan. Una buena manera de aprender es tener una breve discusión una vez que el elemento esté completo y hacer la pregunta: "Si pudiera retroceder en el tiempo sabiendo lo que sé ahora, ¿cómo podría desglosarlo más pequeño?" Luego puede llevar esas lecciones con usted a elementos similares en el futuro.

2. Mueva las pruebas y el control de calidad antes en el proceso de desarrollo. TDD, ATDD y BDD son excelentes formas de adelantar una gran parte de las pruebas al desarrollo y simplificar el proceso de desarrollo. Estos se sienten demasiado extremos, pruebe con una simple reunión de tres amigos. En estas reuniones, un programador, un probador y un representante comercial/usuario tienen una conversación antes de que comience el trabajo. Esto pone sobre la mesa muchas de las ideas de prueba y funcionalidad antes de que se escriba una línea de código y reduce seriamente las transferencias de ida y vuelta.

3. ¡Agrupar! De todos los equipos con los que he trabajado, el problema que estás describiendo casi siempre viene con personas que aplican un enfoque de divide y vencerás al trabajo. Este enfoque suele ser más eficiente en el tiempo en el primer paso, pero pierde mucho más tiempo en la integración, el intercambio de conocimientos y las pruebas. Elija uno o dos elementos y agrúpelos con un enfoque en terminar rápidamente algunos elementos en lugar de comenzar muchos elementos.

Cualquiera de estos ayudará, pero también se pueden usar juntos. ¡Toda la suerte!

Hay algunas maneras diferentes de abordar este problema.

Desde la perspectiva de Scrum, su equipo de desarrollo no tiene subequipos. Puede tener especialistas, como personas que se especializan en pruebas, pero todo el equipo debe estar involucrado. En lugar de poner a los especialistas de control de calidad en una posición en la que deben probar todo al final del Sprint, todo el equipo debe participar en las pruebas, siempre que se produzcan. Los especialistas en control de calidad pueden ayudar a capacitar al resto del equipo en buenas prácticas de prueba.

No es específico de Scrum, entregar el trabajo de manera incremental a lo largo del Sprint e integrarlo y probarlo continuamente también ayudaría a aliviar parte de la presión. En lugar de realizar pruebas al final del Sprint, realice pruebas a medida que finaliza el trabajo. Si está esperando hasta el final del Sprint para integrar el trabajo, intente integrarlo antes. Si parece que no puede, podría ser una señal de que su trabajo no está bien dimensionado o dividido.

Finalmente, en algunos entornos, puede haber buenas razones para tener control de calidad independiente. Los primeros dos puntos aún se aplican, y el Equipo de Desarrollo debería producir un producto de alta calidad. Sin embargo, cualquier integración y prueba independientes deben trasladarse fuera del Sprint a un equipo separado. Si el Equipo de desarrollo ha hecho un buen trabajo, este equipo puede tener comentarios, pero no debería encontrar problemas regularmente que impidan que la salida de un Sprint se pueda enviar al siguiente proceso posterior.

Dado que esta pregunta es un duplicado exacto de una pregunta en Software Quality Assurance & Testing Stack Exchange , este es un duplicado exacto de mi respuesta allí, ya que es igualmente aplicable.

Trate de identificar la causa del problema primero. Puedo sugerir algunas causas posibles:

1. Los sprints son demasiado largos. De cinco a diez días hábiles es una buena duración para un sprint. El problema con los sprints de mayor duración es que la estimación tiende a ser más difícil, es más probable que el equipo se comprometa demasiado, cambie demasiado el contexto y luego se encuentre con problemas imprevistos.

2. Trabajo inesperado. Una vez más, esto puede deberse a que los sprints son demasiado largos, lo que significa que surgen elementos inesperados que deben abordarse antes de que finalice el sprint. Los problemas con la gestión y priorización de recursos también pueden ser un factor.

3. Estimación defectuosa. El equipo debe pronosticar durante la planificación del sprint lo que puede lograr de manera realista durante un sprint. Evite la estimación absoluta (días y horas). Si el equipo siente la necesidad de evaluar los elementos pendientes en términos numéricos, utilice la estimación relativa (puntos). La velocidad de sprint anterior es una buena guía de lo que se puede completar, pero es solo una guía y el juicio del equipo es más importante que el número que le asignan a la velocidad. Si con frecuencia tiene trabajo incompleto en un sprint, eso sugiere que el equipo no está inspeccionando y adaptando en función de su desempeño anterior.

4. Falta de automatización de pruebas. La creación de pruebas puede y debe hacerse en paralelo con el desarrollo del código. Si tiene sus pruebas creadas y un marco de automatización adecuado, la ejecución automatizada debería tomar muy poco tiempo.

5. Disciplina débil del Departamento de Defensa. La definición de hecho significa que una historia está 100% terminada (pruebas incluidas, por supuesto) o 0% terminada. El equipo debe autoorganizarse para asegurarse de que todos se toman en serio al Departamento de Defensa.

Mi sugerencia sería:

• Invierta más en pruebas de regresión automatizadas
• Haga que el problema forme parte de su proceso de planificación: "¿Con qué ticket deberíamos comenzar primero para que podamos probarlo lo antes posible en el sprint?"