15 Nov 2017, 00:05

The Phoenix Project

Cette année, il y a 2 contenus pour lesquels j’ai eu un effet “Whaou” :

  • Le hacker, ce héros : comment être un bon growth hacker : si le titre est plutôt mal choisi, la vidéo fait réflechir sur la tendance à l’over-engineering que l’on a tendance à appliquer vs “le juste ce qu’il faut quitte à améliorer plus tard” de la startup ou du hacker. Le code généré n’est peut être pas à l’image de l’état de l’art mais il est en production, permet de vendre le produit et d’avoir des retours. Quand on sort d’un grand groupe pour faire des missions dans des petites structures, cela fait définitivement réfléchir.
  • The Phoenix Project : sous la forme d’une fiction, le livre sensibilise à la transition d’une équipe IT puis d’une entreprise vers une démarche DevOps/Lean/Agile mais pas uniquement pour faire face aux défis que doit relever l’entreprise.

Il y a les 3 principes :

  • 1er principe : maitriser le flux de bout en bout depuis la phase de développement jusqu’à la mise à disposition à l’utilisateur. Pour optimiser ce flux, il faut des petites itérations et avoir en objectif un but global à l’entreprise (et non local à l’IT). Par ailleurs, on évite les retours en arrière dans le processus, cela est signe d’un dysfonctionnement. Il faut voir le flux comme uni-directionnel allant du développement vers l’utilisateur. Les pratiqes associées tournent alors principalement autour de l’intégration continue et du déploiement continu.
  • 2nd principe : avoir une boucle de feedbacks permanente permettant de faire de l’amélioration continue. Cela permet d’améliorer la qualité du code source et de créer/formaliser la connaissance autour du projet. La pratique consiste donc à mesurer/évaluer les différentes étapes et à les faire évoluer au fur et à mesure.
  • 3ème principe : créer une culture qui permet l’expérimentation en permettant la prise de risque & des apprentissages rapides d’une part et d’autre part en considérant que la répétition et la pratique sont requis pour avois plus de maitrise et de confiance dans le process.

Il y a 4 types de travail dans l’IT :

  • Les projets métiers,
  • Les projets internes à l’IT
  • Les changements
  • Le travail innatendu (incidents, activité non planifiée, etc)

Il y a alors 4 enjeux :

  • Identifier et rendre visible ces 4 types de travaux afin de pouvoir s’organiser, estimer son travail et planifier en conséquence,
  • Garder le contrôle / Maitriser le travail innatendu vu qu’il est le plus perturbateur et apporte le moins de valeur. Quand on travaille sur ce travail innatendu, on perd du temps sur les 3 autres types de travaux.
  • Identifier le “Work in process”, à savoir le travail en cours et qui mobilise alors tout ou partie de la chaine de travail. Les analogies avec la gestion d’une usine permettent d’avoir une meilleure vision des choses et rendre nos flux IT plus concrets.
  • Identifier les contraintes et faire en sorte de les réduire/lever.

On retrouve également le thème habituel des démarches Agiles/Lean/DevOps avec tout le travail autour de la notion de valeur pour l’entreprise et pas uniquement pour la partie IT. Il faut se concentrer sur des éléments apportant de la valeur, de petite taille pour ne pas bloquer la chaine et pouvoir être envoyer en production rapidement. Le livre montre également des contre-exemples comme des contraintes de sécurité que l’équipe cherche à s’imposer alors que le risque d’une part est géré par ailleurs (autres départements) et qu’appliquer des correctifs n’apporte aucune valeur à l’entreprise d’une part et d’autre part compromet sa capacité à avancer.

Une statistique intéressante est celle du temps d’attente d’une personne (time wait) : elle rapporte le temps d’occupation au temps de disponibilité d’une personne. Si une personne est dispo à 5050, le taux est de 1 et il faut attendre 1 unité de temps pour qu’elle fasse la tâche dont vous avez besoin. A l’inverse, une personne occupée à 90% a un taux d’attente de 9 unités de temps. Même si la réalisation de la tâche par cette personne est rapide, il vous faudra attendre 9 unités de temps pour qu’elle le fasse. On crée et identifie alors rapidement des goulets d’étranglements dans votre process de création de valeur qu’il faudra traiter. Pour bien donner l’idée, si un process requiert l’intervention de 7 personnes occupées à 90% du temps, il faudra alors 63 unités de temps pour réaliser l’action.

Au final un livre rapide et agréable à livre. Vous pourrez avoir la sensation que le livre raconte votre project actuel (ou des projets passés) à de nombreuses reprises. Vous pourrez alors évaluer les progrès de votre entreprise au regard des transformations opérées dans le livre et voir si vous êtes en phase ou pas.

Plus que juste l’approche DevOps/Lean/Agile, ce que je retiens de ce livre, c’est surtout l’effort d’alignement de l’IT avec les besoins du reste de l’entreprise et que l’on oublie souvent d’une part et d’autre part les analogies avec le monde de l’usine. Nous considérons parfois à tort que l’IT n’a rien à voir avec une usine et l’on voit bien ces dernières années que cela est faux et que le monde industriel peut nous apprendre énormément de choses et nous faire gagner un temps précieux et ainsi être plus performant et au service des besoins de l’entreprise.