Le mois-homme mythique

Brooks discute de plusieurs causes d’échecs de planification. Le plus durable est sa discussion sur la loi de Brooks: L’ajout de main-d’œuvre à un projet logiciel tardif le rend plus tard. Le mois-homme est une unité de travail hypothétique représentant le travail effectué par une personne en un mois; La loi de Brooks dit que la possibilité de mesurer le travail utile en mois-homme est un mythe et constitue donc la pièce maîtresse du livre.

Les projets de programmation complexes ne peuvent pas être parfaitement divisés en tâches discrètes sur lesquelles on peut travailler sans communication entre les travailleurs et sans établir un ensemble d’interrelations complexes entre les tâches et les travailleurs qui les exécutent.

Par conséquent, affecter plus de programmeurs à un projet en retard le rendra encore plus tard. En effet, le temps nécessaire aux nouveaux programmeurs pour en apprendre davantage sur le projet et l’augmentation des frais généraux de communication consommeront une quantité toujours croissante du temps de calendrier disponible. Lorsque n personnes doivent communiquer entre elles, à mesure que n augmente, leur production diminue et lorsqu’elle devient négative, le projet est encore retardé avec chaque personne ajoutée.

• Formule d’intercommunication de groupe: n(n-1) /2
• Exemple: 50 développeurs donnent 50 · (50 – 1) / 2 = 1225 canaux de communication.

Pas de balle d’argentmodifier

Brooks a ajouté « No Silver Bullet — Essence et Accidents du Génie Logiciel » — et d’autres réflexions à ce sujet, « ‘No Silver Bullet’ Refired » — à l’édition anniversaire du Mythique Mois-Homme.

Brooks insiste sur le fait qu’il n’y a pas de solution miracle one « il n’y a pas de développement unique, ni dans la technologie ni dans la technique de gestion, qui en soi promet même une amélioration d’un ordre de grandeur d’ici une décennie en termes de productivité, de fiabilité, de simplicité. »

L’argument repose sur la distinction entre complexité accidentelle et complexité essentielle, de la même manière que la loi d’Amdahl repose sur la distinction entre « strictement série » et « parallélisable ».

L’effet du deuxième système

L’effet du deuxième système propose que, lorsqu’un architecte conçoit un deuxième système, c’est le système le plus dangereux qu’il concevra jamais, car il aura tendance à incorporer tous les ajouts qu’il n’a pas ajoutés au premier système à l’origine en raison de contraintes de temps inhérentes. Ainsi, lorsqu’il se lance dans un deuxième système, un ingénieur doit être conscient qu’il est susceptible de le sur-concevoir.

La tendance au nombre irréductible d’errorsEdit

L’auteur fait le constat que dans un système suffisamment complexe, il existe un certain nombre irréductible d’erreurs. Toute tentative de correction des erreurs observées a tendance à entraîner l’introduction d’autres erreurs.

Progress trackingEdit

Brooks a écrit « Question: Comment un grand projet logiciel arrive-t-il à avoir un an de retard? Réponse : Un jour à la fois! »Les dérapages progressifs sur de nombreux fronts finissent par s’accumuler pour produire un retard global important. Une attention soutenue à la réalisation de petits jalons individuels est nécessaire à chaque niveau de gestion.

Intégrité conceptuelledit

Pour rendre un système convivial, le système doit avoir une intégrité conceptuelle, qui ne peut être obtenue qu’en séparant l’architecture de la mise en œuvre. Un seul architecte en chef (ou un petit nombre d’architectes), agissant pour le compte de l’utilisateur, décide de ce qui se passe dans le système et de ce qui reste en dehors. L’architecte ou l’équipe d’architectes doit développer une idée de ce que le système doit faire et s’assurer que cette vision est comprise par le reste de l’équipe. Une idée originale de quelqu’un peut ne pas être incluse si elle ne correspond pas parfaitement à la conception globale du système. En fait, pour garantir un système convivial, un système peut délibérément fournir moins de fonctionnalités qu’il n’en est capable. Le fait étant que si un système est trop compliqué à utiliser, de nombreuses fonctionnalités seront inutilisées car personne n’a le temps de les apprendre.

Le Manuelmodifier

L’architecte en chef produit un manuel de spécifications du système. Il doit décrire en détail les spécifications externes du système, c’est-à-dire tout ce que l’utilisateur voit. Le manuel devrait être modifié au fur et à mesure que les équipes de mise en œuvre et les utilisateurs reçoivent des commentaires.

Le système pilotdit

Lors de la conception d’un nouveau type de système, une équipe conçoit un système jetable (qu’elle en ait l’intention ou non). Ce système agit comme un « plan pilote » qui révèle des techniques qui entraîneront par la suite une refonte complète du système. Ce deuxième système, plus intelligent, devrait être celui livré au client, car la livraison du système pilote ne causerait rien d’autre qu’une agonie au client, et peut-être ruinerait la réputation du système et peut-être même l’entreprise.

Documents formelsmodifier

Chaque chef de projet doit créer un petit ensemble de documents formels définissant les objectifs du projet, comment ils doivent être atteints, qui va les atteindre, quand ils vont être atteints et combien ils vont coûter. Ces documents peuvent également révéler des incohérences qui sont autrement difficiles à voir.

Estimation de projetmodiFier

Lors de l’estimation des temps de projet, il convient de rappeler que les produits de programmation (qui peuvent être vendus à des clients payants) et les systèmes de programmation sont trois fois plus difficiles à écrire que de simples programmes internes indépendants. Il convient de garder à l’esprit combien de la semaine de travail sera réellement consacrée à des questions techniques, par opposition à des tâches administratives ou autres tâches non techniques, telles que les réunions, et en particulier les réunions « debout » ou « à mains nues ».

CommunicationEdit

Pour éviter une catastrophe, toutes les équipes travaillant sur un projet doivent rester en contact les unes avec les autres de toutes les manières possibles — e-mail, téléphone, réunions, mémos, etc. Au lieu de supposer quelque chose, les implémenteurs devraient demander au(x) architecte (s) de clarifier leur intention sur une fonctionnalité qu’ils implémentent, avant de procéder à une hypothèse qui pourrait très bien être complètement incorrecte. Le ou les architectes sont chargés de formuler une image de groupe du projet et de la communiquer aux autres.

L’équipe chirurgicaledit

Tout comme une équipe chirurgicale pendant la chirurgie est dirigée par un chirurgien effectuant le travail le plus critique, tout en demandant à l’équipe d’aider avec des parties moins critiques, il semble raisonnable qu’un « bon » programmeur développe des composants système critiques tandis que le reste d’une équipe fournit ce dont elle a besoin au bon moment. De plus, Brooks pense que les « bons » programmeurs sont généralement cinq à dix fois plus productifs que les médiocres.

Gel du code et versioningEdit du système

Le logiciel est invisible. Par conséquent, beaucoup de choses ne deviennent apparentes qu’une fois qu’un certain travail a été effectué sur un nouveau système, permettant à un utilisateur de l’expérimenter. Cette expérience donnera des informations, qui modifieront les besoins d’un utilisateur ou la perception de ses besoins. Le système doit donc être modifié pour répondre aux exigences modifiées de l’utilisateur. Cela ne peut se produire que jusqu’à un certain point, sinon le système pourrait ne jamais être terminé. À une certaine date, plus aucune modification ne devrait être autorisée au système et le code devrait être gelé. Toutes les demandes de modifications doivent être retardées jusqu’à la prochaine version du système.

Outils spécialisésdit

Au lieu que chaque programmeur ait son propre ensemble spécial d’outils, chaque équipe devrait avoir un fabricant d’outils désigné qui peut créer des outils hautement personnalisés pour le travail que l’équipe effectue, par exemple, un outil générateur de code qui crée du code basé sur une spécification. De plus, les outils à l’échelle du système doivent être créés par une équipe d’outils communs, supervisée par le chef de projet.

Réduire les coûts de développement logicielmodifier

Il existe deux techniques pour réduire les coûts de développement logiciel sur lesquelles Brooks écrit :

• Les implémenteurs ne peuvent être embauchés qu’une fois l’architecture du système terminée (une étape qui peut prendre plusieurs mois, pendant laquelle les implémenteurs embauchés prématurément peuvent n’avoir rien à faire).
• Une autre technique mentionnée par Brooks n’est pas de développer un logiciel du tout, mais simplement de l’acheter « sur étagère » lorsque cela est possible.