Note : 9 ; Passionnant, complet et éclairé ! Book of the year 2002 !

Voici un livre à coté duquel il ne faut pas passer. Ne vous laissez pas intimider par le titre, qui peut vous faire croire qu’il s’agit d’une apologie du RAD: il n’en est rien, il s’agit plutôt du développement efficace ».
Avec pas moins de 600 pages constitués de 43 chapitres regroupés en 3 parties, voilà bien un ouvrage impressionnant. La première d’entre-elle couvre une centaine de pages avec 5 chapitres. Le très court chapitre introductif évoque les « pratiques efficaces » évoquées dans l’ouvrage et comment elles se structurent. C’est au second chapitre que l’on en apprends plus avec les 4 piliers du développement rapide associé à 4 dimensions sur lesquelles on peut agir.

Le 3ème chapitre aborde les erreurs classiques des projets listés selon les 4 dimensions (personnes, processus, produit et technologie) avec chaque fois un petit paragraphe descriptif. C’est synthétique et efficace. Le chapitre suivant qui s’attaque aux fondamentaux est plutôt touffu, car il aborde les différents volets tels que gestion de projet, pratiques d’ingénierie et assurance qualité (où bizarrement, on parle assez peu de tests. C’est un peu old school, mais il faut aussi considérer l’âge vénérable de l’ouvrage… La gestion des risques au chapitre 5 est aussi un peu « à l’ancienne », mais dans la catégorie le texte fait remarquablement bien le travail, avec une nomenclature et une catégorisation des risques ainsi qu’une démarche claire et guidée.

La seconde partie, qui reprend le titre de l’ouvrage compte pour sa part 10 chapitres pour un total de 280 pages. Le chapitre 6 qui l’ouvre attaque les problématiques liées au développement rapide. On y trouve pêle-mêle des préoccupations telles que la planification des dates de réalisation, les attentes irréalistes ou la perception de lenteur. Chaque sujet est traité avec finesse et pertinence. Le chapitre 7 nous offre une belle perspective historique sur les cycles de développement, allant du cycle en cascade au modèle en spirale en passant au « code and fixe » (le mode bordel). Il ne s’arrêta pas là car il évoque aussi le stagged delivery et le prototypage. Bref, une belle représentation de différents modèles où est juste absent le mode agile encore très embryonnaire à cette époque. Même si le corpus de connaissance sur les estimations n’est pas directement transposable au monde agile (il s’appuie beaucoup sur le point de fonction), même si le cône d’incertitude est un sujet de discorde avec Laurent Bossavit, ce chapitre 8 rentre remarquablement en profondeur dans le sujet et sera à lui seul une lecture recommandée.

Il est question de planification au chapitre 9, hélas le propos est un peu réducteur car il se concntre et se limite aux causes de la planification optimiste ! On trouve les prémices du développement agile dans le chapitre 10 dédié au développement orienté utilisateur, au cœur du « rapid development » promu par Steve McConnell. Il est moins original 25 ans plus tard, mais l’était fortement à l’époque. Si la motivation intrinsèque est devenu un sujet prédominant à partir de 210, l’auteur n’a pas attendu pour l’évoquer dans le chapitre 11, aux côté des « morale killers ». Bien joué.

On va parler d’équipe au chapitre 11, mais plutôt au sens sociologique : un sens commun, un respact et une confiance mutuelle. Mais aussi la revue de code ou la complémentairité des compétences. Ce sont des thèmes intemporels et fort bien traités. On reste sur le même sujet de l’équipe, mais cette fois de la structure d’équipe avec différents modèles. C’est un passage en revue très complet avec des modèles méconnus, mais chaque modèle n’est que succinctement décrit. C’est de la gestion des besoins qu’il va être question au chapitre 14. Nous sommes ici dans le monde du cahier des charges, l’auteur ne nous en propose pas moins différentes stratégies en fonction des phases du projet. C’est old school mais en fait intéressant.

Les outils de productivité au menu du chapitre 15 n’aborde pas réellement les outils, mais les stratégies à mettre en œuvre pour leur identification, leur évaluation et leur acquisition. L’approche est scientifique mais sans doute pas aussi pragmatique qu’on le souhaiterait. Cette seconde partie se conclut sur un chapitre dédié aux tactiques de sauvetage de projet. Si le chapitre est court, bon nombre de ces tactiques sont bel et bien toujours d’actualité.

La 3ème partie compte près de 200 pages avec 27 chapitres ! C’est bien trop pour tous les passer en revue ici. Chacun couvre une « best practice » sur quelques pages, de manière condensée mais avec un art de la synthèse consommé. Même avec l’épreuve du temps la prose reste plus qu’honorable. Je vais commencer par le Daily build (chapitre 18), qui nous montre que l’intégration continue n’est pas une idée nouvelle, mais Steve McConnell est l’un des premiers à en parler. L’evolutionary delivery (chapitre 20) est une des prémices au développement agile, les quelques pages qui en brossent le portrait sont inspirées de Jim McCarthy. Le JAD, pour Joint Application Design est une idée qui a eu son heure de gloire durant les années 90. Le chapitre 24 nous en donne une excellente synthèse sans avoir à lire un livre sur le sujet.

Le « miniature milestone » s’inscrit également dans la veine des prémices de l’agilité. Ici, c’est Tom Gilb qui sert de mentor à l’auteur pour ce chapitre 27. Par contre je vais passer rapidement sur le chapitre 28 qui identifie l’outsourcing comme une « best practice »… Le « productivity environment » du chapitre 30 mériterait sans doute que l’on s’y arrête plus souvent, aujourd’hui encore… Toujours dans la veine agile, le chapitre 39 évoque le « timebox development » qui, tel que décrit ici, n’est ni plus ni moins que les sprints Scrum !

L’auteur démontre une impressionnante connaissance et maîtrise de tout ce qui touche au développement logiciel, ce n’est pas par hasard qu’il fut éditeur en chef d’IEEE Software. Le livre est volumineux (plus de 600 pages), mais à aucun moment oiseux. La 3ème PARTIE consacrée aux « best practices » de la gestion de projetsest presque de l’or en barre, même si l’ouvrage date de 1996. On comprend aisément qu’il ait été couronné du fameux « Jolt award » du journal Software Development.

Référence complète : Rapid Development, Taming wild software schedules – Steve McConnell – Microsoft Press 1996 – ISBN: 1-556156-900-5