Bonjour à tous,

Dans mon travail quotidien, je m’aperçois continuellement que le mode de fonctionnement des différents projets est mal fait. Ce n’était qu’un ressenti difficile à expliciter jusqu’à présent. Beaucoup de petits projets en même temps, et différentes personnes à côtoyer sans jamais rester assez longtemps pour que de bonnes relations se créent. C’est très frustrant. Pas le temps de rentrer dans le projet en lui-même (tenants et aboutissants, compréhension métier, planning, …), pas le temps de connaître les membres de son équipe. En fait, on ne peut pas réellement parler d’équipe malheureusement.
Et puis, au détour d’une lecture, j’ai découvert que je n’étais pas seul à connaître ce type de problème. Je vais donc retranscrire ici un passage du livre The Clean Coder, de Robert C. Martin.

 

Souvent les projets sont relativements légers, et demandent un ou deux développeurs pour quelques semaines. Un tel projet aura souvent un chef de projet, qui sera également en charge d’autres projets. Il y aura aussi un fonctionnel, qui travaillera également sur d’autres projets. Et il y aura quelques développeurs qui travailleront également sur d’autres projets. Un testeur ou deux seront affectés, et ils travailleront eux aussi sur d’autres projets en parallèle.
Vous voyez le genre ? Le projet est si petit qu’aucune personne ne peut y être affectée à plein temps. Tout le monde travaille sur le projet à 50 ou même 25%.
Bon à savoir : une demie personne, ça n’existe pas !
Cela n’a aucun sens de dire à un développeur de consacrer la moitié de son temps sur le projet A et le reste du temps sur le projet B, particulièrement quand les deux projets ont un chef de projet différent, différents fonctionnels, développeurs et testeurs. Comment appeler cela ? Sûrement pas une équipe.

 

L’équipe solidifiée
Cela prend du temps de former une équipe. Les membres de l’équipe commencent par des nouer des relations. Ils apprennent à collaborer entre eux. Ils apprennent les bizarreries, les forces, les faiblesses de chacun. Et finalement l’équipe se solidifie.

Il y a quelque chose de vraiment magique avec les équipes solidifiées. Elles peuvent accomplir des miracles (toute proportion gardée). Les membres s’anticipent, se couvrent mutuellement, se soutiennent, et il en ressort le meilleur de chacun. L’équipe rend les choses possibles.

Une équipe solidifiée est composée en général d’une douzaine de personnes. Cela pourrait être une vingtaine ou encore trois personnes. Mais le nombre idéal est probablement autour de douze. L’équipe devrait être composée de développeurs, de testeurs, de fonctionnels. Et elle doit avoir un chef de projet.
Le ratio de développeurs/testeurs-fonctionnels peut varier, mais deux pour un est un bon ratio. Ainsi, une équipe de douze personnes devrait avoir sept développeurs, deux testeurs, deux fonctionnels et un chef de projet.

Les fonctionnels développent les exigences métiers et écrivent les tests d’acceptance automatisés pour ces besoins. Les testeurs rédigent eux aussi des tests d’acceptance automatisés, mais la différence entre les deux est une question de perspective. Les deux décrivent des besoins. Mais les fonctionnels se concentrent sur les valeurs et processus métiers ; les testeurs se concentrent sur l’exactitude. Les fonctionnels écrivent les chemins passants ; les testeurs se préoccupent de ce qui pourrait mal se passer, et écrivent les chemins d’erreurs et les chemins en bordure du système (interfaçage avec d’autres systèmes notamment).
Le chef de projet suit l’avancement de l’équipe et s’assure qu’elle comprend le calendrier, les délais et les priorités.
L’un des membres de l’équipe peut jouer un rôle, à temps partiel, de coach, ou de mentor, avec la responsabilité de défendre les processus et la discipline de l’équipe. Ce membre agirait en tant que conscience de l’équipe lorsque cette dernière serait tentée de dévier des bonnes pratiques à cause de la pression des délais.

 

Fermentation
Il faut du temps pour qu’une telle équipe se fasse aux différences de chacun de ses membres, s’adapte à chacun, et se solidifie réellement. Cela peut prendre six mois, voire un an. Mais une fois que l’équipe est vraiment formée, c’est magique. Une équipe planifiera les projets, résoudra les problèmes, fera face aux crises, et rendra les choses possibles.
Une fois que l’équipe est formée, il est ridicule de la séparer parce qu’un projet se termine. Il vaut mieux conserver l’équipe et continuer de l’alimenter en projets.

 

Du projet ou de l’équipe, qui est arrivé en premier ?
Souvent les entreprises forment des équipes autour des projets. C’est une mauvaise approche. Ces équipes ne peuvent tout simplement pas se solidifier. Les individus ne sont sur le projet que pour un temps limité (et la plupart du temps court), et seulement pour un pourcentage de leur temps. Et donc, ils n’apprennent pas à travailler ensemble.

Les sociétés d’informatique réellement professionnelles allouent des projets à des équipes déjà solidifiées, ils ne forment pas les équipes autour des projets. Une équipe peut accepter plusieurs projets simultanément. Et elle se les partagera en fonction des opinions, compétences et aptitudes de chacun de ses membres. L’équipe solidifiée rend les projets possibles.

 

Fin de citation du livre.

 

Alors, tout ceci est-il du domaine des bisounours ou bien cela existe-t-il vraiment dans certaines entreprises ? En tous les cas, ça fait rêver…