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.

Note : 8 ; Inclassable, instructif et passionnant.

Aussi surprenant que cela puisse paraitre, ce livre est simplement la compilation des « posts » de Joel Spolsky sur son blog « Joel on Software ». Les textes n’en ont pas été retouchés, ni rallongés pas plus qu’ils n’ont été agrémentés. Ils ont simplement été mis en page, rassemblés en un livre avec table des matières, index, couverture, relire et tout et tout.

Donc ce que vous pouvez acheter sous forme de livre, vous pouvez le lire gratuitement sur le net ! Le livre, justement, couvre 45 posts regroupés en 4 parties (la 5ème est consacrée aux annexes). Les posts sont ainsi regroupés de manière thématique et la taille de ces parties est en conséquence inégale. La première partie va aussi s’avérer la plus longue. Elle regroupe 19 posts et cible les pratiques de développement (au sens large). 3 sujets ont attisé ma curiosité ici. La série de 4 posts sur les spécifications, d’abord. Elles contiennent les germes de la définition du PO mais révèlent aussi un point de vue pour moi dépasser : écrire pour limiter la communication entre les intervenants, et gagner en efficacité ! Le second sujet a trait au craftsmanship. Il est la prémices du mouvement du même nom, même si l’auteur ignore encore (ou volontairement ?) la culture agile naissante. Le troisième sujet est marginal et évoque le « biculturalisme » chez Microsoft. Un sujet qui explique bien des choses sur la société.

La seconde partie est consacrée à la gestion des développeurs et est riche de 9 posts. Le plus célèbre, et très souvent référencé encore aujourd’hui est « The Law of Leaky Abstraction ». Cette loi stipule qu’une abstraction de haut niveau, destinée à masquer une réalité de plus bas niveau, montrera des failles ou des faiblesses dans certaines conditions. Le corolaire de cette loi est qu’on ne peut se contenter de connaitre cette abstraction de haut niveau, mais qu’il est nécessaire de connaitre voir de maitriser le niveau sous-jacent, car il expliquera certains comportements de cette « abstraction qui fuit ». Je conseille aussi deux posts consacrés au recrutement et à la rémunération. Vous n’êtes pas obligés d’être d’accord avec l’auteur, mais au moins donnent-ils à réfléchir.

Note : 8 ; Une excellente surprise, qui va plus loin que la mise en œuvre de RCS en présentant les finalités de la gestion du changement.

Pourquoi parler de SCCS et de RCS quand on utilise Clear Case ? au mi-temps des années 90, c’est le genre de questions que l’on pouvait se poser. Cet excellent ouvrage ne se limite pas à la comparaison de ces 2 utilitaires (il donne la préférence à RCS, l’ancêtre de CVS). Nous allons le voir.
L’ouvrage est du genre mastoc avec ses 23 chapitres sur 440 pages hors annexes. Comptez 50 pages de plus pour ces dernières ! Le premier chapitre est un simple tour de chauffe destiné à présenter les concepts de base de la gestion des sources.

Les chapitres 2 à 4 viennent en triplet, et ce sera vrai pour la suite de l’ouvrage : d’abord les principes généraux, puis la déclinaison RCS et enfin celle de SCCS. On commence ici avec les concepts de base : la copie de travail d’un fichier, la gestion du verrouillage… Bref, tout ce qui permet de faire une modification. Le chapitre RCS marche exactement dans les traces du chapitre 2 en présentant la syntaxe de cet outil pour lancer les commandes correspondantes. Il en va presque de même pour SCCS dont la philosophie est légèrement différente. Mais un tableau récapitule lesdites commandes pour les deux outils à la fin de chaque chapitre. Pratique.

Le second triplet nous fait faire un grand bond en avant, car on y aborde les concepts tels que branches, numéros de révision et snapshots. Les auteurs adoptent un angle « cas d’utilisation », plus pragmatique mais pas toujours facile à suivre. Pour la déclinaison RCS, le texte s’appuie beaucoup sur les fonctionnalités de branching (et donc de merge) de l’outil, tandis que le snapshot n’est guère évoqué. Côté SCCS, les choses paraissent même plus pauvres, mais on parvient à faire le lien avec le chapitre des généralités.

Note : 8 ; Toute la perspicacité et l’expérience de Grady Booch dans cet incontournable ouvrage. Malheureusement, la traduction française et la qualité éditoriale ne sont pas à la hauteur.

Grady Booch est ce que nous pourrions appeler un récidiviste. Encore une fois il nous gratifie d’un excellent ouvrage. Aujourd’hui, il s’agit de mettre en lumière les meilleures pratiques sur la gestion de projets objets, itératifs et incrémentaux. Trois éléments principaux servent de charpente à l’ouvrage : Les histoires vécues (par Grady Booch), les conseils et les trucs et astuces.

Le livre lui-même est composé de 7 chapitres totalisant 290 pages pour sa partie principale. Le premier chapitre « premier principes » se focalise sur la nature incrémentale et itérative des projets objet, tout en mettant l’accent sur le fait que la structuration objet est facilitante mais ne suffit pas à garantir le succès d’un projet. L’auteur met clairement l’accent sur la nature émergente du projet et de son architecture, ce que sous-tend le caractère itératif, une architecture qui ne s’arrête d’ailleurs pas à la décomposition en classes. C’est un très bon chapitre qui met le doigt là où il faut.

Le second chapitre « produit et processus » est moins passionnant et date bien le livre d’une époque « anté-agile ». La première partie du chapitre pose des concepts et conseils de structuration objet qui forment le socle de la « méthode Booch » que l’on retrouvera plus tard en partie dans UML », tandis que la seconde partie est d’avantage focalisée sur la méthode. On y voit les prémices d’Unified Process, même si en l’état c’est plus léger. Mais il reste indiscutablement un fossé avec l’agilité.