Accueil Expert La réalité de la formation d’une équipe DevOps réussie

La réalité de la formation d’une équipe DevOps réussie

Anupama Rathi
Anupama Rathi, Associate Vice President, Head of DevOps COE chez Infosys

AVIS D’EXPERT – Pour Anupama Rathi, Associate Vice President, Head of DevOps COE chez Infosys, c’est un fait : il est aujourd’hui crucial de fusionner les équipes de développement et d’exploitation en équipes DevOps unifiées, afin de mieux collaborer pour une mise en production rapide des applications. Mais en réalité, depuis près d’une décennie, l’adoption DevOps s’est surtout concentrée sur l’automatisation de l’ingénierie pour développer des pipelines CICD pour les applications. La création d’équipes DevOps unifiées est donc passée au second plan.

Rétrospectivement, c’était probablement la bonne approche pour cette période car, sans
automatisation de bout en bout, la vitesse des versions n’était pas vraiment assez élevée pour exiger la fusion des équipes Dev et Ops. En travaillant par itérations agiles, la taille des versions a été réduite, mais les activités manuelles et les transferts ont encore entraîné des cycles de publication plus longs. Plusieurs cycles de sprint agiles ont ensuite été regroupés pour former une version finale. Finalement, comme les versions n’étaient pas plus rapides, les équipes de développement et d’exploitation n’avaient pas besoin de collaborer fréquemment – et le besoin de casser les silos entre les deux équipes n’était pas si pressant.

Néanmoins, avec l’automatisation du CI/CD et, dans certains cas, avec une automatisation
extrême, l’augmentation de la vitesse des versions est devenue une réalité. La fréquence des versions est passée d’une fois tous les neuf mois, à une fois par semaine, voire plus rapidement, à la demande. Ces applications à grande vitesse doivent dorénavant tenir compte des défis fréquents que pose le passage du développement à l’exploitation pour prendre en charge les nouvelles versions. Une pression s’exerce sur les équipes d’exploitation pour maintenir les mêmes niveaux de service en production, malgré le flux des versions fréquentes. La fréquence croissante des mises à jour d’applications plaide en faveur d’équipes DevOps réunies.

Les défis de la formation d’une équipe unifiée et comment les relever

Cependant, créer des équipes unifiées n’est pas aussi simple que de faire asseoir Dev et Ops autour d’une table et de les intégrer comme une seule et même équipe. Il faut tenir compte de certains éléments clés pour former des équipes DevOps unies réussies. Tout d’abord, à moins d’un effort explicite en faveur d’un changement de culture et d’état d’esprit, les Dev et Ops n’effectuera pas leurs tâches respectives avec le même engagement. Et c’est normal. Un changement d’état d’esprit est nécessaire pour faire évoluer leurs consciences, en les informant de l’objectif global et final. Un excellent « coach DevOps » accompagne ce changement d’état d’esprit grâce à des techniques telles que l’habilitation, les interactions avec les entreprises, la mise en place d’indicateurs clés de performance et de mesures communes à l’ensemble de l’équipe, et la suppression de toute mesure de performance pour les tâches individuelles de Dev ou d’Ops.

Deuxièmement, le « coach DevOps » doit être soutenu par un changement organisationnel : un propriétaire de produit commun doit être identifié pour une équipe DevOps unifiée. Le
propriétaire du produit qui comprend l’importance des tâches Dev et Ops et qui peut donner la priorité à l’une par rapport à l’autre en fonction des besoins de l’entreprise joue alors un rôle crucial dans l’équipe. Sans un tel propriétaire de produit commun, il y aura toujours un défi de priorisation des tâches, et les équipes continueront à jouer des rôles individuels de Dev ou d’Ops.

Troisièmement, il ne suffit pas de former une équipe en combinant Dev et Ops pour obtenir
une équipe de professionnels DevOps. Les Dev et les Ops nécessitent de croiser leurs
compétences par le biais d’une approche de formation très structurée. Il ne s’agit pas
simplement d’apprendre à un développeur comment effectuer des tâches d’exploitation et vice versa. Les développeurs auront également besoin d’une formation complète sur les processus de support, les accords de niveau de service, l’analyse des problèmes et le dépannage. Plus important encore, ils doivent avoir une connaissance plus large du domaine et du système pour localiser et résoudre certains problèmes. De même, il ne s’agit pas seulement de permettre aux membres des opérations de coder, car il existe différents niveaux de soutien opérationnel, comme L1, L2 et L3, qui ont leurs propres niveaux d’expertise en matière de codage. Le « coach DevOps » doit créer un plan pour chaque niveau de soutien aux opérations, avec la possibilité d’ajouter progressivement des activités de développement. Par exemple, le personnel de soutien de niveau L3 peut probablement se mettre au codage très rapidement et commencer à contribuer aux user stories. Mais une personne de niveau L2 ne peut se lancer immédiatement dans les user stories. Il est donc préférable d’établir un parcours d’apprentissage progressif, qui permette d’abord de travailler sur des tâches de niveau L3, puis sur des user stories. Un bon coach DevOps peut créer de tels parcours d’apprentissage personnalisés et un plan de rôles/de responsabilités pour s’assurer de la pérennité de l’équipe.

Enfin, s’il semble plutôt simple d’établir un plan de formation sur papier, il est plus complexe de trouver du temps pour que les équipes Dev et Ops – très occupées – acquièrent de nouvelles compétences et travaillent sur d’autres tâches – tout en ayant aucun impact sur leur productivité. Par où commencer ? Devenons-nous déprioriser certaines des user stories des développeurs ? Et leur demander de contribuer aux tâches d’Ops ? Afin que les Ops disposent de la bande passante nécessaire pour acquérir des compétences en codage ?

S’appuyer sur un bon coach DevOps permettre de prendre des décisions contextuelles pour créer une bande passante suffisante afin que les équipes acquièrent des compétences croisées avec un impact minimal sur l’entreprise.
Si nous pensions que l’automatisation de l’ingénierie CI/CD était la partie la plus complexe de l’adoption de DevOps, ce n’est finalement pas le cas. La transformation des collaborateurs a toujours été un sujet très subjectif et ne s’accompagne pas d’une formule magique prédéfinie. Former des équipes DevOps est beaucoup plus facile à dire qu’à faire. Mais en accordant une attention particulière à la manière dont ces équipes sont créées, sous la direction d’un coach DevOps compétent, nous pouvons drastiquement amplifier les avantages DevOps pour toute application.