Le Mythique homme-mois (The Mythical Man-Month : Essays on Software Engineering) est un ouvrage de Frederick Brooks reconnu comme un classique dans le domaine du génie logiciel.

Le titre de l'ouvrage fait référence à une unité de coût de développement : le homme-mois, c'est-à-dire le travail d'un homme pendant un mois. L'unique fait d'utiliser cette unité tend à faire croire qu'un travail de 1 personne pendant n mois peut idéalement être réalisé par n personnes pendant 1 mois ; selon cette idée, on pourrait diviser les temps de développement par deux en mettant deux fois plus de personnel. Or, expérimentalement, cela est faux. Le proverbe cité par Brooks pour exprimer cette idée est : «Neuf femmes ne font pas un enfant en un mois»^[1].

Bien que certaines remarques proprement techniques de l'ouvrage soient particulièrement datées (car portant sur des types de dispositifs depuis longtemps dépassés), de nombreux problèmes soulevés par Brooks sont toujours d'actualité au XXI^e siècle.

Le livre a été publié une première fois en 1975, et réédité en 1995^[2]. La réédition contient l'essai No Silver Bullet (Pas de balle en argent) et des commentaires de l'auteur.

Résumé

Brooks y expose son expérience du développement informatique et surtout du développement d'OS/360 chez IBM. Quoiqu'il mentionne quelquefois des outils ou des problèmes algorithmiques, il s'attache plutôt à l'organisation ainsi qu'aux méthodes de travail des équipes de développement : hiérarchie des responsables, documentation et prévision des délais de développement.

La loi de Brooks

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 constitué au nouveau dispositif, ce qui prend un temps non négligeable que ne peut compenser la productivité ajoutée par le personnel en question. Les nouveaux ont fréquemment besoin d'entraînement et de formation. Qui plus est , leur présence alourdit les canaux de communications. Si n personnes doivent échanger entre elles (sans hiérarchie), lorsque 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).

Formule des canaux de communication : (pour 50 informaticiens, on a ainsi , soit 1 225 canaux de communication).

L'effet du deuxième dispositif

Tout informaticien ayant réalisé un premier dispositif a tendance à créer un deuxième dispositif incorporant l'ensemble des fonctions qu'il n'a pas pu ajouter au premier dispositif par faute de temps. Un informaticien développant un deuxième dispositif devrait par conséquent être conscient du risque de dépassement des spécifications exigées.

Le suivi de projet

Comment un gros projet peut-il être en retard d'un an sur l'horaire prévu ? À cause du retard pris chaque jour de 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.

L'unité conceptuelle

Tout dispositif convivial possède obligatoirement une unité conceptuelle, laquelle est envisageable si l'architecture logicielle est scindé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.

Le mode d'emploi

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.

Le prototype

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

Les documents de base

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

La planification

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

La communication

Dans l'objectif de prévenir les désastres, l'ensemble des équipes affectées à un projet doivent maintenir le contact entre elles à l'aide du plus grand nombre de moyens envisageables (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.

Le «chirurgien en chef»

Toute équipe de chirurgie est menée par un chirurgien en chef, qui s'occupe en personne des tâches principales de l'opération tout en dirigeant son équipe, qui l'appuie et réalise des tâches moins principales. Il est raisonnable de voir une équipe logicielle de la même façon : le meilleur informaticien s'occupe des parties principales du composant à créer, tandis 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.

La gestion de versions et le gel du code

Tout changement au code source doit être connu via un dispositif de gestion de versions. Par contre, le logiciel est invisible. Pour cette raison, plusieurs fonctions ne deviennent visibles qu'après un certain temps de développement. Dès lors, les utilisateurs peuvent commencer à utiliser une partie du programme final. Leur expérience apporte des points de vue nouveaux, qui changent la vision de l'utilisateur ou la vision de ses besoins. Dès lors, le dispositif 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é. L'ensemble des changements conceptuels en attente d'implémentation se retrouveront dans une version future.

Les outils sur commande

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. Qui plus est , des outils utilisés pour la totalité du projet devraient être créés par une équipe dédiée à cette tâche, laquelle est supervisée par le gestionnaire de projets.

La diminution du coût de développement logiciel

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

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

Notes et références

Traduction

Traduction française : "Le mythe du mois-homme", 1996, ITP/Vuibert, traduit par Frédéric Mora, ISBN 978-2-84180-081-0.

Voir aussi

Liens externes

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

Principaux mots-clés de cette page : dispositifs - projet - informaticiens - brooks - développement - équipes - mois - logiciel - fonctions - temps - fois - retard - architecte - travail - outils - devrait - programme - version - tâches - homme - unité - pendant - personne - techniques - communications - doivent - créer - utilisateur -

---

Ce texte est issu de l'encyclopédie Wikipedia. Vous pouvez consulter sa version originale dans cette encyclopédie à l'adresse http://fr.wikipedia.org/wiki/Le_Mythique_homme-mois.
Voir la liste des contributeurs.
La version présentée ici à été extraite depuis cette source le 26/10/2010.
Ce texte est disponible sous les termes de la licence de documentation libre GNU (GFDL).
La liste des définitions proposées en tête de page est une sélection parmi les résultats obtenus à l'aide de la commande "define:" de Google.
Cette page fait partie du projet Wikibis.

---