¿Deberíamos dejar de intentar ser ágiles si el control de calidad tarda 12 semanas?

Alguien en mi compañía recientemente propuso cambios en nuestro producto principal que nuestros gerentes creen que deberían desencadenar lo que supongo que mi compañía considera un ciclo de control de calidad completo (es decir, probar todo el conjunto de productos desde cero). Aparentemente, nuestro control de calidad tarda 12 semanas en hacer un ciclo completo de control de calidad para nuestro producto. Mi problema con esto es que estamos tratando de hacer un desarrollo ágil (aunque en su opinión a medias). Haremos un conjunto completo de sprints y luego haremos un lanzamiento, que el control de calidad llevará una eternidad, supongo. La pregunta es realmente, si nuestro control de calidad tomará 12 semanas para hacer su trabajo, ¿no deberíamos dejar de intentar Agile? ¿Cuál es el punto de tratar de hacer Ágil en una situación como esta?

Bueno, la respuesta directa a su pregunta sería Mu , me temo, simplemente no hay suficientes detalles para hacer una suposición informada sobre si debe o no dejar de intentarlo.

Lo único sobre lo que estoy bastante seguro es que el nivel de agilidad debe ser impulsado por las necesidades del cliente / mercado (sobre el que no dio información).

• ^{Por ejemplo, como usuario de IDE, estoy perfectamente feliz de actualizar a una nueva versión una o dos veces al año y nunca tengo prisa por hacerlo. Es decir, si su ciclo de lanzamiento es de 3 meses ( 12 semanas ), entonces estoy perfectamente feliz con eso.
   
  Por otro lado, puedo imaginar fácilmente, por ejemplo, que una empresa de comercio financiero quebrará si su software tarda más de un mes en adaptarse a los cambios del mercado; el ciclo de prueba de 12 semanas en este caso sería un camino al infierno. Ahora, ¿cuáles son las necesidades de su producto a este respecto?}

Otra cosa a considerar es qué nivel de calidad se requiere para satisfacer las necesidades de su cliente / mercado.

• ^{Caso en cuestión: en una empresa que trabajé una vez descubrimos que necesitamos alguna característica nueva en un producto con licencia de algún proveedor de software. Sin esta característica sufrimos bastante, así que sí, realmente queríamos que fueran ágiles y entregaran actualizaciones en un mes.
   
  Y sí, parecían ser ágiles y sí, lanzaron esa actualización en un mes (si su ciclo de control de calidad es de 12 semanas, entonces probablemente lo omitieron). Y nuestra función funcionó perfectamente bien. ¿Supongo que deberíamos haber sido perfectamente felices? ¡no! descubrimos un error de regresión showtopper en algunas funcionalidades que funcionaba bien antes, por lo que tuvimos que pegarnos y sufrir con la versión anterior.
   
  Pasó otro mes: lanzaron otra nueva versión: nuestra funciónestaba allí, pero también había el mismo error de regresión: nuevamente, no actualizamos. Y otro mes y otro.
   
  Al final, pudimos actualizar solo medio año después por su agilidad.}

Ahora, veamos un poco más de cerca estas 12 semanas que mencionas.

¿Qué opciones consideró para acortar el ciclo de control de calidad? Como puede ver en el ejemplo anterior, simplemente omitirlo podría no darle lo que espera, por lo que es mejor que sea ágil y considere diferentes formas de abordarlo.

Por ejemplo, ¿consideró formas de mejorar la capacidad de prueba de su producto?

¿O consideró la solución de fuerza bruta para contratar más control de calidad? Por simple que parezca, en algunos casos este es el camino a seguir. He visto a la gerencia sin experiencia tratando de solucionar los problemas de calidad de los productos mediante la contratación a ciegas de más y más desarrolladores senior en los que bastaría un par de probadores profesionales promedio . Bastante patético

El último pero no menos importante: creo que uno debería ser ágil con respecto a la aplicación misma de los principios ágiles. Quiero decir, si los requisitos del proyecto no son ágiles (estables o cambian lentamente), ¿por qué molestarse? Una vez observé que la alta gerencia obligaba a Scrum a proyectos que funcionaban perfectamente bien sin ellos. Qué desperdicio fue. No solo no hubo mejoras en su entrega sino que, peor aún, los desarrolladores y evaluadores quedaron descontentos.

actualización basada en aclaraciones proporcionadas en los comentarios

Para mí, una de las partes más importantes de Agile es tener un lanzamiento enviable al final de cada sprint. Eso implica varias cosas. Primero, se debe realizar un nivel de prueba para garantizar que no haya errores importantes si cree que podría lanzar la compilación a un cliente ...

Liberación de envío, ya veo. Hm. Hmmm Considera agregar un trago o dos de Lean a tu cóctel Agile. Quiero decir, si esto no es una necesidad del cliente / mercado, entonces esto solo significaría un desperdicio de recursos (de prueba).

Por mi parte, no veo nada criminal en tratar a Sprint-end-release como un punto de control que satisfaga al equipo.

• ^{dev: sí, ese se ve lo suficientemente bueno como para pasarlo a los evaluadores; QA: sí, uno se ve lo suficientemente bueno para el caso si se necesitan más pruebas de envío , cosas así. El equipo (dev + QA) está satisfecho, eso es todo.}

... El punto más importante que hizo fue al final de su respuesta en términos de no aplicar ágil si los requisitos no son ágiles. Creo que esto es perfecto. Cuando comenzamos a hacer ágil, lo tuvimos marcado, y las circunstancias tenían sentido. Pero desde entonces, las cosas han cambiado drásticamente, y nos estamos aferrando al proceso donde ya no tiene sentido.

Lo entendiste exactamente bien. Además, según lo que describe, parece que llegó al estado (madurez de equipo / administración y relación con el cliente) que le permite usar el desarrollo de modelos iterativos regulares en lugar de Scrum. Si es así, también puede interesarle saber que, según mi experiencia, en casos como ese iterativo regular, se sintió más productivo que Scrum. Mucho más productivo - no era simplemente por lo tanto menos gastos generales, era simplemente mucho más fácil centrarse en el desarrollo (por control de calidad para centrarse en la prueba, respectivamente).

• ^{Usualmente pienso en términos de Ferrari (como iterativo regular) vs Landrover (como Scrum).
   
  Al conducir en una autopista (y su proyecto parece haber llegado a esa autopista ) Ferrari le gana a Landrover.
   
  Es el todoterreno donde se necesita un jeep, no un auto deportivo; quiero decir, si sus requisitos son irregulares y / o si el trabajo en equipo y la experiencia de gestión no son tan buenos, tendrá que elegir Scrum, simplemente porque tratar de ir regularmente lo conseguirá pegado, como Ferrari se quedará fuera de la carretera.}

Nuestro producto completo está compuesto de muchas piezas más pequeñas que se pueden actualizar de forma independiente. Creo que nuestros clientes están muy dispuestos a actualizar esos componentes más pequeños con mucha más frecuencia. Me parece que quizás deberíamos centrarnos en liberar y QA'ing esos componentes más pequeños al final de los sprints en su lugar ...

Arriba suena como un buen plan. Trabajé en un proyecto así una vez. Enviamos lanzamientos mensuales con actualizaciones localizadas dentro de pequeños componentes de bajo riesgo y la aprobación de QA para estos fue tan fácil como parece.

• ^{Una cosa a tener en cuenta para esta estrategia es tener una verificación comprobable de que el cambio se localiza donde se espera. Incluso si esto llega a la comparación de archivos bit por bit para componentes que no cambiaron, hágalo o no lo enviará. La cuestión es que es el control de calidad el responsable de la calidad del lanzamiento, no nosotros los desarrolladores.
   
  Es un dolor de cabeza para el evaluador asegurarse de que no se hayan producido cambios inesperados, porque francamente, como desarrollador, tengo otras cosas de las que preocuparme y eso es más importante para mí. Y debido a eso, ellos (los probadores) realmente necesitan pruebas sólidas de que las cosas están bajo control con el lanzamiento que prueban para enviar.}

Oh, siento tu dolor. Hay algunos cambios serios que debe hacer al equipo de control de calidad para que esto funcione.

Mi consejo es dividir el equipo en tres equipos:

Pruebas de funciones: respuesta rápida para probar nuevos desarrollos.

Prueba de regresión: prueba completa del producto antes de que salga por la puerta. Esto no debería tomar 3 meses, incluso después de reducir el tamaño del equipo porque el primer equipo encontrará la mayoría de los errores.

Pruebas automatizadas : redacción de un conjunto completo de pruebas de regresión para acelerar el trabajo del equipo de pruebas de regresión.

El tercer equipo es un extra, pero si no puedes tener los dos primeros equipos, entonces también puedes ser una cascada.

A modo de ilustración:

Tenga en cuenta que su equipo de control de calidad probablemente esté trabajando fuera del círculo (ATDD), y usted está trabajando dentro.

Creo que está bien trabajar de esa manera; Si puede demostrar en sus pruebas automatizadas que cumple con los requisitos del cliente en cada sprint, puede permitir que QA realice sus pruebas a su gusto, y llegar a usted con defectos, que luego puede trabajar en el próximo sprint.

Parece que tiene un problema de "Definición de hecho".

Dado que su grupo de control de calidad es externo y solo participa en lanzamientos de clientes, no puede confiar en ellos para recibir comentarios oportunos sobre los problemas. Eso significa que si desea una retroalimentación rápida, tendrá que aportar cierto grado de pruebas "internas" para el equipo.

Trate al grupo de control de calidad como si no existieran. Actúe si su lanzamiento al final del sprint se implementará en su entorno más crítico al día siguiente. El software no se realiza hasta que esté listo para ir a los clientes.

El control de calidad no debe encontrar nada.

Esto será más difícil de alcanzar. Probablemente tendrás algunas cosas que se te escapan las primeras veces. Las pruebas de aceptación automatizadas y las pruebas de "regresión" son sus mejores amigos aquí. TDD lo ayudará a construir grandes partes de tales suites. Debería poder saber, rápidamente, si ha roto algo.

¿Tiene un representante del cliente / propietario del producto que puede ver una versión dada antes de que el control de calidad termine y le proporcione comentarios autorizados sobre ella? Si es así, puede hacer y tener la mayor parte del beneficio de los métodos ágiles mientras trata el control de calidad como una fuente secundaria de retroalimentación algo lenta. Un lanzamiento solo estaría "oficialmente listo" después de que el control de calidad haya terminado, pero no tendría que esperar antes de comenzar el siguiente.

Pero si las reglas de la compañía dicen que el cliente no debe ver un lanzamiento antes de que QA termine, entonces puede olvidarse de ser ágil, hasta que logre cambiar esas reglas.

El proceso que describió no es un proceso ágil. Los equipos que tienen un alto grado de agilidad pueden entregar construcciones confiables y potencialmente liberables en cada sprint. En la mayoría de las implementaciones ágiles, la función de control de calidad se construye dentro del equipo ágil que ayuda a lograr este objetivo.

Si usted, el líder de su proyecto, el propietario de su producto y los desarrolladores no están trabajando juntos y no tiene un plan de mejora (retrospectivas), asigne otro nombre a su proceso y continúe. No parece que los problemas de su equipo sean culpa de los gerentes o del control de calidad. Parecen estar reaccionando a algún problema sistémico que surge de la organización de desarrollo. No todo está perdido si el equipo está dispuesto a asumir la responsabilidad y comenzar a trabajar con las partes interesadas.

Podrías probar tres cosas. Primero, asegúrese de que cada parte interesada tenga roles definidos de manera concisa y que cada persona comprenda su responsabilidad. Dos, estabilice la compilación y luego obtenga la aprobación de QA sin introducir más cambios. Tres, instituto de automatización de pruebas. El equipo de control de calidad lo amará por ello.

Es una pena que los comentarios tarden tanto, pero no creo que valga la pena detenerse con agile. Al final de un sprint (o un par), lanzas un producto que estás seguro de que podría lanzarse al mercado. Para su equipo, Agile brinda la capacidad de concentrarse en el trabajo a realizar y mantener el producto liberable. Cuando el control de calidad encuentra problemas, sugiero crear informes de errores para estos problemas y abordarlos en el próximo sprint (si tienen una prioridad lo suficientemente alta).

Nuestras pruebas de campo de productos toman 8 semanas completas más que dependemos de productores externos. Aún así, al ser ágiles, podemos concentrarnos en el trabajo en cuestión y producir una nueva versión realmente rápida cuando sea necesario.

El problema radica (en sus ojos) en el departamento de control de calidad. ¿Se puede resolver el problema allí? ¿Lo has discutido?

12 semanas son largas, pero es de esperar que el control de calidad pueda proporcionarle comentarios e informes de errores durante ese tiempo (en lugar de después de los tres meses).

¡Entonces aún puede responder a los problemas más importantes de una manera ágil y puede solucionar muchos, si no todos, incluso antes de que hayan terminado!

¿Qué hacen las personas de control de calidad mientras ejecutas múltiples sprints? Parece que sienten la necesidad de probar todo después de cada cambio (razón por la cual esperan un montón de cambios).

El equipo de desarrollo es ágil, pero el resto de la empresa no lo es.

Quien está a cargo del control de calidad no sabe lo que está haciendo o ha realizado un truco mental Jedi en la alta dirección y se les permite tomarse su dulce tiempo. ¿Cómo puede llevar el control de calidad más tiempo que el desarrollo?