Trasladado a scrum, ahora los desarrolladores solo están haciendo control de calidad

Scrum no tiene nada que ver con el desarrollo, ni qa, ni nada por el estilo. En realidad, es solo una filosofía para ayudar a crear mejores estimaciones al mejorar la visibilidad del progreso y también para fomentar una comunicación más sólida entre los miembros del equipo.

Ágil es exactamente lo mismo.

Su mejor apuesta sería explicar el costo de oportunidad: que los desarrolladores (generalmente) cuestan más que el control de calidad dedicado. Aun así, puede ser que sus prácticas de desarrollo sean de mala calidad y esté creando demasiado trabajo qa, y este "desarrollador pluriempleo como qa" está haciendo dos cosas

1. lograr que resuelva el trabajo pendiente de control de calidad
2. asegurándose de que no está agregando a la acumulación de control de calidad

Dudo que sea una lección de mr miyagi o algo así. Sin embargo, sería mejor considerar cómo automatizar el qa, en lugar de quejarse de que no le gusta hacer qa.

Dado que todo lo que está haciendo todo el día es, de hecho, qa, debe tener una muy buena idea de cuáles son los pasos y cómo es el proceso de qa. Averigüe cómo automatizar (¿todo? ¿parte de?) eso, muéstreselo a la gerencia, construya esa herramienta. Esa es una buena manera de obtener un ascenso al mostrar iniciativa, crear algo y dejar de hacer control de calidad.

Tenga en cuenta que aún tendrá que realizar el control de calidad de su herramienta de control de calidad, por lo que no podrá detener el control de calidad por completo con esta idea.

Supongo que algo ha sucedido que provocó una llamada para un sistema de control de calidad mucho más riguroso. A la gerencia realmente no le importa quién hace esto, pero quieren que se haga y se haga bien, y quieren enviar las hojas de cálculo de los resultados a las personas que se preocupan por estas cosas.

Decir que QA es "parte de scrum" realmente no significa mucho y no es realmente relevante aquí. El núcleo del problema es que hay más trabajo de control de calidad por hacer.

Dado que su equipo tiene casi todas las tareas del control de calidad, lo único que puede hacer es llevarla a cabo y completar esta tarea lo mejor que pueda. Dejar las herramientas y decir "Somos médicos, no técnicos de warp core" realmente no ayudará al proyecto en este momento.

En el futuro, debe emplear/recursos para un equipo de control de calidad dedicado o crear un flujo de control de calidad más formalizado en su metodología de desarrollo.

Hable de esto con sus gerentes cuando se complete la fase de prueba actual y haya pasado el pánico. Si esto no cambia con el tiempo, entonces la gerencia deberá lidiar con el consiguiente desgaste causado por las personas que desean hacer los trabajos para los que fueron empleados principalmente.

Un aspecto importante de Scrum es que el equipo trabaja en conjunto para entregar una unidad de trabajo durante un período corto. La entrega de una unidad de obra incluye lo necesario para considerarla completa. Esto puede ser diseño, codificación, implementación, garantía de calidad, etc. Todos son responsables juntos de todos los aspectos del trabajo.

Cualquier parte del trabajo debe ser realizada por personas capaces de realizar el trabajo. Eso significa que si hay que hacer un trabajo de garantía de calidad, los desarrolladores deberían ayudar a menos que también se necesiten para hacer otra cosa. Este enfoque tiene una serie de ventajas. Pone énfasis en entregar algo útil. Cualquier tarea en particular, como la codificación, no es importante. Hacer lo que sea necesario para completar el trabajo es lo importante. En segundo lugar, rompe los silos entre los diferentes conjuntos de habilidades, incluidos los desarrolladores de software, el control de calidad, las operaciones, etc. Nadie puede hacer su parte sin tener en cuenta cómo afecta a los demás.

Esta es una forma más satisfactoria de trabajar para muchas personas porque, en lugar de trabajar solo en tareas específicas, se le da libertad dentro del equipo para organizarse a sí mismo y profundizar en una construcción.

Si el trabajo de aseguramiento de la calidad requiere demasiado tiempo, no es que se haya mudado a Scurm, entonces ha identificado un problema que siempre ha tenido. Su equipo debe trabajar para encontrar formas de realizar el aseguramiento de la calidad de manera más efectiva. Esto puede ser la contratación de cambiar los conjuntos de habilidades en el equipo para tener habilidades de garantía de calidad más específicas o puede ser que los desarrolladores de software trabajen en pruebas automatizadas o refactorización de código para mejorar la capacidad de prueba del trabajo.

Si los desarrolladores piensan que no deberían trabajar en tareas de control de calidad, trabajar en un entorno ágil no es para ellos. Deben dejarse ir para que puedan trabajar en algún lugar donde puedan codificar y dejar que la calidad sea el problema de otra persona.

Como mencioné en un comentario a la pregunta original, creo que esta es la forma en que la administración afirma hacer Agile, mientras que en realidad perpetúa Waterfall. En particular,

Estamos controlando nuevos casos de uso en los que no se había pensado

se parece mucho a pasar meses diseñando el producto completo antes de comenzar a codificar.