Dilema de QA vs. iteraciones

En mi empresa, trabajamos con éxito con prácticas ágiles, pero sin usar iteraciones. La razón principal es que no podemos encontrar una forma limpia de ajustar el control de calidad en un ciclo de iteración.

Entendemos el control de calidad como un poco de verificación adicional para una determinada compilación (candidato de versión) antes de que esta compilación se implemente para el cliente. El punto es evitar que un solo ataque malicioso dañe la versión completa. Como nunca se sabe cuál es, el control de calidad debe esperar hasta que todas las funciones / confirmaciones para el lanzamiento estén en la compilación. (No se permiten las últimas palabras famosas "Fue solo un pequeño cambio").

Si QA encuentra errores en un candidato de lanzamiento, los desarrolladores corrigen estos errores en la rama de lanzamiento respectiva (y los combinan en el tronco). Cuando se corrigen todos los errores, se implementa una nueva compilación para que QA vuelva a probar. Solo cuando no se encuentran errores en un determinado candidato de lanzamiento, se ofrece al cliente para su verificación.

Esto generalmente toma alrededor de dos o tres candidatos, aproximadamente una semana, por lanzamiento. El tiempo para escribir las soluciones suele ser mucho menor que los esfuerzos de prueba. Entonces, para mantener ocupados a los desarrolladores, trabajan en la versión N + 1 mientras que QA funciona en N.

Sin usar iteraciones, esto no es un problema porque podemos superponer el trabajo para las versiones N y N + 1. Sin embargo, por lo que entiendo, esto no es compatible con enfoques basados ​​en iteraciones como Scrum o XP. Exigen que una iteración sea liberable al final con todos los esfuerzos de prueba incorporados en la iteración.

Creo que esto necesariamente conduce a uno de los siguientes resultados no deseados:

(A) Los desarrolladores están inactivos al final de una iteración porque el control de calidad necesita tiempo para verificar un candidato de lanzamiento y el trabajo de corrección de errores no mantiene completamente ocupados a los desarrolladores.

(B) El control de calidad comienza a funcionar antes de que el primer candidato de lanzamiento esté listo. Esto es lo que se recomienda principalmente en Stack Exchange. Pero no es lo que mi empresa entiende como QA porque no se ha probado un candidato de lanzamiento específico. Y el "pequeño cambio" que rompe todo aún puede introducirse sin ser visto.

(C) Los errores se transfieren a la siguiente iteración. Esto también se recomienda en Stack Exchange. No creo que sea una solución en absoluto. Básicamente significa que nunca obtendremos una compilación verificada porque cada vez que se realizan correcciones de errores, también se agregan confirmaciones nuevas y no verificadas a la misma rama.

¿Hay alguna forma de salir de este dilema?

Entendemos el QA como un poco de verificación adicional para una determinada compilación (candidato de lanzamiento) antes de que esta compilación se implemente para el cliente.

No hay nada inherentemente incompatible entre esta forma de control de calidad y metodologías basadas en iteraciones como Scrum.
Dentro de Scrum, el equipo entrega una entrega en un ciclo X-semanal a su cliente. La parte importante aquí es que, si el equipo de desarrollo está haciendo Scrum, entonces su cliente es el equipo de control de calidad, no el usuario final de su producto.

Como desarrollador, consideraría un producto que se puede enviar a QA si tiene muchas posibilidades de pasar todas sus pruebas. Esto probablemente significa que algunas de las pruebas de control de calidad ya se han ejecutado en las compilaciones diarias, pero la forma en que eso afecta a las pruebas de lanzamiento oficiales del equipo de control de calidad depende de su organización.

Para la mayoría de las situaciones de la vida real, Agile se detiene en la entrega a QA / UAT o como se llame.

El esfuerzo de pasar del control de calidad a la producción en un entorno de la vida real a menudo se subestima. En muchos casos, esto implica que los usuarios comerciales reales realicen pruebas, la administración se desconecte de la línea real de gerentes comerciales, programe el lanzamiento con operaciones, etc., etc. ¡Esto no es trivial!

En casos extremos, el software puede necesitar certificación de agencias externas o estar sujeto a rigurosas pruebas de seguridad.

En estas circunstancias, es simplemente imposible prever más de una versión por trimestre, excepto las correcciones de errores.

Se pone peor para un producto de software serio. La documentación debe ser revisada y publicada. Los folletos de marketing deben modificarse. Los vendedores necesitan que se les diga lo que están vendiendo (¡no es una tarea fácil!), Etc., etc.

La solución a muy corto plazo es darle a QA un período de tiempo adicional después de su iteración para finalizar las pruebas. es decir. Si tiene una iteración de dos semanas, no lance hasta la semana 3. Los controles de calidad no tendrán nada que probar para la próxima iteración, durante la primera semana, de todos modos.

Pero te advertiré de antemano qué sucederá (habiendo visto esto en varios equipos): terminarás en una situación en la que una iteración consigues dos semanas de trabajo, el control de calidad está sobrecargado, vienen a ti por eso toda la semana de control de calidad y, en la siguiente iteración, solo realizará una semana de trabajo. Esa iteración, QA no tendrá nada que hacer y pensarás que has resuelto el problema. Pero luego, en la próxima iteración, comenzará el ciclo nuevamente.

Entonces, tan pronto como haya agregado esa semana, solo para asegurarse de que su lanzamiento sea estable (porque una cosa que he aprendido es que si pierde la fe del negocio, Agile se vuelve exponencialmente más difícil de implementar), siga recto en el plan a largo plazo.

Compre una copia de la entrega continua de Jez Humble , léala, de principio a fin, páselo al equipo. Haz que todos se inspiren. Luego implemente todo lo que pueda de él.

Haz que el proceso de construcción sea lo más hábil posible. Implemente una política de prueba unitaria y haga que se ejecuten en cada compilación. Haga que el proceso de implementación sea lo más hábil que haya visto. ¿Tres clics? No lo suficientemente hábil.

Una vez que hayas hecho todo esto, no importará mucho si el error de regresión ocasional pasa. ¿Sabes por qué? Porque podrá (opcionalmente) retroceder, arreglarlo e implementarlo nuevamente antes de que el negocio se desmorone. De hecho, el conserje nocturno podrá deshacerse de usted, el proceso será muy simple.

Sé lo que estás pensando: no tenemos tiempo para hacer todo eso. Déjame decirte, lo haces. Si está sobrecargando el control de calidad, está desplegando demasiado por iteración. Entonces no lo hagas. Si aún no los está sobrecargando, pregúnteles por qué todavía no tienen suites de pruebas automatizadas. Pronto lo estarás.

Haga todo esto con total visibilidad para el negocio. Estime más bajo e inyecte parte de este trabajo en la iteración. O, mejor aún, divídalo en historias y haga que lo prioricen, junto con todo lo demás.

Explíqueles que a) mejorará la estabilidad de la liberación yb) mejorará su capacidad de responder a los problemas para ellos yc) les comprará más velocidad más adelante. Es una compañía rara que no quiere estas cosas. Ciertamente, no es una empresa ágil que no los quiera, así que si obtienes resistencia, sabrás que tienes un problema diferente.

Una vez que tenga la entrega continua inactiva, puede comenzar a acortar el tiempo de control de calidad al final de la iteración. Es del interés de todos volver a poner las iteraciones en paralelo lo antes posible. Tal vez tengas un día al final de la iteración, donde debes completar el tiempo. Ya he respondido qué hacer al respecto en otro lugar .

Sin usar iteraciones, esto no es un problema porque podemos superponer el trabajo para las versiones N y N + 1.

Parece haber un problema con la forma en que decidió qué es exactamente lo que constituye work for release N.

Por alguna extraña razón (solo puedo suponer que hay algún malentendido de recetas ágiles particulares) de alguna manera decidiste que el enfoque ágil exige que todos los esfuerzos del equipo de control de calidad se incorporen en la iteración.

• ^{Si ese fuera realmente el caso, supongo que la popularidad de Agile no estaría ni cerca de lo que vemos ahora. No puedo imaginar muchos proyectos que puedan "sobrevivir" a la sincronización obligatoria de las iteraciones del equipo de desarrollo con los ciclos de prueba de control de calidad.}

Hay un poco más de agilidad a continuación, pero primero, solucionemos work for release N...

Mire, simplemente no hay una razón convincente para que el equipo de desarrollo defina el trabajo de esa manera. Todo lo contrario, según su descripción, está claro que en lugar de una "unidad de trabajo" monolítica, hay varias unidades de este tipo, con hitos que son fáciles de sentir ...

• ^{Por ejemplo, la primera "unidad" se indica con un hito distinto cuando la construcción del candidato se pasa a los probadores, y otros hitos corresponden a los cambios involucrados en los ciclos de prueba realizados por QA, etc.}

Tenga en cuenta también que la forma en que define work for release Nno está forzada por el flujo de trabajo de control de calidad tampoco. Por lo que describe, parece que las cosas tienen su propio horario (y bastante razonable).

Dado anteriormente, una forma más realista de definir unidades de trabajo en su caso podría ser la siguiente:

1. Actividades de desarrollo hasta el momento en que la compilación se pasa al control de calidad
   Release Candidate N
2. Actividades de desarrollo relacionadas con el primer ciclo de prueba de control de calidad
   Release Candidate N patch 1
3. Actividades de desarrollo relacionadas con el segundo ciclo de prueba de control de calidad
   Release Candidate N patch 2
4. etc, hasta la construcción final

Arriba están tus unidades de trabajo, no importa si haces Agile o lo que sea.

Estos son naturales y convenientes para definir, seguir y rastrear. Esto también combina bien con el cronograma de control de calidad, lo que permite una conveniente coordinación entre el odf dev y los esfuerzos de control de calidad.

Sin embargo, por lo que entiendo, esto no es compatible con enfoques basados ​​en iteraciones como Scrum o XP. Exigen que una iteración sea liberable al final con todos los esfuerzos de prueba incorporados en la iteración.

La comprensión anterior de la compatibilidad con Agile parece fundamentalmente incorrecta y esta es la razón ...

La suposición que hizo no tiene nada que ver con Agile, si tomamos su filosofía al pie de la letra como lo indica su propio nombre, ese es un enfoque que favorece y practica la agilidad .

Desde esa perspectiva, seguir un flujo de trabajo "fijo" particular e ignorar si es conveniente o no simplemente contradice el espíritu de Agile. Seguir el "procedimiento" servilmente conduce a prácticas denigradas tan elocuentemente en el Manifiesto Ágil Medio Arsed "... tenemos procesos y herramientas obligatorios para controlar cómo interactúan esos individuos (preferimos el término 'recursos')" .

Puede encontrar más información sobre esto en una respuesta a otra pregunta , citada a continuación. Eche un vistazo a la nota sobre "lanzamiento enviable", parece que entonces OP se ha confundido de manera similar:

uno debe ser ágil acerca de 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.

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, esto significaría solo 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.}