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

Question

he estado aplicando ágil desde hace unos meses en mi proyecto.Sin embargo, estamos viendo un problema constante con nuestra quema de iteraciones.No llegamos a cero en cada iteración.

Las tareas restantes son tareas de control de calidad.Cosas como escribir exámenes, realizar pruebas, etc.

Ahora, existe cierta resistencia organizacional a la idea ágil de "equipo multifuncional".Los desarrolladores se desarrollan para proyectos individuales, pero los probadores se comparten para múltiples proyectos.Lo cual es bastante contrario a la idea ágil de que los desarrolladores y el control de calidad trabajen juntos.

El hecho de que el tiempo de mi evaluador se divida entre tantos otros proyectos es la causa de nuestra desaceleración.Los desarrolladores están probando para aprovechar la mayor cantidad de tiempo posible, pero algunas tareas aún no se pueden realizar.

Por lo que veo puedo hacer dos cosas:

1. Persuadir a la organización para que se mueva hacia "cada proyecto que tenga una persona de control de calidad dedicada"
2. Cambie mi definición de "Hecho" para no incluir el trabajo de QA/Prueba.Sin embargo, las cosas aún se probarían unitarias.

Prefiero evitar hacer el número 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 tener una persona dedicada al control de calidad; incluso con Agile, los recursos se pueden dividir entre diferentes tareas.DEBE incluir su control de calidad en el seguimiento de su progreso.

Sí, tu progreso será más lento.Hay una buena razón para ello (no tiene suficientes recursos de control de calidad) y debe explicárselo a la dirección de su organización con las cifras en la mano.Le ayudará a persuadirlos de que es necesario realizar algún cambio.

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

Answer 2

No creo que puedas llamar ágil a lo que estás haciendo a menos que todos estén involucrados.Haga que el evaluador se siente físicamente cerca de los desarrolladores (al menos durante el tiempo que el evaluador esté trabajando en tareas para su proyecto, como la creación de planes de prueba), esto puede mejorar la comunicación y hacer que los controles de calidad la acepten.

Answer 3

Para que esto funcione, debe conseguir que los controles de calidad dediquen el tiempo adecuado al proyecto.Es posible que deba trabajar con su gerencia para reservar ciertos espacios de tiempo para que trabajen en su proyecto.De esta manera, podrá programar su tiempo y saber exactamente cuánto trabajo pueden hacer sus desarrolladores para que el equipo de control de calidad tenga tiempo de probar.Esto puede requerir que usted reduzca el desarrollo para compensar el soporte reducido del control de calidad.

No menciona cuántas de sus pruebas están automatizadas.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 utilizar parte de su tiempo de desarrollo para preparar las pruebas de control de calidad para que las ejecute el equipo de control de calidad.No es óptimo, pero podría ayudar.

Answer 4

Creo que el control de calidad tiene mucho más que ofrecer en un entorno ágil que solo el trabajo de prueba.Si el control de calidad tiene el conocimiento suficiente sobre el flujo de trabajo y sus diferentes ramas, uno puede estar en el asiento del conductor para dirigir el resto del proceso de scrum.El control de calidad puede colaborar con los desarrolladores para diseñar los flujos de trabajo lógicos que, en última instancia, impulsarán los casos de prueba.De esta manera, se pueden eliminar muchos errores relacionados con el diseño y el flujo de trabajo durante el proceso de desarrollo antes de ingresar al entorno de control de calidad.

Answer 5

Podría considerar a QA como los clientes de los desarrolladores.Entonces, cuando los desarrolladores lanzan al final de una iteración de control de calidad, la iteración finaliza.

Los comentarios del cliente (errores que deben corregirse) pueden incluirse en el trabajo a realizar para la siguiente iteración.

Answer 6

A corto plazo, deje de utilizar los recursos de control de calidad que no pueden encajar en su proceso y asuma estas tareas con aquellos que puedan 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.Es posible que descubra que todo funcionará bien (y aprenderá a realizar pruebas en el proceso).

A largo plazo, sus opciones son

• encontrar una manera de que esto funcione con la estructura/proceso organizacional dado
• cambiar la estructura organizacional para que sea adecuada al proceso
• Cambiar el proceso de desarrollo para que sea adecuado a la organización.