Livre : The Unicorn Project
17 March 2020
The Unicorn Project fait suite au Phoenix Project, publié en 2013. Avec 6 ans d'écart, il reprend la trame romanesque du 1er volume pour présenter l'histoire du point de vue de Maxine, développeur sénior, et en tirer des enseignements plus spécifiquement destinés aux développeurs. Ainsi, les fondements de la culture devOps auront-ils été parcourus par les 2 extrémités, dev et ops.
Avant l'Unicorn, le Phoenix
Le Phoenix Project, qui se plaçait du point de vue des opérations IT, nous a apporté 3 enseignements majeurs nous permettant de mieux coller aux besoins du business et d'apporter de la valeur par la vitesse, l’agilité et la pro-activité. Pour rappel, ces 3 enseignements sont :
- penser en systèmes interdépendants et favoriser la performance du système (l’ensemble, le tout) par rapport à la performance d’un silo,
- pratiquer l'amélioration continue et la correction immédiate des défectuosités du système,
- favoriser la mise en place d'une culture de l’expérimentation continue et de l’apprentissage par l’action.
Vous pouvez retrouver ces principes en détails dans le billet que j'avais écrit lors de la parution du Phoenix Project.
Le Unicorn Project se place donc cette fois du point de vue du développement et à travers l'histoire et le point de vue de Maxine, l'auteur nous éduque sur divers points devOps et finalement tire 5 idéaux :

le 1er idéal : localité et simplicité (Locality and Simplicity)
les systèmes ne doivent pas dépendre de choses externes et doivent rester le plus simple possible. La dépendance à l'extérieur augmente la complexité et ralentit les travaux. Il faut cultiver la simplicité dans le code et les procédures de travail.
le 2ème idéal : concentration, flux & satisfaction (Focus, Flow , and Joy)
dans un objectif de recherche de performance au sens large, tout ce qui peut participer à l'épanouissement des développeurs doit être favorisé : la mise à disposition des bons outils, le retour rapide sur la qualité produite, l'inclusion dans la vue d'ensemble (et non le cloisonnement dans un fragment de code) et l'exploration de nouvelles méthodes et façons de faire.
le 3ème idéal : l'amélioration du quotidien
cet idéal se tourne vers l'amélioration continue des outils et méthodes pour augmenter la productivité et la satisfaction au travail. L'ennemi déclaré ici est "on a toujours fait comme ça"
le 4ème idéal : la sécurité psychologique
le corrolaire à l'amélioration continue et à l'exploration de nouvelles méthodes et façons de faire, est la tranquilité d'esprit pour chacun : les problèmes et les erreurs ne doivent pas faire l'objet de sanctions ni de mise à ban. Les sanctions conduiraient les développeurs à cacher les problèmes, créant ainsi de la dette technique, et à éviter la prise d'initiative, tuant l'innovation.
le 5ème idéal : l'orientation client
cet idéal incite à passer chaque action au crible de l'orientation client en posant la question : "est-ce que ceci est important pour nos clients ? Sont-ils prêts à payer pour cela ou est-ce que cela n'a de valeur que pour nous ?"
Chasse à l'Unicorn
Dans le détail, les enseignements sont plutôt pertinents, avec des discussions sur des sujets tels que :
- la dette technique,
- la nécessité d'environnements de test et développement homogènes pour les développeurs, d'outils qui favorisent la productivité (tests et déploiements automatisés),
- les méthodes de développement modernes : la constitution d'équipes restreintes, concentrées sur un périmètre réduit et disposant d'une certaine autonomie de prise de décision, le découplage des applications, l'imutabilité,
- la nécessité de travailler sur la productivité des développeurs et la recherche de l'équilibre entre le développement de nouvelles fonctionnalités et l'amélioration de la productivité des développeurs par la réduction de la dette technique et l'amélioration des outils,
- la responsabilité du management dans l'organisation des équipes, leurs relations et la nécessité d'un nouveau mode de management qui tient davantage de l'accompagnement bienveillant tendu vers la recherche de la perfection, la satisfaction client et l'innovation.

Cependant, le livre m'a laissé sur ma faim : la forme est un peu lourde, le style semble forcé, "avec des han ! de porteur d'eau" comme l'aurait dit Cyrano, et je me suis ennuyé ferme par moment. Les apparitions (et disparitions) du mentor historique Erik devenu patron de bar pour l'occasion, et qui distille sa sagesse de façon parfois un peu obscure, sont maladroites. On croirait une espèce de Passe-partout de l'informatique.
Bien-sûr, il ne s'agissait pas pour l'auteur d'écrire un roman digne d'un prix Nobel de littérature, mais d'aborder de façon ludique des concepts importants. Et si les enseignements sont globalement intéressants, on peut se demander pourquoi avoir attendu 6 ans pour publier cette version. Il aurait été intéressant de publier les deux livres ensembles, comme les deux faces d'une même pièce, plutôt que d'attendre si longtemps. Avec le temps, le message a perdu de sa force, même s'il garde sa pertinence : dans le monde du développement, le devOps a progressé depuis la révélation du Phoenix Project et les principes énoncés sont maintenant chose acquise. Il reste le sentiment que le livre est né sous l'impulsion de l'éditeur pour continuer à exploiter le filon.
En conclusion, si vous avez déjà mis en place les fondements devOps ou si vous avez déjà lu des livres sur le sujet, passez votre chemin. Pour les autres, c'est une introduction sympatique, mais qui manque de densité : par respect pour votre temps, choisissez un ouvrage qui se passe de la couche romanesque et va droit au but, ils sont pléthore et certains sont très bons.
liens utiles :
- livre « the Unicorn Project » sur Amazon
- the IT revolution, le site lié au livre