It is said that power corrupts, but actually it’s more true that power attracts the corruptible.
the sane are usually attracted by other things than power.
David Brin
Étiquette : management
Project Management. Sigh!
“Let’s organize this thing and take all the fun out of it” — Ashleigh Brilliant
I’m aware that some folk think I like to dismiss project/program managers as unnecessary overhead in organizations, so I’ll start by saying I know some wonderful people who work under these titles. This post is not…
The best way to screw up the usefulness of any process metric is to use it to judge people.
Elisabeth Hendrickson
There are a million ways to lose a work day, but not even a single way to get one back.
Tom DeMarco
Carnet de route : Agile France 2014 (2/4)
Suite de notre première journée d’Agile France.
On se dirige tout doucement vers l’activité de l’après-midi. Toutefois, nous allons avant cela prendre 10 minutes pour une photo de groupe !
Une formule inédite pour cette première après-midi : elle est entièrement consacrée à un open-space ! Cela rapelle un peu la formule du ScrumDay, elle-même inspirée d’Agile Grenoble. Mais peu importe qui emprunte à qui !
Open-space : ouverture !
Pour cette ouverture, nous nous retrouvons tous dans la grande salle Belvédère.
Ca fait du monde, vous en serez peut-être plus convaincus avec la vue panoramique ?
L’ouverture de cet open-space ressemble d’autant plus à celui du ScrumDay que c’est de nouveau Raphael Pierquin que l’on retrouve aux commandes !
Il n’est pas seul, Lan Levi lui donne la réplique.
Nous avons de la chance en ce Jeudi après-midi : la météo est avec nous ! On pourra se mettre à l’intérieur des salles et dehors. Dans ces conditions, le Chalet de la Porte Jaune est tout simplement l’endroit idéal pour faire un open-space. La place de marché nous permet d’utiliser tous ces lieux.
Qu’est-ce qu’un manager agile ?
J’ai trainé un moment du côté de la session proposée par Alain Buzzacaro sur le manager agile, avec l’envie de confronter mon expérience avec celle des autres, mais aussi d’avoir la perception d’un membre de Codir (ce qui est le cas d’Alain). J’ai vite été déçu par la teneur des échanges. En fait, il m’est apparu qu’une bonne partie de l’assistance n’avait aucune expérience du management. Ca n’empêche pas d’exprimer un avis, visiblement…
Parmi les quelques points relevés (histoire que vous ne pensiez pas que je n’ai rien relevé) :
- L’agilité est un style de management.
- Le manager est en partie un coach pour son équipe.
- Son travail est de faire grandir son équipe. Merci Alain !
- Donner du sens est une dimension importante de son travail.
J’applique la loi des deux pieds et vais voir ailleurs.
L’assertivité
Dommage que je n’ai pu assister depuis le début à la session animée par Mathilde Remy ! Arriver en cours de route m’empêche de bien raccrocher les wagons. Mathilde anime cette session sous forme d’un jeu de rôle.
Doublement dommage, d’ailleurs, car Farid se livre à l’exercice : son calme et son rationalisme sont terriblement efficace. J’en sais quelque chose, je l’avais moi-même recruté dans mon équipe il y a quelques années…
Je sens que vous voulez un nouveau petit panoramique ! Allez, hop !
Ah oui, n’oublions pas non plus le travail des scribers !
Comment amener mon directeur à l’agilité
Cette session est du vécu, un cas réel. Cela m’a semblé intéressant de m’y pencher. Disons, pour diverses raisons…
Au départ, il s’agissait de confronter les expériences, mais finalement nous sommes arrivés à réfléchir autour de ce cas particulier ! Le constat n’apporte pas beaucoup d’espace de manoeuvre :
- Ce manager n’a pas de problème : pourquoi devrait-il changer ? Rien d’étonnant à ce que l’argumentaire ne porte pas.
- Est-ce important que ce manager aille dans ce sens ? Ne peut-on « vivre avec » ? C’est hélas important : cette attitude a un impact notable sur l’équipe : démoralisation, départs…
Je ne suis de toute façon pas très bon à cet exercice. S’il fut un temps lointain où je m’y livrais, j’ai abandonné de puis très, très longtemps l’idée de chercher à convaincre des personnes qui n’ont pas envie de l’être.
En fait aujourd’hui je ne cherche plus à convaincre du tout. Ca ne m’intéresse pas, je n’ai pas une vocation de martyre. Je préfère travailler avec des gens qui ont envie d’avancer dans le même sens que moi, avec qui je pourrais me poser des question, que je pourrais aider.
De nouveau, nous avons été scribés en live avec talent !
Ces fresques valent largement ma prose, je vous laisse en profiter.
Et aussi…
Les accords Toltèque
Depuis le temps que j’en entend parler… Je n’ai pas hésité longtemps à rejoindre le petit groupe se formant autour de Frédéric Dufau-Joël sur ce sujet.
Les accords Toltèque nous viennent du peuple éponyme d’Amérique Centrale. Ces accords sont au nombre de 4 :
- Que votre parole soit impeccable.
- Quoi qu’il arrive, n’en faites pas une affaire personnelle.
- Ne faites pas de suppositions.
- Faites toujours de votre mieux.
Je trahis certainement un peu la chose en disant qu’il s’agit d’une sorte de manifeste de la facilitation … ou même d’une discipline de vie, si j’en crois ce que disent certaines personnes du cercle !
Frédéric anime la discussion autour de deux livres écrits par un Chamane Mexicain, Miguel Ruiz, dont le premier est justement le best seller « les 4 accords Toltèque ».
Autres lieux, autres sujets…
On ne peut être partout à la fois. Ailleurs, il y avait aussi :
La définition du bon coach
ou encore du théatre d’improvisation, avec Vincent et Simon !
Clôture de l’open-space
Nous nous retrouvons une dernière fois en salle Belvédère pour partager nos impressions.
L’intelligence collective, par Thibaud Brière
Thibaud est « philosophe en entreprise » ! Je ne savais même pas que cela existait !
Pourquoi s’intéresser à l’intelligence collective, et surtout : pourquoi les grandes entreprises s’y intéressent-elles ? Parce qu’aujourd’hui, elles veulent concilier l’avantage que leur donne leur taille avec la réactivité des startups ! L’intelligence collective est donc un moyen pour être plus adaptable.
Qu’est-ce que l’intelligence collective ?
C’est une dynamique de groupe s’appuyant sur la capacité à diverger. En ce sens, on entretient la pluralité de point de vue plutôt que la convergence, qui est en fait du mimétisme et finalement une abolition du raisonnement. Le point critique est de passer de l’opinion à la pensée ! Cela signifie bien entendu des techniques de facilitation adaptées.
Pour Thibaud Brière, la pensée, c’est une opinion (au départ) + la confrontation à d’autres opinions.
L’orateur différentie aussi diversité et variété, une nuance que je ne suis pas parvenu à saisir.
Ce que j’en ai pensé
J’ai retenu deux ou trois choses de cette intervention :
- Différencier opinion et pensée.
- Faire fonctionner la divergence (cela me rappelle la keynote de Régis) et valoriser les opinions minoritaires.
- Encourager l’impertinence.
Je reste un peu sur ma faim. Il faut dire que le format choisit favorisait les interruptions, ce qui n’a peut-être pas aidé (toutes interruptions étaient loin d’être pertinentes).
Au sortir de la cette intervention, les avis étaient très partagés sur l’intérêt de du sujet.
Fin de journée
Pas de diner pour moi, la faute à un gros mal de tête. Visiblement, celui-ci fut bien animé, Alex Boutin s’en est chargé en préparant un quizz durant l’open space !
C’est tout pour aujourd’hui. Rendez-vous très bientôt !
If everything is under control, you’re going too slow.
Mario Andretti
Carnet de route : Le ScrumDay 2014 (4/4), Bonus track !
Après avoir couvert mon parcours de ces 2 jours de ScrumDays (ici, ici et ici), une question reste en suspens : et les autres sessions ? J’ai donc été rechercher du mieux que j’ai pu les supports de présentation des sessions auxquelles je n’ai pu assister. Il en manque encore hélas beaucoup, sans compter la mise en ligne des vidéos. Si vous avez des liens vers les supports manquants, faites m’en part, je les rajouteraient.
Pour commencer, voici le livret des sessions, en mode présentation
La transformation numérique de France Télévision
France Télévision fut le premier sponsor « client final » du French SUG ! Ils nous partagent leur retour d’expérience.
Vous retrouverez aussi cette présentation via le blog d’Alain Buzzacaro.
Le Lean Startup au service du Product Owner, par Jérôme Guenver
J’ai entendu dire beaucoup de bien de cet atelier animé par Jérôme. Un atelier que Jérôme a imaginé suite à une discussion que nous avons eu ensemble chez Zenika. Je suis donc plutôt heureux d’avoir eu un petit rôle pour inspirer un collègue !
Des outils du monde de la psychologie… par Bruno Sbille
On ne présente plus Bruno, en tout cas on ne devrait plus ! Bruno est l’un des piliers de l’imposante communauté agile Belge. Il est aussi l’organisateur de l’Agile Tour Bruxelles auquel je participe depuis sa création (et j’espère continuer). Lors de ce ScrumDay, il proposait cet atelier en plus de son rôle dans la « coach clinic » !
Dans cet atelier, Bruno présentait et permettait d’expérimenter divers outils tels que la PNL, le VAK, etc. Je me souviens encore que Bruno avait fait le déplacement depuis Bruxelles pour la soirée de création du French SUG il y a 6 ans de cela. C’était justeent pour nous parler de PNL !
Let’s Sketch together, par Alvin Berthelot
L’atelier d’Alvin était articulé autour de la création visuelle de produits. Je sais qu’il le produit régulièrement, j’aimerais bien avoir l’opportunité d’y participer…
The big payoff, par Alexandre Boutin
J’avais eu l’occasion de pratiquer ce jeu lors des premiers Agile Game France. Alex remet le couvert pour ce très bon agile game. Vous pouvez en trouver le descriptif en anglais ici. Et mieux encore le descriptif en Français ainsi que le matériel de jeu sur le blog d’Alex.
Faites Revivre vos spécifications
Un autre sujet orienté BDD issu d’une expérience récente de Yannick. Il m’en avais parlé lors d’un déjeuner, plus tôt dans l’année. Une optique de l’acceptance testing qui diffère un peu de la mienne, mais sans être incompatible (si, si !).
Open Agile Adoption, par Pablo Pernot et Oana Juncu
Encore une session à laquelle j’aurais aimé pouvoir assister si j’avais pu me dédoubler. Too many sessions, so little time…
Ici, Oana et Pablo nous dévoilent (en partie) le framework de Dan Mezik.
Créer le bon produit avec le Lean Canvas, par Romain Couturier
Romain a vécu un ScrumDay mouvementé, avec une panne de sonorisation suivi d’un changement de salle. Ici Romain nous parle du Lean Startup et plus précisément de l’outil de référence développé par Ash Maurya .
Les nouveaux outils du Product Owner
Story Mapping, Impact Mapping, Lean Canvas et Kanban : ce sont les « nouveaux » éléments que nous propose Claude pour le Product Owner.
Agilité : la fin du middle management ? Par Kevin Maccioni et Fabien Barbaud
Avec le passage à Scrum, le retour d’expérience des deux orateurs les amènent à répondre oui !
Introduction to Visual Management, par Natalie Yadrentseva
Je ne suis pas certain de joindre ici le bon support, je l’avoue…
Certains éléments de cette présentation me rapellent furieusement le Lightning Talk d’Igor Sviridenko à l’Agile France 2013…
Devops Game, par Vincent Daviet
Le troisième atelier Zenika de ce ScrumDay nous était proposé par notre nouveau venu Lyonnais avec ce Devops Game que je n’ai hélas pas pu expérimenter.
Podojo : PO, viens t’améliorer par la pratique avec nous ! Par Guillaume Duquesnay et Nicolas Verdot
A défaut d’un support de présentation, voici une petite vidéo avec une interview de Dominique Lequepeys sur cet atelier
Le Product Owner est-il un Product Manager agile ? Par Sébastien Saccard
Sébastien Saccard n’est pas un inconnu pour moi : tout d’abord il fut à l’initiative du workshop d’Ash Maurya à Paris, ensuite en tant que président de l’association We Do Product Management, il fut à l’instigation de la rencontre avec Gojko Adzic hébergée chez Zenika.
Sébastien cherche à développer le métier de Product Manager en France. Sa présentation va dans ce sens.
Vous pouvez aussi retrouver la présentation de Sébastien sur son Blog.
Agile-Lean-Kanban : Le guide du routard 2014, par Christophe Keromen
Bien rodée, j’avais eu l’occasion d’assister à cette très vivante présentation de Christophe à l’Agile Tour Rennes 2013. Mais était-ce réellement la même ?
My Product is a James Bond Movie – part V, par Pierre Neis
Les présentations de Pierre ne ressemblent à rien de connu ! Elles sont difficile à raconter, et je doute que le support ci-dessous lui rende justice. J’avais assisté à la « part I » de cette série « James Bond Movie » lors de l’Agile Tour Bruxelles 2013 … nous voici rendu au 5ème opus !
Développer en mode Kick-Ass, par Samuel Le Berrigaud
Le Kick-Ass de Samuel, cela me fait penser au « programming motherfucker » ! D’ailleurs en fait, il en parle dans sa présentation. Je vous recommande ce support pas mal du tout … en attendant la vidéo !
De la culture projet à la culture produit, par Céline Stauder et Gregory Alexandre
La présentation de Céline et Grégory est tout à fait dans le thème de ce ScrumDay. Par contre le support ne vous permettra guère de saisir la substance de la présentation !
Le prétotyping, avec Elalami Lafkih
Le prétotyping, c’est du prototypage « low cost », plus tôt donc avec un feedback anticipé. Elalami nous en expose un certain nombre de techniques. J’ai repris le support de l’orateur utilisé durant l’Agile Tour. Je suis parti du principe qu’il s’agissait du même…
Kapla Challenge, avec Dragos Dreptate
Construire un pont par itération (avec des Kapla), c’est le challenge que nous propose Dragos durant cet atelier
Faire Agile, c’est bien…, par Aurélien Morvant et Simon Jallais
Simon et l’homme aux chaussures de couleurs différentes nous proposent de découvrir ce qu’est « vivre agile ». Une session plutôt décalée !
DSL et refactoring pour les tests d’acceptation, par Laurent Py
Laurent nous fait partager son expérience ATDD / Devops chez Smatesting. En fait, la session ressemble terriblement à une promotion de l’outil Zest’ qui est, oh surprise, développé par la société dont Laurent Py est CEO !
Bon, voici quand même cette présentation…
Les reportages du ScrumDay
Une petite séquence « fun », tournée en bonne partie durant la pause déjeuner du second jour.
Et le reportage du ScrumDay, avec quelques interviews et des interventions de Xavier Warzee et Alistair Cockburn
Ils en parlent aussi…
Quelques liens vers des articles de blog que j’ai peu glaner à droite et à gauche. Si vous avez d’autres liens, n’hésitez pas à m’en faire part.
Il y avait une Coach Clinic, mise sur pied par Fabrice Aimetti et Bruno Sbille. Côté Zenika, Géry Derbier y participait ainsi que Laurent Sarrazin pour Rupture 21. Un compte-rendu est disponible sur le site d’Ayeba.
Alex Boutin nous livre sur son Blog la manière dont il a vécu ce ScrumDay.
Un retour de Laurent Sorin sur la table ronde menée par Véronique Messager
Autre retour également en provenance d’Ippon, un feedback sur la session de Rachel Davies par Victoria Pedron.
Dominique Lequepeys nous adresse les points forts des sessions auxquelles il a participé. Youpi, ceci inclut la mienne !
Christophe Deniaud fait aussi son billet de Blog sur les sessions qu’il a vu, ainsi que sur l’open-space. Lui aussi donne son feedback sur mon atelier. Pas sûr que mon message principal sur l’écriture collaborative des tests soit bien passé…
Coactiv nous livre aussi ses retours.
97 Things Every Project Manager Should Know
J’avais publié une note de lecture sur cet ouvrage. Il est aussi disponible en eBook. En fait, le texte en licence Creative Commons. Bonne lecture !
La réalisation collaborative de ce texte s’est faite au travers d’un Wiki.
Note de lecture : Software Project Management, par Walker Royce
Note : 6 ; La gestion de projets selon Unified Process.
Un ouvrage un peu dense et un peu difficile à lire, mais dont le contenu est indéniable, notamment sur les métriques de suivi de projet. Walker Royce porte un fardeau assez difficile : son père, Winston, est en effet l’auteur d’un article décrivant le cycle en cascade qui est à l’origine du « cycle en V »… à son corps défendant !
Les 4 parties constituées de 17 chapitres de la partie principale du livre couvrent un peu plus de 250 pages. Il faut y ajouter les très conséquentes 5 annexes de la 5ème partie qui totalisent à elles seules 150 pages !
La première partie « software management renaissance » comprend 4 chapitres et un peu moins de 70 pages. Bien entendu, le premier chapitre traite du modèle en cascade présenté dans l’article de 1970 de papa Royce. Plutôt que de critiquer son géniteur, Walker fustige, à juste titre je dois dire la manière dont le modèle a été mal compris. Le second chapitre, s’il est court avec sa dizaine de page, n’est pas une ballade de santé. Il présente l’évolution de l’économie du logiciel en terme de ROI, coût par SLOC, etc. En comparaison le 3ème chapitre qui présente logiquement l’amélioration de cette économie est nettement plus accrocheur. L’auteur y évoque l’influence de différents paramètres tels que le langage de programmation, l’utilisation de la conception orientée objet ou la pratique du peer review. Cette première partie se conclut par la comparaison des « anciens principes » contre les nouveaux (ceux de l’auteur). J’ai trouvé l’énoncé des 30 principes de Davis bien plus intéressante (même si certains sont clairement erronés), en regard des 10 principes de Royce.
La seconde partie « a software management process framework » rentre dans le dur de UP. 65 pages sur 5 chapitres y sont consacrés. Le chapitre 5 se focalise sur le concept de phase (vous savez, celui que l’on a abandonné avec agile…). Bien entendu ce sont les 4 phases d’UP qui y sont évoquées. C’est sans surprise que l’on aborde le chapitre 6 qui s’avère consacré à la question des artéfacts projet, les 25 pages de se chapitres évoque l’existence de nombre d’entre eux en les ventilant sur 5 pratiques d’ingénierie. Un chapitre que j’ai du mal à trouver passionnant, bien qu’il soit central dans les méthodes prescriptives et finalement bien abordé ici, y compris la discussion sur l’usage et l’apport d’artefacts formels. Les deux chapitres suivants sont étrangement courts. D’abord le chapitre 7 sur les modèles n’évoque que l’existence de 5 modèles (qui rappellent les 4 + 1 vues de Philippe Kruchten), mais sans aller plus avant parce que hors du sujet de l’ouvrage probablement. Ensuite le 8 chapitre 8 nous parle du workflow de l’itération, décrivant celle-ci comme un mini waterfall. Beurk ! Le dernier chapitre de cette seconde partie est plus ésotérique en évoquant les jalons majeurs et mineurs.
La troisième partie « software management disciplines » couvre 85 pages sur 5 chapitres. Il commence avec le chapitre 10 qui aborde la planification itératif et son outil phare : le WBS (Work Breakdown Structure). Encore un truc que l’on ne fait plus en agile. Toutefois si vous voulez rentrer dans le sujet, vous avez là une référence de première main. Non seulement il donne une méthode de découpage, mais évoque les répartitions budgétaires relatives et leur évolution en fonction des phases du projet ! Le chapitre 11 lui traite de l’organisation de projet, au sens « administratif ». C’est donc à des organigrammes qu’il nous faut faire face, avec des listes de responsabilités et tout et tout… Le chapitre 12 focalise sur l’automatisation du processus et notamment du change control. Bref, pas mal d’outillage « projet ». Fort logiquement, au chapitre 13, ce sont les indicateurs de management qui sont à l’honneur et principalement le fameux Erned Value Tracking (EVT). Le chapitre 14 aborde la customisation du processus (car UP se customise). Walker Royce aborde cela en classant les types de projet en 2 dimensions : la complexité technique sur un axe et la complexité de management sur l’autre. Chaque axe nécessite une emphase particulière sur certaines disciplines et certains artefacts. Il n’y a plus qu’à combiner les deux, hein ?
La dernière partie du corps du livre « looking forward » ne compte que 3 chapitres et se contente donc d’une trentaine de pages. Elle débute par le chapitre 15 qui évoque les projets dits « modernes ». C’est finalement là que l’on retrouve des choses qui se rapprochent le plus des projets agiles : des exigences qui évoluent, de l’intégration continue, mais le tout encore et toujours dans les fourches caudines d’XP aux forceps. Au chapitre 16, on tente de tourner notre regard vers un nouveau modèle économique des projets. Il s’agit en partie d’une remise en cause partielle des postulats de Boehm dans le cadre des développements actuels. La partie textuelle de cet ouvrage se conclu par un chapitre 17 assez courts évoquant les problèmes de transition vers ces processus…
La 5ème partie du livre est consacrée aux annexes. Comme je l’ai dit, elle est franchement volumineuse. L’annexe A évoque l’état des pratiques en s’appuyant sur des rapports. Hélas tout ce ceci n’est plus d’actualité, mais cette partie est au moins courte ! L’annexe B rentre dans le modèle COCOMO 2 de Boehm, et on s’en tire pour une vingtaine de pages. Une dizaine de pages sont consacrées à des métriques de changement qui à mon avis ne servent à rien. L’annexe D est un cas d’étude et franchement il faut être motivé pour s’en taper les 60 pages. Enfin, même si l’annexe D compte 30 pages, il est plus facile de s’y intéresser : challenger UP face à CMM peut s’avérer instructif.
Le livre est dense, très dense. Il traite de processus semi-prescriptif est déballant beaucoup de matériel, beaucoup de concepts et un niveau de technicité, en processus, en métriques et un petit peu dans tout, il faut bien le dire, qui est très élevé. Le vrai risque est d’être un peu noyé à force d’en vouloir pour notre argent. L’erreur de l’auteur est d’essayer d’augmenter le niveau de technicité, de finesse dans la maitrise et la gestion de projet, là où la clé serait plutôt la simplification.
Référence complète : Software Project Management: A Unified Framework – Walker Royce – Addison Wesley 1998 – ISBN: 0-201-30958-0
Note de lecture : Surviving Object-Oriented Projects, a manager’s guide, par Alistair Cockburn
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 
