Come migliori i processi di ingegneria?

Question

Accepted Answer

Migliora il processo **individuando il vero collo di bottiglia con i dati, cambiando una cosa, e misurando l'effetto** — non importando una metodologia in blocco. Il processo esiste per servire il team; quando smette di servire, cambialo.

## Un ciclo di miglioramento

```text
1. MEASURE       → where does work actually slow down? (cycle time, review wait,
                    deploy frequency, incident rate)
2. FIND THE CONSTRAINT → optimizing anything but the bottleneck is wasted effort
3. CHANGE ONE THING → small, reversible experiments
4. MEASURE AGAIN → did it help? keep, adjust, or revert
5. INVOLVE THE TEAM → they know the pain; they'll own the fix
```

## Esempio

Se le feature richiedono tre settimane ma solo due giorni sono di coding, il vincolo è il *tempo di attesa* — code review queue, disponibilità dell'ambiente, approvazioni — non la velocità dello sviluppatore. Aggiungere pressione sul coding non servirebbe a nulla.

## Insidie

- **Cargo-culting** del processo di un'altra azienda ("facciamolo come Spotify").
- **Processo fine a se stesso** — cerimonie che hanno superato il loro scopo.
- **Cambiare cinque cose contemporaneamente**, così non riesci a capire cosa ha funzionato.
- **Imporre il processo top-down** senza il consenso del team.

## Perché è importante

I piccoli miglioramenti di processo si compongono.

Ridurre il tempo di attesa della review o il dolore dei test flaky libera ore ogni settimana in tutto il team.

Egualmente importante, coinvolgere il team trasforma il processo da qualcosa fatto *su* di loro in qualcosa che possiedono — che è la differenza tra un cambiamento che attecchisce e uno che silenziosamente viene abbandonato.