Idea principale

Lo schema è diffuso: uno sviluppatore consegna una funzionalità, passa all'attività successiva, e i difetti che emergono vengono presi da qualcun altro — uno sviluppatore libero, una persona di turno, un team di supporto tecnico, a volte un team dedicato ai bug. Il criterio di assegnazione è la disponibilità.

Ottimizzare la disponibilità sembra un guadagno di pianificazione. L'effetto reale sta altrove. Chi ha introdotto il difetto non vede mai quanto è costata la sua consegna. Chi corregge deve ricostruire un contesto che non ha creato, e quindi paga due volte: la correzione e la comprensione. E il tempo perso, diventato collettivo, smette di essere imputabile a una consegna precisa.

Il sistema emette allora un segnale che nessuno formula: si può consegnare in fretta, e se qualcosa si rompe, qualcun altro assorbirà. «Sono passato ad altro» diventa una risposta accettabile.

Perché è importante

Sposta la diagnosi di un team che produce troppi difetti: prima di guardare le sue competenze o i suoi strumenti, si guarda la regola con cui assegna le correzioni. Una regola che ottimizza il throughput a breve termine può essere proprio ciò che alimenta il flusso da correggere.

Offre anche una lettura dei team «dedicati ai bug»: non sono solo un modo di organizzarsi, sono un dispositivo che recide il legame fra una consegna e il suo costo.

Sfumature e limiti

L'assegnazione per disponibilità non è sempre evitabile — uno sviluppatore che se n'è andato, un difetto nato da più contributi, una zona di legacy senza un autore identificabile, una persona oggettivamente più adatta. Questi casi esistono e nessuno li contesta.

Ciò che si contesta è l'uso che se ne fa: servono spesso a giustificare la regola generale opposta, in cui la disponibilità decide per default invece che per eccezione.

Domande aperte

• Come attribuire un difetto nato da più contributi successivi senza trasformare l'attribuzione in un'indagine più costosa della correzione?