Une revue en retard de la lecture elle-même déjà un peu tardive de ce livre très connu sur la gestion de projet informatique:
Le Mythe du mois-homme par Fred. P. Brooks, 1995 (1ere édition 1975)
J'ai beaucoup entendu parler de ce livre ces dernières années et j'ai été étonné de constater que tout ce qu'on en dit est vrai !
Derrière une patine qui est en intéressante pour elle-même et aussi parfaitement attendue pour un livre écrit à l'aube du développement informatique (1975 !) tout semble curieusement actuel: de l'incapacité chronique des développeurs à concevoir les difficultés qui ne manqueront pas de perturber la retranscription de leurs idées sous la forme d'un programme stable, à la tendance naturelle des managers à chercher à faire grossir leurs équipes tout en négligeant les gains de performance atteignables par une meilleure circulation de l'information et la mise à disposition de meilleurs outils pour leurs équipes, tout y est !
Un autre point particulièrement intéressant: dans l'édition de 1995 l'auteur rajoute des observations qui lui permettent de répondre à ses premières critiques, de confirmer certaines de ses affirmations et de pointer à certaines de ses erreurs. Le livre contient sa propre revue !
Inutile de préciser que ce livre est incontournable pour ceux qui sont intéressé par la gestion de projet logiciel, et malgré cela, le premier aspect qui m'a plu réside dans la justesse avec laquelle l'auteur caractérise le "plaisir de programmer":
- la joie de fabriquer quelque chose
- la joie de faire quelque chose d'utile
- la fascination pour les puzzles
- la joie d'apprendre en permanence
- la joie de travailler de la matière qui est essentiellement de la "pensée pure"
Dans la suite de ce billet, je relève quelques uns des autres points saillants du livre en essayant de les classer en trois catégories: planification, développement, organisation.
Planification
- la loi de Brooks: rajouter des personnes à un projet en retard va mettre le projet encore plus en retard, ce qui s'explique par le temps pris par la re-distribution des tâches, par la formation des nouveaux venus, et par la hausse du coût d'inter-communication.
- la règle (heuristique) de Brooks: réaliser un "produit système" multi-composant et bien testé prend 3 fois plus de temps que de réaliser un simple programme stable qui prend déjà 3 fois plus de temps que de développer un logiciel pour une utilisation privée.
- La maintenance coûte 40% du prix du développement, une correction de bug a 20-50% de chances de créer un nouveau bug et les "réparations" ont tendance à détruire la structure initiale du logiciel.
Développement
- l'intégrité conceptuelle est cruciale pour la réalisation d'un système multi-composant
- la facilité d'utilisation peut se mesurer par le ratio entre fonctionnalités et complexité (du code)
- les tests doivent mettre en jeu des données valides, des cas limites et des données invalides
- la documentation doit fournir une vue d'ensemble complète et expliquer les raisons des choix techniques qui ont été pris
Organisation
- utiliser des outils performants et faire en sorte que les équipes soient à leurs aises
- structurer les équipes pour le changement (les gens doivent échanger leurs rôles !)
- les toutes petites équipes ultra-compétentes sont les plus efficaces
- la communication doit être permanente (pour les décisions techniques et les statuts du projet)
- un architecte doit généreusement reconnaître les crédits et mérites des autres membres de l'équipes et les écouter
A la croisée des chemins
Enfin, pour certains arguments, je n'ai pas pu les attribuer à une seule des catégories précédentes car il me semblait qu'ils les recoupaient toutes:
- les besoins et la perception que le client/utilisateur a de ces besoins changent inévitablement
- des changements justifiés d'objectifs se produisent systématiquement: il faut s'y préparer !
- les retards chroniques dans les développements sont fatals au moral d'une équipe
Il me semble d'ailleurs que ces 3 derniers points sont ceux qui ont été depuis ciblés en priorité par les méthodes Agiles.
