El arquitecto y los equipos de desarrollo

Hay dos formas de reducir lo que llega a revisión. La primera es revisar menos, lo que deja pasar riesgos. La segunda es construir caminos pavimentados: componentes comunes ya revisados (una biblioteca de autorización, una plantilla de pipeline, un cliente del gestor de secretos) que los equipos usan por ser lo más fácil. Lo que sigue el camino no necesita revisión; la revisión se reserva para quien se sale de él.

La cola de revisiones/cola-q1.txt tiene una columna con el tema de cada revisión, y plataforma/caminos-pavimentados.txt dice qué componentes existen y qué equipos los adoptaron. Cruzar las dos dice dónde invertir.

La política de Guacamaya dice que toda funcionalidad con superficie externa nueva necesita revisión de diseño antes del lanzamiento. Una corrección sin superficie nueva no la necesita, y exigirla sería un trámite sin sentido. La lista de lanzamientos/q1.txt dice, por lanzamiento, si tenía superficie externa nueva y qué revisión tuvo.

Una revisión que tarda un mes enseña al equipo a no pedirla. La cola registra la fecha de solicitud y la fecha en que se inició cada revisión. El indicador que importa al equipo es la espera: los días entre las dos fechas. Calcula la espera más larga del trimestre.

Un arquitecto no puede estar en cada sprint. Los campeones de seguridad son personas de cada equipo, con unas horas por semana, que llevan las preguntas de seguridad a su equipo y las dudas del equipo al arquitecto. Un equipo sin campeón se entera de las reglas por la revisión, tarde y a veces con un rechazo.

equipos/campeones.txt dice quién es el campeón de cada equipo y cuántas horas por semana dedica.

Cuando un diseño no se puede aceptar, un rechazo seco enseña al equipo a evitar al arquitecto. Una respuesta útil tiene cuatro partes: qué riesgo concreto ve, la alternativa más barata que lo cierra, quién la decide y para cuándo. Si el equipo decide aceptar el riesgo, queda registrado con nombre y fecha de vencimiento.