La “teoria dei vincoli” (Theory of Constraints o TOC) dice che in ogni sistema, in ogni momento c’è almeno un vincolo di quel sistema che determina quanto velocemente il sistema può produrre.

La teoria dei vincoli è stata analizzata ampiamente nel libro di David J. Anderson (padre di MSF for CMMI Process Improvement, Kanban, e di molti di altri contributi ai temi del CMMI, dell’Agile e del Lean Management) “Agile Management For Software Engineering”:

TOC, applied to manufacturing, seeks to identify bottlenecks in the production line. The underlying assumption is that a production facility is only as fast as the slowest process in the chain. As a general rule, TOC assumes that a value chain is only as strong as the weakest link in the chain. The capacity of the weakest link is the current system constraint. 

- David Anderson, “Agile Management for Software Engineering”

La teoria dei vincoli si concentra sull’individuazione dell’anello debole della catena per migliorare la produzione di software.

Nel white paper di Derick Bailey intitolato “Theory Of Constraints: Productivity Metrics in Software Development” vengono analizzate varie metriche di produttività individuate nella teoria dei vincoli, sia di tipo “produttivo”, sia di tipo “finanziario”. Dopotutto la produzione di software è un’attività economica, e come tale va trattata.

Queste metriche “sembrano” diverse dalle classiche metriche dell’ingegneria del software, ma leggendo il white paper si vedrà che in verità sono molto collegate alle metriche software “tradizionali”, ad esempio alle metriche legate ai Function Point per le metodologie a cascata, o agli Story Point per XP e le altre metodologie agili.

Il white paper è molto breve (solo 11 pagine) ma scritto molto bene, e può sicuramente dare una prospettiva diversa a come viene affrontata la misurazione della produttività nello sviluppo software.

-Lorenzo

P.s. Chi volesse poi approfondire l’argomento, il libro di David Anderson rimane il punto di riferimento, anche se non l’ho trovato proprio di “facile assimilazione”…
Vi consiglio di dedicarci un po’ di tempo, in quanto lo stile è “da trattato di economia” più che da libro sull’ingegneria del software.