El costo de un retraso mayor entre el desarrollo y el control de calidad

En mi posición actual, el control de calidad se ha convertido en un cuello de botella. Hemos tenido la desafortunada aparición de características que se mantienen fuera de la compilación actual para que el control de calidad pueda terminar la prueba. Esto significa que las características que se están desarrollando pueden no probarse durante 2-3 semanas después de que el desarrollador ya haya avanzado. Con un desarrollador que se mueve más rápido que un QA, este intervalo de tiempo solo se hará más grande.

Sigo hojeando mi copia de Code Complete, buscando un fragmento de "Datos duros" que muestre que el costo de corregir defectos aumenta exponencialmente cuanto más tiempo exista. ¿Alguien puede señalarme algunos estudios que respalden este concepto? Estoy tratando de convencer a los poderes fácticos de que el cuello de botella de control de calidad es mucho más costoso de lo que piensan.

No necesitas referencias, en mi humilde opinión. Esto es lo que podría (más bien debería ) hacer:

¡Cuantifique el costo de la demora! Supongamos que lleva 1 semana probar las características. Un retraso de 2-3 semanas implica que la función no estará disponible hasta al menos la cuarta semana. Y eso también suponiendo un 100% de éxito. Agregue un tiempo de fijación de otra semana para que haya aproximadamente 5 semanas de retraso.

Ahora, si es posible, obtenga acceso a la fecha límite esperada del proyecto / función. ¿Para cuándo lo espera el cliente? ¿Se deslizará? Si no, ¿se deslizarán otros como consecuencia? Entonces, ¿cuánto se retrasará el 'lanzamiento' como resultado?

¿Cuál es el "costo para la compañía" para ese lanzamiento, es decir, cuánto espera el cliente beneficiarse de ese lanzamiento? Si esperan $ 5200 / año de ganancias de ese lanzamiento, cada semana que se desliza les cuesta $ 100 en ingresos perdidos. Esa es la opinión del cliente. Es posible que tenga o no acceso a estos datos, pero vale la pena tenerlo en cuenta y declarar cómo la demora puede afectar la relación.

Ahora, ¿cuál es la pérdida para los desarrolladores? Una vez que el desarrollador pasa a otras funciones, le pide que rompa su ciclo y 'arregle' la función anterior. ¿Cuál es la pérdida de tiempo / esfuerzo? Conviértalo en costo para la empresa utilizando el salario como un múltiplo por cada hora desperdiciada como resultado. Puede usar eso para decir la cantidad de "ganancias / ingresos" que los desechos están "comiendo".

Lo que ha tropezado puede cuantificarse convenientemente utilizando el "Costo de retraso", recomendado por Don Reinerstein en Principios del flujo de desarrollo de productos y también por Dean Leffingwell en Requisitos de software ágil. Debería ser capaz de respaldar cada reclamo por factores económicos para convencer a los 'poderes superiores' cuyo idioma principal es $$: debe hablar su idioma para convencerlos :)

Bestia de la suerte! (juego de palabras previsto :)

Realmente no creo que Code Complete sea ​​el recurso adecuado para usted aquí. Este no es un problema de código, es un problema de proceso y quizás un problema de administración.

Si parte de su proceso es particularmente débil, entonces es hora de revelar la Teoría de las Restricciones :

1. Identifica la restricción.

   Esto significa encontrar la parte más lenta o más ineficiente del proceso general. En tu caso, está probando. ¿ Pero qué parte de la prueba? Lo es:

   • ¿Preparando el entorno de prueba?
   • ¿Determinando qué probar?
   • ¿Pruebas funcionales (aceptación)?
   • Pruebas de regresión?
   • ¿Prueba exploratoria?
   • ¿Informar errores / defectos de las pruebas?
   • ¿Determinar los pasos para reproducir un error?
   • ¿Obteniendo aclaraciones de desarrolladores o gerentes de proyecto?
   • ¿Soluciona los problemas encontrados en la etapa de control de calidad?

   Todos estos son problemas muy diferentes y requieren soluciones diferentes. Debe decidir cuál es el más costoso / importante. Justificarlo a la gerencia no debería ser difícil, ya que todas las actividades anteriores cuestan tiempo (dinero AKA) y solo un par de ellas son tiempo de valor agregado.

2. Explotar la restricción.

   En otras palabras, a optimizar todo el proceso de restricción. Nunca dejes que los probadores estén inactivos. Esto esencialmente equivale a:

   • Poner probadores dentro de los equipos de desarrollo, si aún no lo están, para que haya un ciclo de retroalimentación continuo con los desarrolladores.
   • Tener implementaciones de prueba frecuentes, por lo que siempre hay algo nuevo / fijo para probar.
   • Hacer la comunicación más rápida y más frecuente. Por ejemplo, favorezca la mensajería instantánea sobre los hilos de correo electrónico.
   • Asegurar que los probadores tengan las mejores herramientas disponibles (máquinas rápidas, monitores múltiples, seguimiento de errores simplificado, etc.)

   Esta etapa no se trata de optimizar el proceso de prueba en sí (todavía), se trata más bien de reducir los gastos generales. No pierdas el tiempo de los probadores. Eliminar el tiempo que realmente se desperdicia también debería ser una venta fácil para la administración.

3. Subordinar otras actividades a la restricción.

   En este punto, los evaluadores son tan productivos como pueden ser por sí mismos, por lo que debemos comenzar a tomar prestada la productividad de otras áreas:

   • Indique a los desarrolladores y al personal de operaciones que den prioridad a los evaluadores, sin importar en qué más estén trabajando.
   • Si no tiene equipos multifuncionales, reserve una sala de reuniones todos los días a una hora preestablecida para que los evaluadores nunca tengan que perder el tiempo tratando de reservar una.
   • Desvíe un porcentaje mayor del tiempo de desarrollador (y posiblemente operaciones) del trabajo de características; por ejemplo, enfóquese en las correcciones de errores, refactorización / deuda tecnológica, revisión de código y pruebas unitarias.
   • Realice pruebas de forma continua e incremental: no se desarrolle durante 3 semanas y luego páselo a los evaluadores. Haga que los desarrolladores trabajen para hacer que su código sea comprobable inmediatamente, por ejemplo, con andamios o prototipos de IU.

4. Elevar la restricción.

   Si los probadores trabajan a plena capacidad, tanto en términos de productividad como de gastos generales mínimos, y aún no es lo suficientemente rápido, entonces debe comenzar a invertir más en pruebas.

   • Si confía en implementaciones de pruebas manuales, automatícelas mediante el uso de secuencias de comandos de integración continua y administración de configuración.
   • Si los planes de prueba tardan mucho en crearse, trabaje para obtener mejores criterios de aceptación (es decir, INVEST ). La mayoría de las organizaciones son inicialmente muy malas en esto.
   • Si las pruebas de aceptación demoran demasiado, comience a automatizarlas. Use una herramienta como Cucumber o FitNesse, o escriba pruebas de tipo xUnit si es necesario. También hay Selenium, Watij y otras herramientas de automatización del navegador si la prueba de la interfaz de usuario lleva mucho tiempo.
   • Si las pruebas de regresión están tardando demasiado, automatícelas también. Si no se puede automatizar, concéntrese en mejorar la calidad desde el principio, es decir, con un énfasis aún mayor en la revisión del código, las pruebas unitarias, las herramientas de análisis estático, etc. Los desarrolladores deben estar bastante seguros de que hay muy pocos errores reales antes de pasarlo. QA (los defectos del producto son una historia diferente).
   • Si las pruebas exploratorias son el cuello de botella, podría posponer algo de eso hasta después del lanzamiento, o contratar a una empresa de pruebas para que haga cosas altamente paralelizables como probar el mismo flujo de trabajo en múltiples navegadores.
   • Si los evaluadores no pueden reproducir muchos errores, considere crear un entorno de prueba de capacidad para poder comenzar a reproducir errores intermitentes. O intente simplemente ejecutar sus pruebas de aceptación automatizadas en paralelo y de forma continua, durante todo el día, manteniendo registros detallados.
   • Si lleva demasiado tiempo solucionar los errores, comience a particionar sus proyectos y / o considere seriamente volver a diseñar sus soluciones. O, como alternativa, no arregles algunos de ellos; no todos los errores son críticos, debe poder priorizarlos junto con el trabajo de características.
   • Si todo lo demás falla, contrate más evaluadores.

5. Regrese al Paso 1.

Me gustaría decir que todo esto tiene sentido común, pero desafortunadamente no lo es, al menos no en la mayoría de las organizaciones. Si está obteniendo mucha resistencia por parte de la gerencia, una técnica invaluable es Value Stream Mapping (una técnica de manufactura esbelta), que puede usar para mostrar cuánto tiempo y, por lo tanto, el dinero se está desperdiciando todos los días por un candidato de liberación que no puede para pasar a la siguiente etapa. El costo de oportunidad es difícil de entender, pero esta es una de las mejores formas que he encontrado para visualizarlo y demostrarlo.

Y si nada de eso funciona ... entonces quizás estés en una compañía disfuncional, ¡sal antes de que sea demasiado tarde!

Pero no resolverá este problema simplemente dejando caer unos pocos papeles en el escritorio del gerente y pidiéndoles que arrojen dinero al problema, porque supondrán (correctamente) que arrojar dinero en realidad podría no resolverlo, e incluso podría es peor Debe proporcionar soluciones , y de eso se trata esta respuesta. Si presenta el problema como "aquí hay una lista de formas en que podemos comenzar a resolver este problema, en orden descendente de costo / beneficio" en lugar de "necesitamos más evaluadores", entonces tendrá mucho más éxito.

Las páginas 29 y 30 pueden tener los datos que está buscando, aunque puede ser necesario un seguimiento.

Examinaría la investigación mencionada en esta oración en la página 30:

Docenas de compañías han descubierto que el simple hecho de centrarse en corregir los defectos más temprano que tarde en un proyecto puede reducir los costos y cronogramas de desarrollo por factores de dos o más (McConnell 2004).

Por cierto, fue tu pregunta la que me hizo levantar el libro nuevamente para actualizarlo :-)

Lo que está describiendo es un cuello de botella en un proceso. La teoría Lean afirma que siempre habrá un cuello de botella en un proceso, pero su gravedad puede variar ampliamente. Si QA contrata un extra, entonces el desarrollo podría convertirse en el cuello de botella.

Para entender el costo, imagine la siguiente situación. Elegiste a uno de los desarrolladores. Su trabajo nunca estaría asegurado por la calidad, sino que siempre se pondría en cola indefinidamente. Imagine que esto significaría que el control de calidad podría garantizar la calidad del trabajo del resto de los desarrolladores de manera oportuna y no habría ningún costo de demora.

En ese escenario, el costo de la demora es el costo del salario del desarrollador, porque su trabajo se desperdiciaría.

La razón por la que argumento en términos de costo y no del valor creado por el proceso, es simplemente porque es más difícil documentar el valor de un proceso, a pesar de que es mucho mejor.

Sigo hojeando mi copia de Code Complete, buscando un fragmento de "Datos duros" que muestre que el costo de corregir defectos aumenta exponencialmente cuanto más tiempo exista. ¿Alguien puede señalarme algunos estudios que respalden este concepto?

El costo exponencial de encontrar un error parece estar basado en un estudio NIST . El estudio fue una encuesta que supone distintas etapas de cascada:

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( mesa aquí desde aquí )

Uno de los objetivos de las metodologías de desarrollo de software ágil es eliminar estas etapas distintas y reducir estos costos. Las cifras no se aplican cuando se utilizan otras metodologías en cascada.

Su problema no es con el control de calidad, de hecho, si su control de calidad está haciendo pruebas, los retrasos son la menor de sus preocupaciones. Permítanme expandirme (nuevamente, ya que es un error común en la industria de la programación) ... QA asegura la calidad del producto al supervisar todo el SDLC, desde los requisitos (tal vez antes), hasta el desarrollo, la verificación, el lanzamiento y el soporte. Las pruebas aseguran que no existan defectos obvios en el código. Hay una diferencia muy grande e importante. Si tuviera un control de calidad verdadero, estarían en todo el departamento de Pruebas / V&V preguntando por qué le estaban costando el tiempo comercial (y, por lo tanto, el dinero) retrasando los lanzamientos, o toda la gestión del proyecto, asegurando que administraban la programación del proyecto correctamente, o toda la gestión Seguro que había suficientes probadores para el código que se está produciendo, etc.

Entonces, suponiendo por QA, realmente quieres decir Test, volviendo a la pregunta original. Code Complete lo hizo bien: el costo de un defecto es el tiempo que toma desde la inserción hasta la corrección. La detección temprana solo es útil si también la corrige temprano, pero la interpretación de la mayoría de las personas es incorrecta.

(Nota: estoy jugando a Devils advocate aquí, no tome nada de esto literalmente ya que no sé nada de su situación) La demora causada por su departamento de pruebas es un costo, sin embargo, tengo que preguntarle si está esperando que encuentren tus defectos, ¿qué estás haciendo? ¿No deberías encontrar tus propios defectos? Quizás si tuvieran menos trabajo (a través de una entrada de mayor calidad con menos defectos de su parte), la demora no sería tan significativa y el costo sería menor: como gerente, le preguntaría cómo planea reducir los defectos en el código que entrega prueba, ya que (según su argumento) esos defectos cuestan más si se encuentran por prueba que usted mismo.

Además, como gerente, podría decir que no es un trabajo de Pruebas encontrar sus defectos, Su trabajo es encontrar que no hay defectos; si espera que encuentren defectos, tal vez no haya hecho su trabajo lo suficientemente bien.

Tenga cuidado de cómo aborda esto. Si no tiene una solución al problema, es probable que salga en segundo lugar.