Des développeurs dans un open-space

By | 1 novembre 2007

L’année dernière, l’éditeur de logiciels dans lequel je travaille a rénové entièrement les locaux. La rénovation s’est soldée par quelques abattages de cloisons pour gagner de la place et la plupart des bureaux sont maintenant organisés en open-space.

N’ayant pas d’expérience dans des domaines tels que la vente ou le marketing, je ne sais pas si cela leur permet de mieux travailler, ou bien si au contraire cela freine leur créativité ou les empêche de conclure certaines ventes. En revanche, mettre une vingtaine de développeurs dans un open-space, c’est absurde (mais moins que de mettre des commerciaux et des développeurs dans un même open-space).

Voici une équation simple pour mettre en lumière l’absurdité:

Développeurs + open-space = productivité faible + bugs

L’open-space est un mauvais endroit pour faire travailler un développeur car il concentre deux faiblesses : c’est un endroit bruyant, et c’est endroit sans intimité.

A moins de travailler pour la NSA, les développeurs sont en contact avec toutes sortes de gens: d’autres développeurs qui viennent leur demander conseil, des clients ou des collègues du département support qui les appellent au téléphone, etc. Mettons que chaque développeur est ainsi dérangé 2 à 3 fois par jour pendant 5 à 10 minutes ; Dans un open-space avec 20 développeurs, cela veut dire qu’il y aura quasiment à tout moment de la journée, une conversation en cours, et donc du bruit toute la journée. Pas facile de se concentrer dans ces conditions…

De plus, dans un open-space où tout le monde est « visible », il est plus facile d’aller déranger son collègue pour savoir pourquoi il a renommé la méthode titi de la classe Toto plutôt que d’aller regarder dans l’historique de Subversion.

Or une étude (lire Peopleware, Chapitre 9) a montré qu’un développeur mettait en moyenne 10 minutes à « rentrer » dans le code qu’il était en train d’écrire. Au bout de 10 minutes de programmation, un développeur sait exactement quelles fonctions il est en train d’écrire, quelles autres classes il faudra qu’il modifie suite aux changements qu’il est en train d’effectuer, etc. On peut le comparer à un jongleur qui jonglerait avec une dizaine de massues.

Au début il commence avec une massue, et toutes les minutes il peut en rajouter une. Au bout de 10 minutes, il jongle avec toutes ses massues. Maintenant, un équilibriste arrive et demande à notre jongleur de bien vouloir l’aider à tendre son fil. Le jongleur cesse de jongler, pose ses boules et aide bien amicalement son collègue. A la suite de quoi, le jongleur recommence à jongler, avec une massue d’abord, puis au bout de 10 minutes avec toutes ses massues. Il en va de même du développeur. Interrompez-le 2 minutes et il lui faudra 10 minutes pour reprendre son « rythme » de croisière.

On peut même prolonger l’analogie avec le jongleur: dérangez le jongleur, en lui posant une question, en lui racontant une bonne blague, ou juste en aillant une conversation animée avec l’équilibriste et il risque de se déconcentrer et de faire tomber une boule. Dérangez le développeur et il risque d’écrire un bug!

Pour augmenter la productivité et la qualité des développements d’une équipe, il faut éviter de distraire incessamment les développeurs. Et un open-space c’est un endroit plein de distractions…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *