Le Mythe du mois-homme

Ajouter des ressources humaines à un projet en retard sur les prévisions ne fait qu'accentuer ce retard : c'est la loi de Brooks. En effet, le personnel ajouté devra être formé au nouveau système, ce qui prend un temps non négligeable que ne peut compenser la productivité ajoutée par le personnel en question. Les nouveaux ont souvent besoin d'entraînement et de formation. De plus, leur présence alourdit les canaux de communications. Si n personnes doivent échanger entre elles (sans hiérarchie), quand n augmente, leur extrant M décroît et peut même devenir négatif (c'est-à-dire que le travail total à réaliser à la fin d'une journée est plus grand qu'au début de cette journée).

Ce chapitre a été ajouté dans l'édition de 1995 et s'inspire du livre No Silver Bullet — Essence and Accidents of Software Engineering du même auteur.

Brooks insiste sur le fait qu'il n'existe pas de « balle en argent » :

« Il n'y a pas un seul développement dans aucune technologie ou technique managériale qui promette par elle-même, avec un ordre de magnitude [ … ] d'apporter en une décennie des améliorations en productivité, en fiabilité, en simplicité. »

Pour illustrer cela, Brooks s'appuie sur deux types de difficultés rencontrées dans la réalisation de logiciels :

• difficultés accidentelles (langages de programmation et systèmes laborieux et malaisés à utiliser) ;
• difficultés essentielles (inhérentes à la production de logiciels).

Les difficultés accidentelles ont déjà été en grande partie éliminées, par exemple par l'adoption de langages de haut niveau ; il n'y aura donc pas dans l'avenir de nouveaux progrès permettant de gains importants de productivité. En revanche, les technologies ne peuvent supprimer les difficultés essentielles.

Tout informaticien ayant réalisé la version originale d'un logiciel a tendance à incorporer dans la deuxième version toutes les fonctions qu'il n'avait pu intégrer, faute de temps, dans la première. Or cette initiative, apparemment heureuse, comporte de réels dangers :

• bouleverser l'aspect du logiciel, auquel les utilisateurs de la version originale avaient fini par s’habituer ;
• automatiser des séquences de tâches que l'utilisateur effectuait volontiers lui-même dans la première version, ce qui alourdit l'interface ;
• promouvoir des fonctionnalités obsolescentes ;
• faire exploser la taille du logiciel ;
• et surtout perdre l'unité conceptuelle du logiciel (les spécifications d'origine) qui régissait la première version, en cherchant à imiter la concurrence.

Un informaticien développant une deuxième version devrait donc être conscient du besoin de stabilité de l'utilisateur moyen et du risque de dépassement des spécifications exigées.

Comment un gros projet peut-il être en retard d'un an sur l'horaire prévu ? À cause du retard pris chaque jour sur ce projet.

Des retards à différentes étapes du projet ont un effet cumulatif et retardent globalement le projet. Pour prévenir ce retard, il faut que les gestionnaires agissent pour faire respecter l'horaire de livraison de chacune des étapes du projet.

Tout système convivial possède nécessairement une unité conceptuelle, laquelle est possible si l'architecture logicielle est séparée de son implémentation. Une « super idée » peut être rejetée si elle ne s'insère pas naturellement dans le programme. Pour assurer la convivialité, un architecte logiciel peut décider que le programme offrira moins de fonctions que ce qu'il peut offrir. La raison en est simple : si une fonction est trop longue à comprendre, elle ne sera pas utilisée.

L'architecte rédige au complet le mode d'emploi du programme, c'est-à-dire ce que l'utilisateur final verra. Le mode d'emploi devrait être modifié au fur et à mesure que l'architecte reçoit des commentaires de la part des informaticiens et des utilisateurs.

Lorsqu'elle conçoit un nouveau type de système, une équipe va forcément concevoir un système bon à jeter, de manière intentionnelle ou non. Un tel système a en fait le rôle d'un prototype permettant de faire émerger des techniques qui causeront par la suite une complète refonte du système. C'est ce second système, plus « intelligent », qui devrait être celui qui sera livré aux clients, puisque livrer la version prototype ne causerait rien d'autre que la mise en difficulté du client, ruinant par là-même la réputation du programme, voire peut-être celle de l'entreprise.

Tout gestionnaire de projet devrait rédiger des documents de base servant à établir le plan de travail : quels sont les objectifs, comment les atteindre, qui est responsable de quoi, quand doivent-ils être atteints et combien chacun d'eux coûtera ? Ces documents peuvent révéler des incohérences difficilement visibles autrement.

Lorsqu'un architecte logiciel planifie un projet, il doit se souvenir qu'un compilateur est trois fois plus difficile à créer qu'une application logicielle. Et qu'un système d'exploitation est trois fois plus difficile à créer qu'un compilateur. L'usage d'un langage de haut niveau adapté peut substantiellement améliorer la productivité d'un informaticien. Il doit également tenir compte du temps pris par les tâches qui ne sont pas de nature technique (réunions, rapports, congés maladie, etc.)

Dans le but de prévenir les désastres, toutes les équipes affectées à un projet doivent maintenir le contact entre elles à l'aide du plus grand nombre de moyens possibles (courriel, téléphone, réunions, mémos, etc.). Plutôt que de faire des hypothèses sur une fonction, l'informaticien se réfère à l'architecte logiciel pour clarifier la nature de la fonction. Sinon, il risque d'implémenter une fonction qui sera jetée.

Toute équipe de chirurgie est menée par un chirurgien en chef, qui s'occupe en personne des tâches essentielles de l'opération tout en dirigeant son équipe, qui l'appuie et réalise des tâches moins essentielles. Il est raisonnable de voir une équipe logicielle de la même façon : le meilleur informaticien s'occupe des parties essentielles du composant à créer, alors que les autres s'occupent des autres tâches.

Brooks spécule que les meilleurs informaticiens ont une production de 5 à 10 fois supérieure aux pires.

Tout changement au code source doit être connu via un système de gestion de versions. En revanche, le logiciel est invisible. Pour cette raison, plusieurs fonctions ne deviennent visibles qu'après un certain temps de développement. À ce moment, les utilisateurs peuvent commencer à utiliser une partie du programme final. Leur expérience apporte des points de vue nouveaux, qui changent la perception de l'utilisateur ou la perception de ses besoins. À ce moment, le système doit aussi changer pour combler leurs besoins.

Ces modifications sont permises à l'intérieur d'une certaine fenêtre de temps, sinon le produit final change continuellement, en attente d'être livré aux clients. À une certaine date, seuls les bogues doivent être réparés : le code source est gelé. Tous les changements conceptuels en attente d'implémentation se retrouveront dans une version future.

Plutôt que chaque informaticien utilise un coffre à outils composé par ses soins, chaque équipe devrait avoir un membre qui se spécialise dans la création d'outils pour les autres membres de l'équipe. De plus, des outils utilisés pour l'ensemble du projet devraient être créés par une équipe spécialisée dans cette tâche, laquelle est supervisée par le gestionnaire de projets.

Selon Brooks, il existe deux techniques pour diminuer le coût de développement :

• engager les informaticiens qui implémentent le système une fois les spécifications complètement établies par les architectes (une étape qui peut prendre plusieurs mois, période durant laquelle les informaticiens employés trop tôt n'ont rien à faire) ;
• acheter des logiciels déjà fonctionnels (« sur étagère »), tout simplement.

• Loi de Parkinson
• Balle en argent
• Partage du temps de travail
• Scalability

• (en) Une revue par Tal Cohen
• (en) Site officiel de Frederick Brooks
• Une revue en Français