¿Cómo rompo las barreras entre el desarrollo y el control de calidad en un proyecto ágil?

Question

He estado aplicando agile durante unos meses en mi proyecto. Sin embargo, estamos viendo un problema constante con nuestras iteraciones burndowns. No estamos llegando a cero en cada iteración.

Las tareas restantes son tareas de control de calidad. Cosas como escribir pruebas, pruebas, etc.

Ahora, hay cierta resistencia organizativa a la idea del "equipo multifuncional" de ágil. Dev se desarrolla para proyectos individuales, pero los probadores se comparten para proyectos múltiples. Lo cual es completamente contrario a la idea ágil de Dev y QA trabajando juntos.

El hecho de que el tiempo de mi comprobador se haya dividido entre tantos otros proyectos es la causa de nuestra ralentización. Los desarrolladores están probando tomar tanta holgura como pueden, pero algunas tareas aún no se están logrando.

Por lo que veo, puedo hacer dos cosas:

1. persuadir a la organización para mover hacia "cada proyecto que tiene una persona QA dedicado"
2. cambiar mi definición de "Hecho" a no incluye el trabajo de QA/Testing. Sin embargo, las cosas seguirían siendo probadas en unidades.

Prefiero evitar el # 2, ya que valoro la colaboración de prueba que estamos haciendo.

¿Qué consejo tienes para mi situación?

Answer 1

Es una situación difícil y, lamentablemente, muchas empresas que intentan seguir Agile no lo reconocen. No es necesario que tenga una persona de control de calidad dedicado, incluso con recursos ágiles que podrían dividirse entre diferentes tareas. DEBES incluir tu QA en tu seguimiento de progreso.

Sí, su progreso será más lento. Hay una buena razón para eso (no tiene suficientes recursos de control de calidad) y debe explicarlo a la gerencia de su organización con las cifras disponibles. Te ayudará a persuadirlos de que debe haber algún cambio.

También podría avanzar hacia pruebas más automatizadas y usar sus desarrolladores para ayudar a los evaluadores con la automatización de pruebas. Esto distribuirá la carga de manera más uniforme y mejorará la calidad de la garantía de calidad en su proyecto

Answer 2

No creo que pueda llamar lo que está haciendo ágil a menos que todos estén metidos en ello. Haga que el probador se siente físicamente cerca de los desarrolladores (al menos por el tiempo que el probador está trabajando en las tareas para su proyecto, como crear los planes de prueba), esto puede aumentar la comunicación y obtener los QAs para comprar.

Answer 3

Puede considerar la garantía de calidad como clientes para los desarrolladores. Entonces, cuando Devs se lanza al final de una iteración para QA, la iteración termina.

Los comentarios del cliente (errores que deben corregirse) pueden entrar en el trabajo que se realizará para la próxima iteración.

Answer 4

Para que esto funcione, debe obtener los QAs para dedicar el tiempo adecuado al proyecto. Es posible que tenga que trabajar con su administración para obtener cierta cantidad de tiempo para que trabaje en su proyecto. De esta forma, podría programar su tiempo y saber exactamente cuánto trabajo pueden hacer sus desarrolladores que el equipo de control de calidad tendrá tiempo de probar.Esto puede requerir que se reduzca el desarrollo para compensar el soporte reducido de QA.

No menciona qué parte de sus pruebas está automatizada. Es posible que pueda aumentar la automatización de las pruebas para reducir el tiempo que el equipo de control de calidad necesita para certificar el proyecto. Podría usar parte de su tiempo de desarrollo para preparar las pruebas de control de calidad para que se ejecute el equipo de control de calidad. No es óptimo, pero podría ser útil.

Answer 5

En el corto plazo, deje de utilizar los recursos de control de calidad que no pueden encajar en su proceso y realice estas tareas con aquellas que pueden dedicarse según sea necesario. Me doy cuenta de que esto no es ideal, pero hay una situación subóptima en la que tienes una estructura organizacional que no coincide con tus procesos. Tal vez descubra que funcionará bien (y aprenda sobre las pruebas en el proceso).

A largo plazo, las opciones son

• encontrar una manera para que esto funcione con la estructura/proceso de organización dada
• cambio de la estructura organizativa sea adecuado para el proceso
• chagne el desarrollo proceso para ser adecuado para la organización

Answer 6

Creo que QA tiene mucho más para ofrecer en un entorno ágil que solo el trabajo de prueba. Si QA tiene conocimientos suficientes sobre el flujo de trabajo y las diferentes ramas del mismo, uno puede estar en el asiento del conductor para conducir el resto del proceso de scrum. QA puede involucrarse con los desarrolladores para diseñar los flujos de trabajo lógicos que, en última instancia, impulsarán los casos de prueba. De esta forma, uno puede eliminar gran cantidad de errores relacionados con el diseño y el flujo de trabajo durante el proceso de desarrollo antes de que entren en el entorno de control de calidad.