Pour aider à définir le contexte de ces points de départ, je dois d'abord tenter de donner une définition de "DevOps" et de l'objectif qu'il vise. Le mot "DevOps" est un mot-valise formé à partir des mots "Development" et "Operations". Il est né de la prise de conscience que les "Devs" et les "Ops", bien que normalement séparés, devaient collaborer plus étroitement afin d'accroître la valeur qu'ils apportaient au reste de l'entreprise. Pour parvenir à cette collaboration plus étroite, de nombreux principes de base de la fabrication physique ont été appliqués avec beaucoup de succès. Cela a conduit à un changement de paradigme, car la valeur commerciale a été fournie de manière cohérente à un rythme toujours plus élevé, permettant aux entreprises qui ont intégré les principes et les pratiques DevOps dans leur travail quotidien de "gagner sur le marché".
Donner des petits pas pour chaque partie de l'organisation typique conduirait facilement à un article trop long et sortirait rapidement de mon domaine d'expertise. Pour éviter cela, j'ai identifié trois personas typiques avec lesquels j'ai travaillé et je donnerai les points de départ pour chacun d'entre eux. Il s'agit du contributeur individuel, du chef d'équipe et du manager.
Les personas
Le contributeur individuel est la personne dont le travail quotidien apporte une valeur ajoutée à l'entreprise. Il peut s'agir d'un développeur de logiciels, d'un administrateur de systèmes ou d'un testeur d'assurance qualité. Pour cette personne, je recommanderais de commencer par automatiser son environnement de développement. Assurez-vous qu'il peut être mis en place de manière cohérente et répétée, et qu'il imite l'environnement de production. Soyez attentif à ce qui rend la mise en place de l'environnement pénible et génère du travail non planifié. Ces difficultés sont le signe d'améliorations qui pourraient être apportées au produit et au processus de développement du produit. Souvent, ces améliorations permettent de s'assurer que leur travail répond à l'idéal de localité et de simplicité, ce qui conduit l'équipe à être plus heureuse et plus productive.
Le chef d'équipe est la personne dont le travail quotidien consiste à fournir des conseils techniques aux différents contributeurs de l'équipe. Pour cette personne, je recommanderais de commencer par définir les étapes nécessaires pour faire passer le code de la validation à l'utilisation par les clients, la durée de chaque étape et le nombre de personnes nécessaires pour accomplir chaque étape. Cela permet de s'assurer que l'équipe est toujours consciente des opportunités d'améliorer le travail quotidien et de communiquer aux responsables lorsque l'équipe est sur le point de se heurter à un obstacle afin qu'il puisse être éliminé avant qu'elle ne l'atteigne, ce qui permet un flux continu de valeur pour le client et un resserrement constant de la boucle de retour d'information.
Le manager est la personne dont le travail quotidien consiste à coordonner la direction de plusieurs équipes et à les maintenir dans l'alignement. Pour cette personne, je recommanderais d'examiner l'un des produits de son portefeuille dans le but de communiquer et de clarifier l'impact qu'une transformation DevOps aurait sur les personnes travaillant sur le produit. Si cette communication est bien faite, les équipes comprendront comment les objectifs de la transformation DevOps s'alignent sur les objectifs du produit et quand signaler qu'elles se heurtent à un obstacle à la réalisation de ces objectifs et qu'elles ont besoin de l'aide du manager pour le résoudre. Cela renforce la sécurité psychologique, qui est incroyablement importante (mais pas suffisante) pour garantir que les membres de chaque équipe sont satisfaits des produits qu'ils livrent. Cela a pour effet d'enchanter les clients grâce à une livraison de plus en plus rapide de la valeur.
Ces étapes ne suffiront pas à elles seules à provoquer une transformation DevOps, mais elles permettront d'entamer le voyage et, espérons-le, d'obtenir des résultats rapides. Toutefois, je me dois d'émettre une mise en garde, que je pense pouvoir illustrer au mieux par une histoire.
Apprendre une nouvelle compétence est difficile
Ma femme et moi aimons emmener nos filles au parc. L'une d'entre elles, à l'âge de la petite enfance, refusait de marcher complètement seule. En même temps, elle adorait descendre les toboggans, surtout quand je l'attendais en bas. Elle atterrissait en bas sur ses pieds et levait les bras, attendant que je la prenne. Après avoir fait cela plusieurs fois, j'ai eu une idée soudaine et j'ai reculé d'un pas ou deux du bas du toboggan et j'ai tendu les bras. Elle est descendue et a atterri sur ses pieds. Elle s'est ensuite mise à trottiner vers moi tandis que je commençais à marcher à reculons en tendant les bras. Environ cinq pas plus loin, elle s'est arrêtée et a commencé à pleurer, non pas parce qu'elle pensait que je la fuyais, mais parce qu'elle avait soudain réalisé qu'elle faisait ce qu'elle pensait ne pas être prête à faire. Après quelques autres sorties au parc cette semaine-là, elle a finalement acquis suffisamment de confiance et de volonté pour marcher seule.
Cela se produit également dans le cadre de DevOps. Au cours de la phase initiale, l'équipe commence à être performante, puis se heurte à un mur parce qu'elle n'est pas encore compétente ou parce qu'elle se heurte à des vents contraires politiques et doit ralentir pour y faire face. Cette frustration peut conduire à ce que DevOps soit perçu comme une nouvelle mode qui ne change rien. Parfois, il faut surmonter la frustration et reconnaître que les avantages pour tout le monde valent le temps et la peine d'apprendre à bien faire les choses au sein de l'équipe et de l'organisation.
Une dernière remarque
Chaque parcours DevOps vise à rationaliser la fourniture de valeur au client d'une manière qui profite à tous ceux qui sont impliqués dans le processus. Pour que tous en profitent, nous devons nous assurer que nous apprenons toujours, non seulement sur le besoin tel qu'il est donné, mais aussi sur les sources de ce besoin, de sorte que l'entreprise traite le vrai problème plutôt que le problème apparent. Il n'y a rien de plus démoralisant que de découvrir qu'un voyage ne s'achèvera jamais parce que les vrais problèmes ne sont pas abordés. Lorsque le besoin d'un client est satisfait et qu'il disparaît, le parcours visant à répondre plus efficacement à ce besoin est terminé. En apprenant continuellement du client et en rationalisant pour répondre à ses besoins, l'entreprise sera en mesure de pivoter et de changer pour répondre à de nouveaux besoins, sinon elle disparaîtra avec l'ancien besoin. Un tel pivot ne peut se produire que si l'entreprise a un objectif plus élevé que celui de simplement gagner de l'argent en répondant aux besoins du client. Cet objectif supérieur ne pousse pas seulement le collaborateur individuel, le chef d'équipe et le directeur à atteindre de plus hauts niveaux d'excellence. Il peut également orienter la direction que prennent les clients dans leur propre parcours et que nous suivons tous. L'examen de ce parcours plus large n'entre toutefois pas dans le cadre de cet article. Bonne chance et que Dieu vous accompagne dans votre périple DevOps. Si vous avez besoin d'aide ou de plus d'informations, n'hésitez pas à nous contacter, n'hésitez pas à nous contacter! Improving peut vous aider à démarrer ces petits pas.
*Un grand merci aux auteurs de DevOps Handbook, Project to Product, et Sooner, Safer, Happier. Sans eux, je n'aurais pas eu le vocabulaire nécessaire pour écrire cet article.
