J’ai profité de mes dernières vacances pour lire « The Mythical Man-Month » (Amazon) de Frederick P. Brooks, Jr. (un des ténors du génie logiciel).

C’est LE livre qui apparaît systématiquement dans les tops 10 des livres à lire pour les ingénieurs logiciels, chefs de projet, développeurs ou encore manageurs de développeurs.

Même si l’édition originale date de 1975, et l’édition anniversaire de 1995, la plupart du contenu reste entièrement d’actualité, puisqu’il s’agit principalement de bon sens. Enfin surement qu’à l’époque beaucoup des choses qu’il raconte étaient nouvelles. Aujourd’hui elles font partie – ou devraient faire partie – de la culture de base de l’informaticien au sens large

Je vous livre quelques idées du bouquin histoire de bien cerner l’ouvrage :

• (p5,6) On peut étendre un programme en travaillant sur son industrialisation (généralisation, documentation, tests, maintenance…) ou sur son intégration (interfaçages à d’autres systèmes, intégration dans l’écosystème de l’IT), mais pas les 2 en même temps.
• (p16-19) Ajouter des développeurs à un projet en retard le retardera encore plus, aussi connu sous « 9 femmes enceintes ne font pas un bébé en un mois ».
• (p32-36) Il propose une méthode d’organisation pour les très gros projets : mettre en place N équipes de 10 personnes chacune centrées autour d’un lead programmer (le chirurgien, un mec ultra talentueux), son copilote (le même en un peu plus junior, qui apprend et vérifie), les 2 seuls à développer et une équipe de support.
• (p45,46) Définition de l’architecte (il le sous-entend fonctionnel – la MOA quoi) : qui représente l’intérêt de l’utilisateur, qui doit indiquer quel est le résultat attendu mais pas comment cela doit être fait. Par opposition au constructeur (la MOE), qui lui prend en compte les contraintes et le ratio coût/performance, et conçoit  la solution. Ce qui amène un cycle de développement : Architecture (MOA – On définit la fonction d’une boîte noire) > Implémentation (MOE –  On établit le contenu de la boîte) > Réalisation (MOE – On fabrique la boîte). Ne vous offusquez pas sur son choix de vocabulaire, qui diffère de ce qu’on a l’habitude d’employer en France, l’important c’est le découpage des tâches et des responsabilités.
• (p62) Les spécifications sont le manuel utilisateur.
• (p116) Le mieux est de toujours commencer par un prototype, jetable ci-besoin, plutôt que de vouloir y arriver du premier coup, puisque la plupart du temps on recommencera plusieurs fois du début.
• (p117) Tous les besoins utilisateurs ne doivent pas être pris en compte dans le design. Et plus on avance dans le projet, plus c’est vrai.
• (p142) Il faut tester les spécifications : faire des maquettes, tester les règles de gestion, avant même de commencer le développement.
• (p143) Le mieux est de faire des programmes modulaires, afin d’augmenter la capacité d’adaptation du système (En 1975 manifestement ce n’était pas évident ;)).
• (p155) Les jalons sur le planning doivent être clairement identifiés (périmètre et date), afin de ne pas pouvoir se mentir à soi-même par rapport à l’avancement.
• (p157) Un directeur de projet ne doit pas intervenir dès le premier retard d’un de ses chefs de projet, sans quoi ils arrêteront de rapporter les glissements pour fuir le micromanagement.
• (p201) Le développement itératif c’est le top (En 1975 ! C’était révolutionnaire !)

Évidemment il y a plein d’autres choses très intéressantes, et à chaque fois il développe et justifie ses idées, mais pour moi le top est dans cette liste.

Vous faut-il le lire ?  Je dirais oui si :

• Vous vous devez d’avoir de la crédibilité en tant que bloggeur qui ramène sa fraise sur la gestion de projet (mon cas ;)).
• Vous êtes ou aspirez à devenir chef de projet et que vous voulez comprendre le pourquoi de ce que vous appliquez.

Dans le cas contraire, votre bon sens, l’expérience personnelle et suivre la « BI ça vous gagne » suffiront largement à faire votre culture 🙂