¿Cuáles son las prácticas prioritarias de calidad?

Trataré de plantear varios puntos en algunos departamentos separados en el orden en que los abordaría. Dependiendo de los recursos y el apoyo que tenga, la situación de esfuerzo versus beneficio podría dictar un orden diferente.

Especificaciones

Necesita especificaciones claras, completas, actuales y correctas. No importa cuántas personas estén involucradas en lograr que los requisitos de lenguaje comercial se conviertan en especificaciones de lenguaje de desarrollador. Importante es:

1. se hace
2. se hace correctamente
3. Las responsabilidades son claras.
4. Tiene un solo canal (si tiene N desarrolladores todos hablando con M clientes, deténgase)

Cosas que pueden ayudar aquí:

• Propietario de un producto (principalmente debido al punto 4 anterior)
• Una definición de listo (para ayudar con los puntos 1 y 2)

Pruebas

Necesita pruebas confiables, repetibles y rigurosas. He trabajado como probador en un entorno que se centró exclusivamente en las pruebas manuales. Simplemente no es sostenible. A medida que su conjunto de características crece, las necesidades de prueba crecen exponencialmente. Si no automatizas al menos una parte, estás jodido.

Cosas que ayudan aquí:

1. Tener un probador dedicado. Sé que es elegante hablar sobre cómo los desarrolladores deberían poder probar su propio código. Y sin duda es útil. Pero he sido un desarrollador responsable de mis propias pruebas, he sido un desarrollador con un probador asignado y he sido un probador asignado a un desarrollador. Hay algo extremadamente liberador en poder probar el código de otra persona. Del mismo modo, tener un buen probador de tu lado es mucho más divertido que hacer malabarismos con los sombreros. Hacemos la separación de preocupaciones en nuestro código por una razón. Entonces, si tiene la opción de presionar a los desarrolladores para que prueben más y obtener un evaluador dedicado, ni siquiera es un concurso ...
2. Pruebas automatizadas. Como dije anteriormente, si está trabajando en algo más que un proyecto único, solo se está castigando a sí mismo si no hace esto. No importa si adopta TDD o lo hace al estilo cascada después del desarrollo. Sus probadores deberían tener que encontrar cada error exactamente una vez. Si solo hay una situación en la que escribe una prueba, es esta.
3. Construcciones automatizadas. Como requisito previo para las pruebas continuas y como una forma de ahorrar tiempo. He visto un proceso de compilación manual de 30 pasos en el mundo .NET. no hagas eso
4. Pruebas continuas. Cuanto más ajustado sea el circuito de retroalimentación, más rápido podrá corregir los errores
5. Definición de hecho. Esto no hace mucho por sí solo por la calidad. Pero es útil crear conciencia sobre el nivel de calidad en el que está operando y crear una mejor comprensión mutua de lo que significa cuando cada persona dice "esto está hecho".

Organización

• Comentarios iniciales de los usuarios. No importa cuán diligentes sean el probador y el propietario del producto, algunas cosas pasarán desapercibidas.
• Iteraciones más cortas/menor alcance por iteración. Cuanto menor sea su incremento, menos interacciones tendrá que probar a la vez. Esto puede ayudar a que las pruebas se sientan menos como una tarea.

Pida al equipo de desarrollo que sugiera pasos para mejorar la calidad

Tu idea de introducir Retrospectivas es buena. Como Scrum Master, deberías estar haciendo eso (y Sprint Reviews) de todos modos. En la Retrospectiva, anime al equipo a hablar sobre problemas de calidad. Estoy seguro de que están tan frustrados por la mala calidad como tú. También tendrán ideas sobre lo que se debe hacer para solucionarlo. Extrae esas sugerencias y ayuda a implementarlas. Este enfoque tiene los siguientes beneficios:

• Se unió recientemente mientras que el equipo de desarrollo ha estado allí por más tiempo. Sabrán más sobre la causa raíz de los problemas de calidad y qué se debe hacer para solucionarlos. Como la persona nueva, aportas una nueva perspectiva. Pero use eso para guiar la discusión para evitar señalar con el dedo y hacia líneas productivas.

• Si trabaja con el equipo de desarrollo y ayuda a implementar sus ideas, habrá una mejor aceptación de las ideas y menos resistencia al cambio.

• Como Scrum Master, desea ser un líder servidor en lugar de imponer sus ideas al equipo.