The Mythical Man-Month – Frederick P. Brooks, Jr.

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 🙂

4 liens rapides pour la semaine (2012-16)

Que des classiques cette semaine:

  1. David Heinemeier Hansson de 37 Signals avec un petit rappel de bon sens face aux dérapages de valorisation de certaines start-ups.
  2. Marco Arment d’Instapaper qui commente la récente promesse de Twitter de ne pas faire de bêtises avec ses brevets.
  3. Garrett Murray de Karbon avec une belle satire de l’annonce d’Asus de rattraper le GPS défectueux de leur tablette par un dongle.
  4. Scott Berkun, que je citais encore précédemment, qui nous offre un extrait gratuit de son fameux Making Things Happen. Ça parle gestion de projet et développement personnel.

______________________

<< Semaine Précédente – Semaine Suivante >>

Combien de personnes avez-vous dérangé aujourd’hui?

Un petit concentré de bon sens de Brendan Daws (via Max Voltar) :

« Le monde est rempli de choses moyennes faites par des gens qui ne veulent déranger personne, ou par des gens qui ne recherchent que la reconnaissance de leurs pairs. »

Cette idée est loin d’être neuve, la remise en cause du statu quo qui dérange la masse endormie, elle revient d’ailleurs souvent chez Seth Godin et consort, ça fait juste du bien de la voir se propager.

Pour ma part, vu le nombre de personnes qui m’en veulent au boulot, c’est vraiment que je dois faire des choses hors du commun 😀

D’ailleurs il ne faut pas oublier son corolaire : lorsque des gens s’énervent au boulot, ce n’est pas forcément un mauvais signe. En effet, cela signifie qu’ils se préoccupent encore suffisamment de ce qu’ils font pour que cela puisse provoquer des émotions fortes comme de la colère. A tord ou à raison, c’est au manager de gérer, mais au moins les émotions sont là, et cela il faut le cultiver.