Microsoft

DevOps Étude de cas Dojo InnerSource

Résumé

Une fois fait correctement, InnerSource est l’un des moyens les plus efficaces pour libérer la valeur piégée dans l’entreprise. InnerSource n’est pas seulement pour le code source, il peut être utilisé pour n’importe quel contenu, y compris les ventes, préventes, marketing, solution, livraison ou éducation dans votre organisation.

Microsoft pratique InnerSource au sein des groupes de produits pour développer le code depuis plus de 5 ans avec des poches précoces de collaboration cross team sur le code en remontant à bien plus d’années. Dans la chaîne des efforts de collaboration, le Dojo DevOps au sein de Microsoft Professional Services est l’un des groupes les plus récents à utiliser InnerSource, cette fois, pour créer du contenu en collaboration.

Lire la suite pour savoir comment Microsoft-S DevOps Dojo a utilisé InnerSource pour les aider :

• Résoudre le problème d’avoir de nombreuses copies divergentes du contenu orienté vers le client, au lieu de créer une source unique de vérité, pour les ressources utilisées dans la livraison de leurs masterclasses DevOps
• Autonomiser une communauté mondiale des praticiens DevOps et des consultants Microsoft pour s’engager dans la co-création des actifs, asynchrone, accessoire à leur travail de jour
• Permettre aux membres de l’équipe de intégrer les commentaires des clients améliorer le contenu en direct avec les clients et l’avoir propagé rapidement à l’ensemble de l’organisation
• Développer les compétences dans les domaines de la communication, de la documentation et de l’édification communautaire qui ont mené à l’épanouissement personnel, au succès professionnel et aux promotions
• Construire personnelle profonde et durable des connexions à travers le monde.

Historique

L’ingénierie Microsoft a connu une transformation massive au cours des dernières années : de la mise en service d’un logiciel emballé en 2014 à son déploiement en production 82 000 fois par jour en 2019, et aujourd’hui 5,6 millions de fois par mois. Les clients demandaient naturellement : « Comment cela s’est-il produit ? » et « Quel est le secret en coulisses ? » Un groupe de Microsoft Professional Services (désormais Microsoft Industry Solution) a décidé de relever ce défi et de partager avec les clients les enseignements tirés par Microsoft de la pratique d’InnerSource. L’initiative DevOps Dojo a débuté au début de 2019. DevOps Dojo est une communauté de pratique de Microsoft. Elle a commencé avec un petit groupe de bénévoles de l’organisation Services, puis s’est étendue à la Succès client, Conseils numériques, Groupes de produits et autres organisations. Toute participation est volontaire et se fait à côté de leurs principales priorités professionnelles. C’est une communauté où les équipes interfonctionnelles pratiquent les principes agiles, de collaboration continue et d’automatisation de DevOps pour trouver le meilleur moyen de livrer des logiciels de l’idée à la production avec qualité. Il comprend un ensemble diversifié de participants à travers les rôles, les niveaux d’expérience et les géographies, tous travaillant pour apprendre ensemble et partager ces apprentissages avec les clients de Microsoft.

Problèmes à résoudre

Lorsque DevOps Dojo a commencé l’IP cross-fonctionnel était une source fermée. Cela posait un problème. Les équipes travaillaient avec des technologies qui venaient de sortir, avec des outils encore en bêta. Le contenu de base était constamment mis à jour par les groupes de produits. Les liens avec les ressources et les rapports devaient être régulièrement mis à jour.

Chaque membre du Dojo créerait souvent sa propre copie locale pour personnaliser ou mettre à jour pour les clients. Il y avait une prolifération de versions du contenu, légèrement différentes les unes des autres : Il n’y avait pas de source unique de vérité. Des mises à jour globales n’ont pas pu être publiées facilement, et les commentaires des clients sont restés avec le membre Dojo le plus proche du client.

Michael Watson, Architecte de Microsoft, a développé sur la question : le Dojo DevOps est une collaboration de plus que le personnel de Microsoft. Nous réunissions des gens pour parler de ce sujet. Même si nous avions un point de vue, beaucoup des gens que nous avons engagés avaient des années d’expérience. Nous voulions apprendre les uns des autres et nous tenir au courant de ce qui se passait dans l’industrie.

En contemplant le problème, l’un des membres du Dojo, Alvaro Guadamillas, s’est souvenu : « J’ai vu tellement de contenu étonnant créé par la communauté DevOps Dojo que dès le premier jour j’ai ressenti le besoin de rendre ce contenu aussi ouvert que possible à tous. Après deux mois d’appartenance à la Communauté Dojo, j’ai eu assez de confiance pour partager une idée : Pourquoi ne faisons-nous pas DevOps Dojo content InnerSource ? Pourquoi ne pas appliquer les demandes de tirage à la création du contenu et collaborer à l’échelle pour avoir le plus récent et le plus grand contenu disponible pour tout le monde à Microsoft? Pourquoi n’évitons-nous pas d’avoir plusieurs copies de la même présentation distribuée partout et d’avoir une seule source de vérité à la place? Si l’on examine comment elle a relevé leurs défis et si l’on considère qu’il existe déjà une communauté mondiale de InnerSource pour les aider dans leur cheminement, il a été convenu qu’ils expérimenteraient une approche de InnerSource. Compte tenu de l’impact culturel de InnerSource, l’équipe a décidé de piloter d’abord InnerSource sur un sous-ensemble de la solution Dojo DevOps. Avec le soutien de la communauté Dojo, y compris l’équipe d’ingénierie Azure DevOps et l’expertise de GitHub, ils ont créé le premier pilote InnerSource dans les services professionnels Microsoft.

Fondations et mise en œuvre

L’une des premières mesures prises par l’équipe a consisté à obtenir des conseils d’experts pour les aider dans leur voyage. Ils ont appelé Natalie Bradley de GitHub qui avait une expérience importante dans la collaboration avec les organisations pour les aider dans leur voyage InnerSource. Avec l’aide de Natalie, l’équipe s’est mise à mettre en place toutes les politiques et processus appropriés pour aider l’équipe. Tout le contenu a été stocké sous forme de fichiers de balisage dans GitHub et le Dojo a communiqué jour après jour par l’intermédiaire des canaux communautaires sur les équipes Microsoft.

Figure 1: InnerSource au Dojo DevOps au Microsoft

L’équipe s’est concentrée sur la prestation d’une expérience transparente pour les contributeurs. Ils ont également veillé à clarifier la gouvernance, notamment en nommant qui était responsable de chaque domaine et comment ils régleraient les différends qui pourraient survenir.

Dès le premier jour, l’équipe savait qu’il serait essentiel de pouvoir suivre et célébrer les contributions et l’utilisation de leurs résultats. Par conséquent, la configuration initiale incluait également des mesures autour des téléchargements ainsi que le suivi du nombre et de la source des demandes de tirage.

Lors de la conception du Dojo DevOps, l’équipe n’a pas pensé au Dojo simplement comme un programme à court terme. Ils croyaient que le Dojo était un programme de transformation pour les clients internes de Microsoft et de Microsoft. Ils ont adopté un modèle axé sur le produit par le biais d’un processus et d’une approche de produit. Vous pouvez en savoir plus sur l’approche de produit maigre dans leDevOps blog Dojo.

Une source unique de vérité – délivrée

En quelques mois, l’équipe de base initiale avait un produit minimum viable (MVP) en marche. Le contenu des masterclasses était transmis à la communauté de façon à être constamment à jour. Les laboratoires et les instructions pour la livraison des laboratoires ont été créés et mis à jour de la même manière.

Comme l’a décrit Harleen Kaur, consultant technique chez Microsoft : « En tant qu’entraîneur, je me préparais à chaque session, et si je voyais un lien ou une référence qui devait être changé, mon premier instinct était de le faire sur le site Web, de sorte que tout le monde bénéficierait du changement. J’ai pu le faire en ce moment. Si je pouvais, j’aurais peut-être oublié de revenir plus tard pour le faire.

L’équipe centrale a alors commencé à tenir des sessions régulières pour aider à diffuser le mot. Ils ont montré le contenu disponible et comment l’équipe pouvait l’utiliser, ou encore mieux y contribuer. Ils ont fait des jeux de rôle en direct pour démontrer comment les différents rôles de InnerSource fonctionnaient, et même des modifications en direct du contenu sur les appels afin que les gens puissent voir comment le processus d’examen et d’approbation fonctionnait et à quel point il était facile. Dans le cadre de ce processus, ils ont également identifié différents défis et expériences des clients à intégrer.

La participation et les contributions se sont rapidement répandues dans le monde entier. Le Dojo dispose actuellement de plusieurs unités d’affaires travaillant ensemble dans 36 pays pour fournir le contenu le plus récent et le plus précis aux clients de Microsoft.

Deep Mehta, consultant en technologie chez Microsoft a partagé : la réutilisation IP est quelque chose que nous avons toujours voulu fournir, mais dans le passé, c’était un défi. InnerSource nous a aidés à le faire. De plus, nous encourageons ceux qui réutilisent le contenu à aider en contribuant. InnerSource vous aide également à établir un réseau avec les gens autour de l’organisation. Vous apprenez à connaître les contributeurs; vous apprenez d’eux. C’est un point majeur.

Dave McKinstry, Microsoft-S DevOps FastTrack Program Manager, a ajouté : Ce que j’ai remarqué du point de vue de l’ingénierie, c’est que lorsque vous ouvrez votre code source, la qualité monte intrinsèquement. Les gens veulent améliorer les choses.

Innovation activée

Avec l’utilisation accrue du contenu de DevOps Dojo, l’équipe a réalisé que des outils supplémentaires pourraient aider les utilisateurs à connaître le contenu. Ils ont été inspirés à mettre en œuvre un QnA Chatbot pour améliorer l’expérience pour les utilisateurs du contenu.

Le chatbot permet à la communauté Dojo de demander n’importe quoi dans leur canal d’équipes communautaires soutenu par les robots AI et QnA Maker (un service cognitif Azure). En plus de fournir des réponses en temps réel avec un soutien linguistique, la solution améliore organiquement les questions et les réponses de la communauté. Intégrée avec de puissantes capacités d’IA, la solution est conçue pour aider Dojos à obtenir rapidement des réponses liées au contenu, à la préparation, aux offres et à la livraison de Dojo dans un style conversationnel dans les équipes Microsoft.

Une fois que les exigences ont été définies et que l’équipe a bien compris l’architecture d’intégration, elle a commencé la mise en œuvre par InnerSource. Le QnA Bot est devenu public à Microsoft comme prévu. Toutes les améliorations et contributions se produisent par un processus InnerSource et peuvent rapidement prendre effet par des pipelines d’automatisation.

Yue Sheng, qui a travaillé sur l’IA Chatbot en dehors de ses responsabilités professionnelles de base, a partagé : « Vous avez des mentors, des enseignants et des amis ici. Tout est un processus bidirectionnel. Nous essayons toujours de nouvelles innovations. Je reçois de nouvelles choses intéressantes à travers le processus.

Comme Kan Tang, l’un des dirigeants de DevOps Dojo l’a fait remarquer : – Chez Microsoft, nous avons tous notre objectif professionnel. Parfois, vous voyez quelque chose que vous voulez essayer en dehors de vos responsabilités fondamentales. Les gens viennent à DevOps Dojo, et ils ont l’autonomie pour expérimenter et innover. « 

Apprendre par InnerSource

Grâce à leur pratique de InnerSource, la communauté Dojo a également noté que la publication de leur contenu par InnerSource a créé une merveilleuse opportunité d’apprentissage. InnerSource exige qu’une équipe capture et documente tout afin que l’équipe puisse collaborer asynchronement et ne pas compter sur une proximité physique étroite. Comme l’a fait remarquer l’équipe : l’écriture vous fait penser, la pensée vous fait réfléchir, la réflexion vous fait délibérer, la délibération vous fait apprendre plus profondément.

Dans notre écriture, nous nous défions constamment, nous apprenons les uns des autres, et nous itérerons collectivement, a commenté Kitty Chiu, DevOps Architecte chez GitHub.

Pour moi, ce qui m’a fait rejoindre l’équipe était le concept de partager du contenu et d’apprendre de différentes parties du monde et de différents rôles. Nous avons toujours partagé des idées et des points de vue différents. C’est un véritable enrichissement, une conversation qui a apporté beaucoup de valeur, a partagé Giulia Cupani, Azure Program Manager.

Connexions mondiales

L’équipe DevOps Dojo est distribuée dans le monde entier. Cela présente de nombreux défis tels que les contraintes de fuseau horaire ne permettant pas à toute l’équipe de se rencontrer ensemble. Kitty Chiu, basée en Australie, a décrit comment le processus de InnerSource et de se concentrer sur la création de contenu leur a permis de s’engager de manière transparente dans le processus : -Avant la pandémie, la culture Microsoft impliquait habituellement des rencontres en personne. C’était un défi si vous travaillez dans un fuseau horaire différent. Nous devions souvent nous rendre à Seattle pour collaborer à des projets comme celui-ci. Lorsque la pandémie de Covid-19 a frappé, la notion de communication asynchrone est devenue la norme. InnerSource était l’endroit où les conversations ont commencé. Tout le monde pourrait contribuer de la même façon, peu importe où il était assis dans le monde. .Margarita Sanz, DevOps et Cloud Consultant chez Microsoft, ont également partagé comment InnerSource a permis à l’équipe de développer un objectif commun à l’ensemble de l’équipe mondiale : . L’équipe est passée de Chine à Madrid, en passant par l’Inde et la Suisse, vers plusieurs fuseaux horaires aux États-Unis, etc. Des fuseaux horaires différents, des langues différentes, des origines différentes, mais le même but, et surtout la même CULTURE.

Client premier

Microsoft parle souvent d’une culture du client d’abord. Dans ce cas, l’équipe de DevOps Dojo a démontré comment l’approche InnerSource pour la création de leur contenu a non seulement permis à son client de recevoir le contenu le plus récent et le plus à jour, mais également permis au client de s’engager dans le processus de mise à jour.

Les équipes livrent leurs masterclasses directement aux clients. Paul Fijnvandraat, consultant principal chez Microsoft, a partagé que si un client avait des commentaires ou une question à répondre (en prévente ou en livraison), il a créé une demande de tirage pour que la question et la réponse soient ajoutées au contenu du Dojo DevOps. De cette façon, les commentaires des clients se sont propagés presque immédiatement à l’ensemble de l’organisation.

Impact pour l’équipe

Le DevOps Dojo offre une valeur significative à Microsoft et à ses clients. Cependant, en parlant avec l’équipe DevOps Dojo, un avantage supplémentaire est l’impact incroyable sur les participants individuels.

Beaucoup de membres du Dojo ont été officiellement récompensés et promus en raison de son énorme succès, mais il semble que la plus grande récompense de tous était encore plus personnelle. Les membres du Dojo ont indiqué qu’ils avaient noué des relations étroites entre les régions et qu’ils avaient acquis de nouvelles compétences et des expériences d’apprentissage incroyables. Margarita Sanz décrit :

Je sais par coeur trouver une équipe où vous vous sentez soutenu, et valorisé n’est pas facile, et même si le chemin n’a pas toujours été lisse, je le remarcherais sans doute. Nous n’étions pas une équipe, nous étions amis, nous travaillions en famille côte à côte. Le jour où j’ai rejoint Dojo, j’ai senti que je rejoignais une nouvelle famille. Aujourd’hui, je développe, apprends, et grandis main dans la main avec tous, et je ne pourrais pas être plus fier et plus excité par l’avenir qui nous attend.Comme l’explique Kan Tang :Qu’obtenons-nous de cette expérience ? Énorme apprentissage et croissance, nouvelles opportunités, bonheur, confiance en soi et amitiés de vie !

Plans futurs

Aujourd’hui, le contenu de DevOps Dojo est continuellement amélioré par la communauté, ils ont une seule source de vérité avec le plus récent et le plus grand contenu, et l’équipe peut collaborer à une échelle, à tout moment et n’importe où dans le monde. Ils ont vu l’adoption du contenu de DevOps Dojo croître mois par mois et ont commencé à voir les contributions commencer d’autres régions du monde. Le groupe attend avec intérêt d’étendre les pratiques DevOps Dojo et InnerSource au sein de Microsoft et peut-être même de commencer le processus d’approvisionnement ouvert du contenu Dojo DevOps au monde !Nous avons plus de 80 000 ingénieurs travaillant sur le code chez Microsoft, et nous évaluons constamment ce qui serait intéressant à partager ouvertement avec nos clients. InnerSource nous a permis de débloquer ce potentiel, de réduire la redondance et de collaborer plus efficacement.Arno Mihm, gestionnaire principal de programme pour InnerSource @ Microsoft.

Remerciements

Cette étude de cas a été rédigée par Clare Dillon, directeur exécutif de InnerSource Commons, Daniel Izquierdo, PDG de Bitergia & directeur de InnerSource Commons, et Dr. Klaas-Jan Stol, directeur de InnerSource Commons, à la suite d’une série d’entretiens avec les équipes du Dojo DevOps à Microsoft.

Clare note que Partager des histoires sur nos voyages InnerSource est une partie importante de la communauté InnerSource Commons. Nous tenons à remercier vivement toutes les personnes merveilleuses de Microsoft et GitHub qui ont pris le temps de partager leurs expériences et de nous aider à enregistrer cette étude de cas :

• Deep Mehta – Consultant en technologie, Azure Cloud & AI, Microsoft Inde
• Margarita Sanz – DevOps et Cloud Consultant, Microsoft Espagne
• Álvaro Guadamillas – Directeur de programme d’affaires, Azure Cloud & AI, Microsoft Espagne
• Michael Watson – Architecte, Microsoft Australie
• Yue Sheng – Consultant, Azure Cloud & AI, Microsoft Chine
• Kitty Chiu – Architecte principal DevOps, GitHub, Australie
• Harleen Kaur – Livraison technique – Sécurité de l’information & DevOps, Microsoft Inde
• Dave Burnison – Avocat technique principal, GitHub, États-Unis
• Karl Piteira – Groupe principal PM Manager, Microsoft, États-Unis
• Jeff Wilcox – Directeur principal du PM, Microsoft, États-Unis
• Natalie Bradley – Directrice, Customer Success Architects, GitHub, États-Unis
• Dave McKinstry – gestionnaire, programme FastTrack DevOps, GitHub, États-Unis
• Paul Fijnvandraat – Consultant principal, Microsoft Pays-Bas
• Chris Witte – Consultant principal, Microsoft US
• Jihee Choi – Consultant, Microsoft US
• Nicolas Mays – Conseiller ASSC, Microsoft US
• Geoff Sexton – Consultant senior, États-Unis
• Giulia Cupani – Gestionnaire de programme Azure, Microsoft Suisse
• Aakanksha Lnu – Gestionnaire de produits de conseil, Microsoft, Royaume-Uni
• Beste Altinay – ASSC Architect, Microsoft Pays-Bas
• Rui Melo – Architecte, Microsoft, PORTUGAL
• Nithyanathan R – ASSC Architect, Microsoft Inde
• Charlie Gu – Architecte, Microsoft, Chine
• Harry Chen – Architecte, Microsoft, États-Unis
• Bahram Rushenas – Architecte, Microsoft, États-Unis
• Garry Trinder – Senior Cloud Advocate, Microsoft, Royaume-Uni
• Kan Tang – Gestionnaire d’architecte, Services de vente au détail et de biens de consommation, États-Unis
• Arno Mihm – Directeur principal de programme, InnerSource @Microsoft, États-Unis

Pour plus d’informations ou pour obtenir plus de détails, rejoignez la communauté InnerSource Commons Slack pour susciter une conversation. Vous pouvez également consulter laDevOps Articles de blog Dojo(tous créés par l’équipe en utilisant Markdown via un processus InnerSource).

Si vous souhaitez partager votre histoire InnerSource, veuillez nous contacter àinfo@innersourcecommons.org.