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.

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 :

1. penser en systèmes interdépendants et favoriser la performance du système (l’ensemble, le tout) par rapport à la performance d’un silo,
2. pratiquer l'amélioration continue et la correction immédiate des défectuosités du système,
3. 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 :

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.

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.

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 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.

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.