C’est une histoire fictive, mais qui traite de problèmes bien réels. Il s’agit de la manière dont une entreprise, représentée par son équipe dirigeante, tente de se sauver. Le « Projet Phénix » est un produit de cette entreprise qui ne peut plus fonctionner comme avant. Les concurrents lancent rapidement de nouvelles fonctionnalités, alors que l’équipe actuelle met beaucoup de temps à sortir ses versions. Après ces sorties, le produit cesse souvent de fonctionner correctement pour de nombreux utilisateurs, en raison d’une faible qualité et de tests d’intégration insuffisants.
Conscients de la nature du problème, les managers essaient par tous les moyens de rectifier la situation, mais au début, rien ne fonctionne et la situation empire. Il y a une forte dépendance à certains ingénieurs clés, dont l’absence complique la maintenance des projets ainsi que la publication des nouvelles versions. Les dettes techniques constituent aussi un problème important, qui ne fait que s’aggraver avec le temps.
Avec le temps, l’équipe commence à adopter de nouvelles approches, notamment en matière de tests et de déploiement, ce qui donne des résultats positifs. Désormais, ils n’ont plus de dettes techniques, et les sorties peuvent se faire quotidiennement. Pour éviter trop de spoilers, je me limite à un résumé très bref, et je me concentre sur certains autres messages du livre.
La technologie DevOps avec des solutions CI/CD complètes est excellente en soi. Cependant, l’implémentation des outils seule ne suffit souvent pas à apporter un grand bénéfice au projet. Oui, cela permet de développer rapidement du code, de le tester et de le livrer aux utilisateurs. Mais pour que le produit soit demandé et que le cycle de développement soit le plus efficace possible, il faut changer fondamentalement les approches en matière de communication et d’amélioration des processus entre départements. Ce problème est soulevé en filigrane (parfois ouvertement) tout au long du livre. Toute la construction des processus DevOps est discutée avec les questions de motivation, de bureaucratie et d’autres nuances. Certaines de ces nuances sont extrêmement indésirables et nuisibles. On peut aussi observer, tout au long du livre, comment les relations inter-équipes évoluent avec la mise en place des processus de développement et de livraison du produit jusqu’au consommateur final.
En somme, c’est un livre intéressant et facile à lire. Il sera utile à ceux qui veulent se détacher un peu du travail sans s’éloigner trop du domaine IT. De plus, pour beaucoup de managers et de cadres, il serait utile pour comprendre quels problèmes peuvent survenir en cas de mauvaise approche ou mauvaise organisation des processus, ainsi que la manière dont tout cela peut et doit être changé.
