Le Principe de Gilb

Aujourd'hui, en préparant une mise à jour majeure du Référentiel, je me suis "reposé" de l'écriture du code d'indexation (en Ruby) en écrivant quelques fiches, dont celle de la pratique "Niko Niko", un import japonais d'autant plus intéressant qu'il m'a donné l'occasion de rappeler le Principe de Gilb

Si vous avez besoin de quantifier quelque chose, il existe toujours une manière de le faire qui soit préférable à ne pas le quantifier du tout.

Le Principe de Gilb est un bon antidote à l'un des travers les plus pernicieux du management des projets de développement logiciel: quand on se pique de gérer ces projets de façon empirique, en se basant sur des éléments objectifs et donc quantifiés, on finit en général par ne mesurer... que ce qui est facile à mesurer, mais rarement ce qui est pertinent.

Par exemple, la motivation, le bien-être d'une équipe ont généralement un effet déterminant sur les résultats qu'elle obtient. Mais comme aucun élément objectif ne permet de rendre ces paramètres immédiatement visibles, ces préoccupations passent souvent au second plan dès qu'on utilise par ailleurs des chiffres rendant compte de la productivité ou de la qualité.

Dans une approche Agile on cherche à mesurer en premier lieu ce qui est pertinent, ce qui est déterminant, même quand c'est difficile à mesurer. Et si on ne sait pas mesurer ce qui a de l'importance, ça n'a pas de sens de dépenser énergie et créativité à mesurer ce qui n'en a pas.

Attention toutefois: le Principe de Gilb ne dit pas que quantifier quelque chose qui ne l'était auparavant pas est systématiquement une bonne chose, et surtout pas que quantifier en vue d'encourager les équipes à atteindre des objectifs chiffrés est une bonne chose. (Lisez en particulier l'excellent Measuring and Managing Performance in Organizations si jamais la tentation vous vient du "management par les objectifs chiffrés".)