Note : 7 ; Beaucoup de clairvoyance et de clarté dans l’illustration de cas réels, une pertinence du texte qui résiste mais s’est érodée avec le temps.
Ce livre est rédigé de façon pragmatique, c’est probablement pourquoi il ne compte que 200 pages, volume au delà duquel il faut planifier du temps pour lire entièrement l’ouvrage. L’auteur s’est attaché à décrire comment une organisation pouvait basculer vers l’objet, les stratégies possibles et comment mettre le maximum d’atouts de son coté. Les cas de figure sont abondamment illustrés de cas de figure réels, aussi bien en succès qu’en échecs. Mais voyons plus avant son contenu. Les 200 pages de son contenu sont réparties sur 8 chapitres, mais il faut aussi évoquer les 40 pages d’annexes.
Le premier chapitre est un rappel des concepts de base de l’objet : encapsulation, polymorphisme, etc.. Rien de vraiment original, surtout en 98 où l’objet est quand même un acquis. Mais le propos a le mérite d’être clair.
Le second chapitre est plus original, car il reprend de manière très succincte 11 projets avec leurs facteurs clés de succès, d’échecs ou simplement de difficultés. Chaque cas est exposé sur moins d’une page avec un cartouche caractérisant le projet. En synthèse de ce chapitre l’auteur expose les avantages et les coûts liés aux projets objet. Le contenu est original et reste intéressant, même maintenant.
Les 40 pages du chapitre 3 sont dédiées aux choix et au setup du projet. Quel type de projet doit-on choisir pour faire son premier projet objet ? Avec quelles personnes et surtout avec quel langage ? Certains des points évoqués font largement sourire aujourd’hui. Comme par exemple la question d’un nouveau venu « périphérique » : Java. Aujourd’hui c’est surtout avec ce regard historique que l’on lira ce chapitre dont le propos a perdu de sa pertinence au fil du temps.
Au chapitre 4, on discute méthodologie et plus exactement ce que l’auteur appelle « big-M » versus « little-m » methodologies. Le big-M, ce sont les vrais processus, alors que les little-m ce sont les notations dérivant vers des méthodes/processus d’usage de ces notations. L’auteur exhorte d’abandonner le little-m et de se consacrer au big-M en statuant sur le choix d’un « big shop » ou « small shop » methodologies. Ce qui deviendra plus tard sa « cristal family of methods ». Même si l’auteur conseille de ne pas faire trop lourd, on reste quand même dans la logique rôles / activités / outils, sans compter le plan, les milestones, etc.. On reste assez loin de l’agilité quand même.
Justement, le très long chapitre 5 (près de 50 pages) est exclusivement consacré aux aspects itératifs et incrémentaux des projets. L’auteur y explique par le menu la différence entre les deux et l’avantage des les combiner et compare l’utilisation de ce mode à une « correction de trajectoire ». Cette lecture reste pertinente, même aujourd’hui.
Par comparaison, le chapitre 6 est très court, car il ne compte que 10 pages. L’auteur y évoque les phrases qu’il aurait souhaité de ne jamais entendre. Ce que j’appelle de mon côté les tartes à la crème. Certaines de ces idées reçues sont passées de mode (du moins je crois) mais d’autres ont la vie dure… On passe un bon moment à passer cela en revue !
Le chapitre 7 traite le cas des gros projets et se focalise spécifiquement sur les facteurs de réduction de risque. Là encore, il s’agit d’une lecture qui ne se démode pas.
Le dernier chapitre revisite l’un des cas exposé au premier chapitre et montre comment un échec aurait pu être évité à la lumière des éléments exposés dans le livre.
N’oublions pas non plus l’annexe A, la plus importante qui reprend sous forme de patterns, les stratégies de réduction de risques. Pas mal.
Le livre mérite sans contestation possibles son titre. Il accuse par pas mal de facettes le poids des ans. Il devient difficile de le conseiller, surtout quand de l’excellente littérature agile peut vous montrer la voie. Quelques chapitres méritent le détour, même aujourd’hui. Mais on en est plus à considérer les projets orientés objet comme de la technologie d’avant-garde…
Référence complète : Surviving Object-Oriented Projects, a manager’s guide – Alistair Cockburn – Addison Wesley / Object Technology Series 1998 – ISBN: 0-201-49834-0
Software Freethinker 
