Il fattore autobus, gli impiegati del catasto e i costi (esorbitanti) di una documentazione inesistente

Un indice di rischio del progetto molto singolare: il fattore autobus!
Foto di Allen Watkin distribuita con licenza Creative Commons.

Il fattore autobus di un gruppo di lavoro (team’s bus factor) è l’espressione utilizzata dai due autori di Team Geek1 – per esprimere il grado di rischiosità di un progetto prodotto dall’improvvisa assenza di uno o più componenti del gruppo di lavoro.

La definizione di questo indice di rischio è:

Il numero di persone (appartenenti allo stesso gruppo di lavoro) che è necessario siano investite da un autobus prima che il progetto possa dirsi spacciato.

Minore è questo numero, maggiore è la concentrazione di conoscenza su aspetti critici del progetto e maggiore ne è la sua rischiosità.

Uno dei modi per ridurre il rischio rappresentato dal fattore autobus è quello di produrre e mantenere in vita una sana documentazione (una parte della quale sarà utile anche nei successivi progetti, ad es. Lessons Report). Tuttavia mentre programmare è affascinante, sembra quasi un’arte, equivale a creare, scrivere documentazione è come ritrovarsi d’un tratto a fare l’impiegato del catasto: non rientra tra quelle attività che generano simpatia, tantomeno entusiasmo.

Non cercherò di convincervi con le parole, proverò con un’immagine.

Costo relativo della correzione di un difetto nelle varie fasi di sviluppo software.
Costo relativo della correzione di un difetto nelle varie fasi di sviluppo software.

Questo grafico a barre2 illustra il costo relativo necessario a correggere un difetto in base alla fase del ciclo di vita di un software in cui questo baco viene scoperto. Il costo aumenta in modo significativo tanto più ci ci avvicina al rilascio in produzione.
Una sana documentazione abbassa il rischio rappresentato dal fattore autobus perché aiuta a distribuire la conoscenza tra tutti i membri del gruppo di lavoro e permette di mantenere i costi sotto controllo. Forse produrre buona documentazione non sarà affascinante ma vi permetterà di avere ancora un progetto, sensato, su cui lavorare!


1. Fitzpatrick, Brian W., e Ben Collins-Sussman. Team Geek: A Software Developer’s Guide to Working Well with Others. O’Reilly Media, 2012.
2. Wiegers, Karl E. Software Requirements by Karl Wiegers 2nd ed. Microsoft Press, 2003