Il progetto è in ritardo, la direzione sblocca il budget, il team passa da quattro persone a otto. Sei mesi dopo la roadmap è andata avanti, ma di doppio non c’è niente: c’è pochissimo in più, e nessuno ha sbagliato niente. Non è sfortuna, è una legge.
Seconda di due puntate sulle otto Leggi di Lehman. Qui affronto le quattro che parlano di persone e non di codice: il ritmo di lavoro utile che resta costante nel tempo, la quantità limitata di novità che sviluppatori, assistenza e utenti riescono ad assorbire per volta, l’autoregolazione che riporta il team sulla sua media storica, e il software come sistema a feedback, dove la regola introdotta per ridurre i bug finisce per aumentarli.
Che il doppio delle persone non produca il doppio del lavoro lo diceva già Brooks. Lehman dice qualcosa di più scomodo: il tetto esiste, ogni persona aggiunta alza il ritmo meno della precedente, e a fissare quel tetto è l’architettura del sistema, non il budget. Le leggi si piegano solo dove ci sono tanti pezzi separati su cui lavorare in parallelo e nessun limite a chi ci lavora, come nel kernel di Linux e nei contributi a DelphiMVCFramework.
Chiude con quattro contromisure concrete: pianificare sul ritmo misurato e non su quello desiderato, togliere l’attrito prima di assumere, rilasciare a lotti piccoli e frequenti, governare misurando i numeri invece che per decreto. Più il ponte con il pensiero lean, da Taiichi Ohno in Toyota allo sviluppo software.
Se non hai ascoltato la prima parte, è la puntata Le Leggi di Lehman (parte 1): perché il software invecchia anche se non lo tocchi: conviene partire da lì.
Per CTO, Software Architect, Lead Developer, chiunque mantenga sistemi in produzione.
Approfondimenti: l’articolo Leggi di Lehman sull’evoluzione del software spiegate le racconta tutte e otto con scenari pratici, sintomi e contromisure. Sul pensiero lean applicato al codice c’è il libro Lean Thinking per sviluppatori software impegnati.
Fonti: Meir M. Lehman e Laszlo Belady, leggi sull’evoluzione del software (1974-1996), voce Lehman’s laws of software evolution su Wikipedia. Fred Brooks, “The Mythical Man-Month” (1975). Michael W. Godfrey e Qiang Tu, “Evolution in Open Source Software: A Case Study” (2000), sulla crescita super-lineare del kernel Linux concentrata nei driver.
Per formazione e consulenza: professionals@bittime.it.
A cura di Daniele Teti e bit Time Professionals.