Note 3 : Se retrouver à lire un livre que l’on n’a pas envie de lire…

Et ainsi donc, le développement itératif et incrémental est désormais acquis au développement agile ! Tout le développement itératif et incrémental ? Non ! Un village résiste encore et toujours : il s’appelle « spirale de Boehm ». Cet ouvrage est peut-être son chant du cygne, l’avenir nous le dira.

L’ouvrage que nous allons explorer nous présente l’ultime version du modèle en spirale. Il compte environ 250 pages découpés en 16 chapitres, eux-mêmes structurées en 4 parties. Si ces caractéristiques laissent présager une lecture pas trop longue et bien rythmée, c’est sans compter sur l’austérité de la prose ! Il est temps de s’y attaquer. L’introduction permet aux auteurs de positionner le « incremental commitment spiral model » que nous nommerons maintenant ICSM sur le même créneau des méthodes adaptatives que les approches agiles qui sont d’ailleurs citées. Elle ne cherche pas à s’y opposer, mais à se positionner différemment en s’appuyant sur 4 principes sur lesquels nous reviendront. Le but est de se tailler une place dans les environnements plus classiques et « legacy » qui sont quand même prêts à accueillir un cycle itératif. En prime, ce chapitre 0 nous propose une belle vue actualisée du cycle en spirale : l’ouvrage aura ainsi au moins une valeur archéologique !

La première partie compte 4 chapitres sur 80 pages. Ils vont détailler les 4 principes de l’ICSM que nous avons mentionné. Le premier chapitre aborde la question de la valeur pour les parties prenantes. Il s’appuie sur les leçons tirées de 2 histoires, notamment de la conception d’un équipement hospitalier. Ce principe est adossé au « success critical stakeholder » ou SCS. Ce principe est un mélange de modernité (la mesure du succès est le succès du SCS) et de choses plus anciennes avec une approche en phases qui rappelle étrangement Unified Process ! On n’échappe d’ailleurs pas à une matrice critères de succès / parties prenantes ! Au second chapitre, on aborde la notion d’engagement incrémental : c’est le cône d’incertitude qui est mis à l’honneur ici. Cette fois encore le propos est illustré de deux histoires, un succès et un échec, le succès étant le projet TRW débuté en 1978 qui fut à l’origine du cycle en spirale ! Le chapitre fait apparaitre l’approche comme très technocratique et la prose est plutôt lourde. Le volet intéressant de ce chapitre est la comparaison de modèles incrémentaux allant du « prespecified » au « evolutionary concurrent ».

Le 3ème principe que nous découvrons au chapitre 3 est le « concurrent multidiscipline engineering ». Nous avons aussi droit à deux histoires, celle illustrant le succès étant le développement d’un drone. Le propos est alambiqué et assez lourd. Il s’éclaire vers la fin du chapitre quand l’auteur nous déclare que l’utilisateur peut rarement spécifier clairement ce qu’il veut au début du projet et qu’il nous faut donc mener de front l’affinage des besoins, la conception et le développement. Il s’agit bien du fonctionnement multidisciplinaire que nous connaissons en agile. Il est simplement exprimé de manière obscure ici. Le dernier principe est celui des décisions basées sur les risques, le sujet du chapitre 4. Le propos se concentre sur la valeur apportée par les études de faisabilité. L’auteur met aussi en perspective l’approche de Walker Royce intégrée à Unified Process comme étant un progrès par rapport au cycle en spiral initial ! Globalement la coloration « pré-agile » y est assez évidente.

La seconde partie va entrer plus en détail dans le cycle de vie de l’ICSM au « stage 1 » avec 4 chapitres qui adressent chacune des phases précédées d’une introduction, sur une quarantaine de pages. Le chapitre 5 est là pour nous faire découvrir le cycle de vie de l’ICSM. Sur quelques pages, le texte nous décrit et compare le cycle ICSM à d’autres jouant dans la même catégorie tels que DOD 5000 ou… Safe ! La mise en avant des avantages d’ICSM n’est pas terriblement évident même si le propos insiste beaucoup sur le pilotage par les risques ! Au chapitre 6 nous abordons la présentation de la phase d’exploration. La description est plutôt abstraite et méthodologique, mais cependant pas désagréable à lire, d’autant que cette fois aussi, l’ouvrage nous gratifie d’un exemple. Bref, une présentation claire où le pilotage par les risques est aussi décliné de manière spécifique à cette phase !

Au chapitre 7, il est question de la phase d’évaluation qui doit aboutir à un go/no go du projet. Le chapitre est assez court et suit exactement la même structure que le chapitre précédant et il a également droit à un exemple. Il reste d’une lecture confortable, mais le propos lui-même est moins convaincant. Cette seconde partie se referme sur le chapitre 8 qui nous définit la phase de fondation. Comme son nom l’indique, elle est là pour poser les bases de l’architecture et du fonctionnement du projet. Elle sent un peu la poussière et même Unified Process fait mieux.

La 3ème partie compte 2 chapitres sur 35 pages pour évoquer le stage 2. C’est le cœur du développement incrémental. Cela a beau être incrémental, c’est bien d’une phase de développement dont nous parle le chapitre 9. Il n’aborde pas que l’aspect software, mais aussi l’aspect hardware, car l’approche ICSM se veut adapté au développement « système » et non réduit au logiciel. Il y a beaucoup de généralités dans ces pages, et peu d’intérêt. Le chapitre évoque aussi le test. Même si celui-ci se veut incrémental, il reste du test « après coup ». Globalement, même si le chapitre est plutôt court, il présente peu d’intérêt. C’est un problème que rencontrent la plupart des textes méthodologiques quand ils traitent du développement : soit on rentre réellement dans les pratiques auquel ca le propos ne peut pas être frugal, soit on en est réduit aux généralités, voir aux banalités. Le chapitre 10 aborde la production et les opérations. La partie production ignore le devops qui n’en était qu’à ses premiers pas lors de l’écriture de l’ouvrage (pour ne pas parler du cloud qui n’était pas encore mainstream), mais d’un point de vue système, parler d’assemblage et de distribution reste pertinent, surtout dans le monde embarqué. La partie opérations ne dit vraiment pas grand-chose, passons. On a un peu l’impression que ce chapitre est là surtout pour ne pas briller par son absence, nous n’en retiendrons au mieux que peu de choses.

Nous voici arrivé à la 4ème partie, elle aborde la mise en œuvre d’ICSM au niveau de l’organisation. Elle est longue de 5 chapitres sur 60 pages. Le chapitre 11 qui ouvre le bal évoque les patterns de l’ICSM. En fait nous devrions sans doute plutôt parler de profils de projets. Quel que soit le nom qu’on lui donne l’approche est intéressante : elle décrit comment décliner ICSM dans ces différents profils. C’est d’ailleurs l’approche qu’avait adopté Unified Process en son temps ! L’auteur n’hésite pas à embarquer l’approche agile en temps de déclinaison particulière de l’ICSM : c’est gonflé ! L’objectif du chapitre est d’aborder la manière dont ICSM va s’inscrire dans l’organisation. Mais on n’y parle pas vraiment d’organisation, mais plutôt d’emprunter ou réutiliser les pratiques existantes. J’ai vaguement l’impression de lire un dépliant publicitaire me vantant la capacité d’ICSM d’englober toutes les pratiques de développement. Quel intérêt ?

Le chapitre 13 qui va nous éclairer sur « evidence-based lifecycle » a très nettement des odeurs de CMMi. C’est lourd, très lourd. L’objectif est de mettre en place les éléments permettant d’inscrire ICSM dans un cadre de décision d’entreprise basé sur des jalons. Ce n’est pas particulièrement festif, donc. Coût et planification sont au menu de ce chapitre 14. Pourquoi cela figure-t-il au sein d’une partie consacrée à l’organisation ? Mystère ! On y trouve deux éléments principaux : l’estimation, sujet sur lequel l’auteur se repose sur COCOMO, puis la planification qui met en œuvre le développement time-boxé … mais que l’auteur a rebrandé SAIV ! On ne sera bien sûr pas autrement surpris de retrouver COCOMO dont Barry Boehm est aussi le créateur ! Le livre se referme sur le chapitre 15 qui revient sur la gestion des risques, cette fois en l’intégrant dans la notion d’opportunité. Voir les risques sous l’angle de l’opportunité c’est d’une certaine manière l’une de mes dadas ! Mais en fait non : on ne parle pas vraiment d’opportunité mais de contrôle des risques sous tous les angles. C’est plutôt décevant.

Pourquoi donc ai-je lu ce livre dont la philosophie plonge ses racines dans l’ère précédant l’agilité ? Eh bien justement pour cette raison, en quelque sorte archéologique. Au début des années 80, ce que nous proposait Barry Boehm était novateur, mais je commençais tout juste à programmer et ces considérations me passaient au-dessus de la tête (en vérité, je ne savais même pas qu’elles existaient !). Ce livre, même s’il date un peu s’inscrit à un moment où l’agilité qui en est l’héritier est désormais mainstream. ICSM lui, n’a que marginalement évolué et le texte en devient cocasse et même has been. Le second argument est que l’éditeur déstockait ce livre pour faire place nette à un prix très attractif. J’ai donc complété ma bibliothèque avec ce titre à coloration historique.

Référence complète : The Incremental Commitment Spiral Model – Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong & Richard Turner – Addison Wesley 2014 – ISBN : 978 0 321 80822 6