Dans le cadre des projets de développement logiciels, la difficulté de faire travailler un grand nombre de personne sur un même projet est appelée la loi de Brooks [BRO] : " Le fait d’ajouter des gens à un projet logiciel en retard, le retarde encore d’avantage ". Plus précisément, si le travail réalisé est plus ou moins proportionnel au nombre de personnes impliquées, la complexité augmente, quant à elle, comme le nombre d'échanges et donc comme le carré du nombre de personnes. Cela est du au fait que les liens entre les différents acteurs augmentent bien plus vite que le nombre des acteurs.

La loi de Brooks ne s'applique plus si les liens ne sont pas critiques

Une solution semble avoir été trouvée dans le cas du logiciel libre avec le développement de logiciels complexes sur une base très différente. Cette solution est décrite très en détail par Eric S. Raymond dans " La Cathédrale et le Bazar " [RAY1]. Suivons la chaîne de développement d'un produit pour comprendre ce qui permet de sortir de la loi de Brooks. Une fois la première version mise sur le marché, les corrections et améliorations se font en trois étapes :

1. la détection des problèmes
2. leur correction ou la réalisation d’améliorations
3. l’intégration de l’ensemble dans le produit.

Le lien qui s'établit entre les divers contributeurs est l'aspect clé. Le développement des liens est une très bonne chose pour développer la confiance entre les membres et l'émergence d'un esprit de communauté. Mais ces liens ne doivent absolument pas être critiques. Si le travail est parallélisé plutôt qu'en séquence, alors la défaillance d'une personne n'entraîne pas de conséquence sur le travail des autres. Chaque contributeur doit envoyer sa contribution directement au coordinateur qui choisi alors de l'intégrer ou non. Ainsi la complexité s'établit comme le nombre de personnes et non comme le nombre de liens comme le décrit la loi de Brooks.

Contrairement aux apparences, le coordinateur risque moins d'être submergé s'il doit intégrer chaque contribution que s'il doit intervenir sur les liens opérationnels entre les tâches réalisées par les différents contributeurs. D'une part, il y a généralement beaucoup moins de contributions que de membres de la communauté. D'autre part, même si 10% des liens entre les tâches étaient à suivre (les problèmes sont en général bien plus nombreux dans la réalité), ce nombre devient plus grand que le nombre de tâches dès qu'il y a plus de dix contributions !

Première Règle : Des contributions courtes, simples et autonomes

 Le premier critère est d’avoir des tâches parallélisables pour que les contributeurs puissent s’impliquer sur des tâches les plus courtes possibles sans imposer de liens entre elles. En fait, il s’agit bien plus souvent qu’on ne le pense d’une façon de découper le projet que du type de projet lui-même. Les tâches courtes avec un résultat clairement identifié sont bien plus adaptées aux projets coopératifs : un ensemble de documents courts (FAQ, check-lists, listes de liens) sera obtenu plus facilement qu’un rapport monolithique sur le même sujet. Si la façon de réaliser le projet est déjà prédéfini, elle risque non seulement de tuer les opportunités, mais également d’ajouter des contraintes pas forcément utiles pour le projet.

Plus les tâches sur lesquelles les utilisateurs pourront contribuer seront petites, courtes, simples et autonomes, plus il leur sera facile de s'impliquer. Pour prendre une comparaison avec les techniques informatiques, il faut passer d'une programmation monolithique à une programmation objet.

Deuxième règle : le seul lien opérationnel est avec le coordinateur

Pour éviter de subir la loi de Brooks, il faut que les tâches ne soient pas liées entre elles. Le coordinateur doit dans ce cas être le point central qui intègre chaque contribution autonome.

Cela ne veut pas dire qu'il ne doit pas y avoir de lien entre les contributeurs. Mais ceux-ci ne doivent pas être ceux d'une chaîne de tâches à accomplir comme Taylor l'a proposé. Les liens doivent plutôt se développer autour de l'émulation sur les idées et le développement des sentiments d'appartenance et de confiance qui renforcent la communauté.

En d'autres termes, il s'agit de remplacer une chaîne fragile comme le plus faible de ses maillons, par une corde solide comme la somme de ses brins les plus solides.

Cela peut sembler étonnant de proposer une telle centralisation dans une approche distribuée et coopérative. Mais la véritable décentralisation n'est pas dans le projet lui même mais dans la multiplication des projets et la possibilité de participer à plusieurs d'entre eux.

Troisième règle : Réduire le nombre de tâches critiques et les conserver

Pour rendre un projet le plus résistant possible, il faut non seulement que les contributeurs effectuent des petites tâches autonomes pour les soumettre directement au coordinateur, mais il faut également qu'aucune de ces tâches prises individuellement ne soit critique pour le projet.

Si le coordinateur dispose pour développer son projet d'un très grand nombre de personnes, les statistiques jouent en sa faveur et de bonnes idées auront toutes les chances d'en émerger. Mais toute tâche critique devient alors un maillon sensible du projet.

Il est presque toujours possible de réduire le nombre de tâches critiques d'un projet en le réorganisant, comme cela a été le cas dans l'exemple de l'Internet Fiesta 2000. L'art du coordinateur du projet est justement de savoir réduire au minimum ces tâches. Il devra ensuite en conserver la maîtrise.

Ainsi la grande différence entre le coordinateur et les contributeurs d'un projet est que le coordinateur exécute les quelques tâches critiques qui mettraient le projet en péril si elles étaient mal faites alors que les contributeurs effectuent un grand nombre de tâches non critiques qui démultiplient et enrichissent le projet.

Quatrième Règle : Le projet doit se suffire d'un minimum de contributions

Le système doit être le plus résistant possible à la non-coopération. Plutôt que d'espérer que 100 % des utilisateurs seront des contributeurs actifs, faites en sorte que le minimum indispensable soit le plus bas possible.

Par exemple les mécanismes de votes classiques peuvent être pervertis si le taux d'abstention est grand ou si les votants sont faiblement informés. Dans les techniques du "rough consensus" [IET], au contraire, tout le monde reçoit l'information, mais seuls ceux qui sont fortement opposés s'expriment. Le projet s'affine jusqu'à ce que plus personne ne s'oppose. On atteint alors un consensus approximatif suffisamment acceptable pour tous. Dans ce cas, l'abstention n'est pas un inconvénient mais une position qui signifie "je ne m'oppose pas au choix tel qu'il est proposé".

Pour garantir de bonnes chances de succès, considérez toujours qu'il suffit d'un minimum de personnes qui contribuent. Ce minimum critique doit être facilement atteint (éventuellement juste le coordinateur pourrait suffire). Tout contributeur supplémentaire sera alors un plus pour le projet.

 Livre sur la coopération #coordination28

Répondre à cet article

Par J-M Cornu | Avant | 24/12/2004 10:22 | Après | Coopération | un commentaire | Lu 8689 fois |