Pasar del modelo de sprint de desarrollo de 2 semanas / sprint de control de calidad de 1 semana a un modelo de sprint "verdadero" de 2 semanas: ¿sugerencias?

Habiendo pasado por algo similar yo mismo, aquí hay algunas consideraciones. Intentaré no extenderme demasiado, pero hay algunos aspectos de Scrum que deben mencionarse.

1. Hacer este tipo de cambio puede ser extremadamente beneficioso, pero ante todo necesita la aceptación de los desarrolladores . Si no admiten cambios, no funcionará, y Scrum debe ser ejecutado por los desarrolladores.

Los equipos de desarrollo están estructurados y autorizados por la organización para organizar y gestionar su propio trabajo. La sinergia resultante optimiza la eficiencia y eficacia general del Equipo de Desarrollo. http://www.scrumguides.org/scrum-guide.html

Con eso en mente, me aseguraría (si aún no lo ha hecho) de mencionar los desafíos que tiene su proceso actual, revisar los principios de scrum y la razón por la que existen, y luego preguntarle al equipo de desarrollo qué se debe hacer para hacer esto. trabaja. Guíelos en la dirección correcta en lugar de decirles, y el equipo tendrá mucho más éxito. Como dije, es posible que ya lo estés haciendo de esa manera, pero vale la pena mencionarlo.

Si puede mostrar el éxito a través de su equipo empoderado haciendo mejoras, también lo ayudará a impulsar más cambios y aceptación en el lado comercial.

2. El principal cambio de proceso para ayudar en este trabajo es involucrar a todo el equipo lo antes posible . Lo que quiero decir con eso es asegurarme de que los desarrolladores y el control de calidad trabajen juntos desde el comienzo del sprint. Todos deben estar presentes en las reuniones de scrum y trabajar juntos para completar el objetivo del sprint. La mejor manera que he encontrado para hacer esto es la siguiente:
   • Asegúrese de que cada miembro del equipo conozca el lado comercial del proyecto, el por qué, el caso de uso y el valor que aportará. Deles la oportunidad de hacer preguntas desde el principio (en realidad, prefiero que esto suceda antes de que el propietario del producto haya mostrado algo a las partes interesadas, los ejecutivos y los clientes. Sin embargo, eso no siempre es necesario si tiene una orden de compra increíble).
   • Haga que el control de calidad revise cada historia antes de que comience el trabajo (por ejemplo, en la planificación de tareas pendientes o en la planificación de sprints) y pídales que agreguen sus criterios de aceptación. Esto asegurará que el control de calidad esté familiarizado con la tarea y que los desarrolladores estén pensando en lo que debe hacer antes de comenzar a codificar. También creará una conversación temprana si hay confusión en cuanto al resultado deseado, y dejará en claro que los desarrolladores y el control de calidad deben trabajar juntos. (Algo que me gusta hacer aquí es darles a todos el resto del día después de la planificación del sprint para revisar las historias, entrar en el código, investigar, agregar notas, etc... y luego darles la oportunidad de hacer preguntas de seguimiento al siguiente día. Esto también puede ser muy útil para adelantar preguntas al PO, de modo que no lleguen todas al mismo tiempo hacia el final del sprint) .
   • Divida las historias lo más pequeñas posible . Esto garantizará que las historias lleguen al control de calidad de manera muy rápida y constante, de modo que puedan probarse básicamente desde el primer día del sprint. Esto también alentará a los desarrolladores a probar su propio código (que deberían estar haciendo) antes de que llegue al control de calidad y reducir la carga del control de calidad al final del sprint.
   • Impulse la idea de que todo el equipo (desarrollo y control de calidad) es responsable de lograr el objetivo del sprint . Ajuste las columnas de su tablero de scrum si es necesario, pero asegúrese de que el equipo comprenda que es responsabilidad de todo el equipo completar el alcance del trabajo en el sprint. Esta es una de las principales razones por las que Scrum no reconoce ningún otro título que no sea el de desarrollador en el equipo de desarrollo.

     Scrum no reconoce títulos para los miembros del Equipo de Desarrollo que no sean Desarrollador, independientemente del trabajo que realice la persona; No hay excepciones para esta regla; http://www.scrumguides.org/scrum-guide.html

La razón de esto no es hacer las cosas más difíciles, sino garantizar que el equipo trabaje en conjunto hasta que hayan logrado el objetivo del sprint con su Definición de Terminado.

3. Mencionaste que los desarrolladores se comprometieron con el trabajo de sprint. Como parte de lo que dije anteriormente, asegúrese de que Dev y QA se comprometan con el trabajo de sprint . Están juntos en esto y necesitan apoyarse mutuamente por igual. El trabajo de control de calidad debe reflejarse en su estimación.

4. Nuevamente, mencione estas cosas en retrospectivas. Obtén ideas y comprométete con el equipo. Muestre mejoras en el negocio para que vean cómo es efectivo empoderar al equipo. A medida que realiza cambios, descubra qué funciona y qué no, y adáptese, sea ágil. Recuerde que Agile y Scrum son marcos destinados a brindarle formas de realizar grandes cambios rápidamente para lograr la mejor calidad de trabajo que satisfaga las necesidades de los clientes.

Como nota final, recuerde que Velocity no es para comparar el progreso del equipo entre sí, ni para informar a los ejecutivos por sí solo. Es determinar cuánto trabajo puede hacer el equipo en un sprint determinado.

Algunas sugerencias:

Automatice tanto como sea posible sus pruebas de regresión. Esto deja al control de calidad libre para centrarse en la nueva funcionalidad. Esto permite que el equipo pruebe a medida que avanza en un sprint, en lugar de esperar el final.

Piense detenidamente en la forma en que utiliza la numeración de versiones y los entornos. Por ejemplo, algunos equipos con los que he trabajado harán una caída en un entorno de control de calidad cada pocos días en un sprint. Cuando adopta este enfoque, es importante detectar errores en una versión determinada para que no haya confusión con el trabajo en curso.

Buscar la integración continua entre los equipos. No esperes al final del sprint para hacer esto. Aún mejor, combine la integración continua con la automatización de pruebas de regresión para obtener comentarios regulares sobre el código fusionado.

Además, planee con cuidado. Si desea realizar pruebas durante todo el sprint, debe tener historias pequeñas sin dependencias. Siempre tenga una conversación durante la planificación sobre lo que probará primero y qué tan rápido estará listo. Por ejemplo, un equipo podría apuntar a tener las primeras historias listas para probar después de 2 días del sprint. Si tiene una historia que será particularmente difícil de probar, entonces no tiene sentido comenzar a probar el último día del sprint. Busque abordarlo temprano en el sprint con tiempo suficiente para probar.

Finalmente, fomente la comunicación entre los miembros del equipo. Deje de pensar en las pruebas como una actividad de control de calidad. Es una actividad de equipo e involucra a todos (incluido el propietario del producto).

Obviamente, su primer obstáculo será conseguir la aceptación, tanto de la alta dirección como del equipo. Pero suponiendo que ya lo tengas...

Un problema con el que se puede encontrar es que el control de calidad no está suficientemente trabajado al comienzo de los sprints cuando no hay mucho que probar, mientras que los desarrolladores no están suficientemente trabajados hacia el final, cuando la mayoría de las historias están en control de calidad. Si bien la utilización del 100% es una falacia, tampoco es deseable una infrautilización severa.

Hay otras preguntas y respuestas sobre esto, pero la conclusión básica es tratar de encontrar tareas alternativas para llenar los horarios más ligeros. Idealmente, los desarrolladores deberían poder ayudar con las pruebas y el personal de control de calidad debería poder ayudar con el desarrollo. Por supuesto, en realidad, uno o ambos a menudo no son más que un sueño imposible.

Dicho esto, hay cosas que tanto los desarrolladores como el personal de control de calidad podrían hacer para ocupar su tiempo de manera productiva, incluidas, entre otras, las siguientes:

• Escribir más pruebas (ya sean de unidad, integración, aceptación, lo que sea).
• Realización de picos.
• Investigando nuevas tecnologías.
• Abordar la deuda técnica.
• Refinamiento de la cartera de pedidos.
• Trabajando en proyectos paralelos más pequeños/de menor prioridad.

Además, vale la pena señalar: mencionó que actualmente tiene un calendario de lanzamiento trisemanal y se está moviendo hacia sprints de dos semanas. ¿Has considerado los sprints de tres semanas? Esto podría ser esencialmente lo mismo que está planeando, solo que sin estropear el patrón de programación de lanzamiento arraigado de su organización.

He encontrado algunos problemas similares en uno de mis proyectos. Al igual que el suyo, uno de mi equipo tuvo esfuerzos de prueba acumulados hacia el final del sprint. Cuando las historias estaban incompletas (es decir, no se realizaron pruebas en este caso), provocaba que las historias se trasladaran al siguiente sprint, se interrumpía el flujo, se retrasaba la entrega, se producían problemas de coordinación (entre control de calidad y desarrollo), caos, etc.

La forma en que salí de esto es desarrollando esta mentalidad : lo que comprometemos en un sprint TIENE que terminar dentro del sprint.
Pida al equipo que calcule y elija las historias que creen que pueden desarrollarse, probarse y estar listas para implementarse dentro del plazo de 2 semanas.

Es difícil hacer este cambio, pero los equipos mejoran a medida que practican esto algunos sprints. Para empezar, es posible que tenga negocios que se quejen de la entrega lenta, que el equipo no llegue a una conclusión fácilmente y mucho más. Pero hazlo suave y lentamente.

Factores indispensables en los que centrarse:

1. Comience su sprint con planificación.
2. Establece un objetivo de Sprint.
3. Haga historias más granulares, más pequeñas y COMPROBABLES.
4. Planificar juntos como equipo (desarrolladores y control de calidad involucrados)
5. Calcule una tarea/historia considerando el desarrollo, las pruebas, la implementación (scripts, cambios de configuración, etc.), todos los aspectos para que esa historia cobre vida o se alinee con la definición (DOD) de hecho.
6. Entrene al equipo para hacer BDD o TDD, lo que promueve la participación de QA en las primeras etapas del desarrollo.
7. Las retrospectivas son muy útiles en situaciones como esta para comprender qué funciona y qué no. Adaptarse en consecuencia.
8. Mejore el proceso, pero introduzca mejoras lenta y gradualmente. Realice una planificación previa y una preparación del trabajo pendiente una vez que las cosas estén estables. Dale un poco de ritmo al proceso. (Esto me resultó muy útil porque me ayudó a administrar las expectativas comerciales mejor que antes).
9. Medir el progreso: utilicé el gráfico de quemado todos los días en la puesta en marcha para llamar la atención de todos sobre cualquier retraso.
10. Apoye sinceramente y de todo corazón al equipo, ya que los cambios/cambios en la forma de trabajar pueden causar problemas de moral/motivación.

Espero que esto ayude.

Ha cometido un error crítico en su comprensión de cómo funcionará esto.

No pasará de un ciclo de lanzamiento de 3 semanas a 2 semanas. Está pasando de 3 semanas a 6 semanas.

Los problemas que experimenta con los desarrolladores que se comprometen con un sprint y el "ataque de errores" no se deben a una desconexión entre ellos y el control de calidad, sino a la adición de tareas a un sprint en curso.

Este problema solo se agravará si permite que el control de calidad agregue errores en el sprint actual en curso para que su ciclo sea:

S1: desarrollador de funciones con algunas funciones probadas.

S2: pruebe las funciones restantes y el desarrollador S1 informó errores.

S3: dev S2 informó errores. Control de calidad final y aprobación. Inicie las características de la rama de la próxima versión porque no queda suficiente trabajo de desarrollo

Un mejor enfoque es tener sprints de desarrollo y prueba compensados ​​pero de igual duración y hacerlos 1 semana

Características de la versión 1 de desarrollo de S1

S2 prueba las características de S1, características de la versión de desarrollo 2 en una nueva rama

La versión de prueba 2 de S3 incluye errores informados por el desarrollador S2

Versión 1 al final de S3

S4 dev S3 informó errores

Versión 2 al final de S4

Si la prueba tiene 'tiempo de inactividad', deben usarlo para escribir las pruebas para el siguiente conjunto de funciones antes del desarrollo.