Europace

Adopter les pratiques open source chez Europace

Étude de cas tirée de l’article ou chapitre d’Isabel Drost-Fromm dans « Adopting Inner Source » (juillet 2018)

Introduction

Europace est une entreprise fintech de taille moyenne basée à Berlin, en Allemagne. Elle a officiellement lancé son programme InnerSource en 2017 et a partagé ses enseignements dans l’article un an plus tard. 

Au cours de cette première année, Europace a constaté une amélioration sensible des délais de développement, une meilleure qualité du code et une collaboration plus fréquente entre équipes là où les processus et pratiques InnerSource avaient été appliqués. Les nouveaux processus ont aussi renforcé la responsabilité des développeurs envers les projets et favorisé une culture du mentorat entre équipes.

Objectifs d’InnerSource

En 2015, Europace a commencé à explorer d’autres modèles d’organisation et de gouvernance. L’objectif était de créer un nouveau cadre pour toute l’entreprise, favorisant une culture d’« auto-organisation décentralisée » (je peux insérer un lien ici…). Dans cette nouvelle structure, les responsabilités et les décisions seraient confiées aux personnes ayant le plus d’expertise. 

Cette mission reposait sur la « … conviction fondamentale… que les employés d’Europace sont experts dans leur domaine et tout à fait capables de prendre les bonnes décisions ». 

(faut-il ajouter une référence ?  Page 88 de l’article)

Dans ce contexte, InnerSource offrait à la fois un modèle global et des lignes directrices utiles pour concrétiser cette vision. 

En reprenant les bonnes pratiques de l’open source, InnerSource pouvait également résoudre plusieurs difficultés de cette entreprise en croissance, notamment :

• La multiplication des silos de développement entre les équipes. 
• L’interdépendance technologique et les difficultés associées à la priorisation du développement.
• Les lacunes d’information et la perte de « mémoire des projets » dues à une documentation limitée. 
• La nécessité de passer à une communication et à une prise de décision asynchrones pour faciliter le travail à distance.

InnerSource : la première année chez Europace

Obtenir l’adhésion et l’engagement du personnel

• Créer un rôle dédié à InnerSource

Un rôle spécifique a d’abord été créé pour coordonner les efforts InnerSource. L’expérience du nouveau coordinateur dans l’open source et auprès de l’Apache Software Foundation a été précieuse pour comprendre, communiquer, mettre en œuvre et résoudre les problèmes rencontrés dans le parcours InnerSource d’Europace.

• L’importance stratégique des relations humaines

L’étape suivante consistait à mobiliser différents acteurs d’Europace et à discuter des avantages de leur participation. La démarche choisie était de les inviter à des déjeuners informels en tête-à-tête. Ces échanges ont été particulièrement utiles pour identifier les préoccupations et les obstacles potentiels. 

Une fois les difficultés communes identifiées, des déjeuners informels en groupe ont été organisés pour partager les enseignements. Ils sont ensuite devenus des tables rondes mensuelles autour d’un déjeuner, consacrées à l’échange d’informations et à la résolution de problèmes.

• Le rôle de Trusted Committer au « méta-niveau »

Durant cette première phase, les personnes enthousiastes à l’égard d’InnerSource ont aidé leurs collègues à adopter de nouveaux processus de communication et de consignation des décisions. D’autres ont accompagné les équipes, répondu aux questions et promu InnerSource auprès de leurs collègues.  Ce groupe central a été invité à devenir les Trusted Committers du programme InnerSource.

L’attribution du statut de Trusted Committer reconnaissait publiquement les efforts des promoteurs et mentors d’InnerSource. Elle rendait également visibles les personnes qui portaient le programme dans l’entreprise. 

Nouveaux processus, nouveaux outils

• Accroître la transparence de la communication et des décisions

Retracer les décisions concernant le développement et les produits était devenu difficile chez Europace.  Le besoin de consigner par écrit les communications et les décisions avait été identifié. 

Les promoteurs d’InnerSource ont activement encouragé leurs collègues et donné l’exemple pour passer de décisions principalement orales à l’utilisation de Slack, des discussions GitHub ou d’autres supports archivés. 

• Améliorer la transparence des tâches pour faciliter la collaboration

Jusqu’alors, la planification se faisait principalement sur des tableaux Trello ou dans JIRA. Les équipes limitaient toutefois souvent les accès en lecture et en écriture à leur propre unité, créant des obstacles à la collaboration entre équipes.

GitHub rendant les informations accessibles par défaut, son adoption a facilité pour toutes les équipes les recherches « … dans les tickets, les échanges sur les pull requests et le code ».

• Le dépôt InnerSource : donner l’exemple et permettre de se tromper sans risque

Le programme InnerSource devait montrer l’exemple en matière de transparence, offrir un espace où poser des questions à la communauté et conserver les documents pertinents recueillis.

Le programme suivait une approche InnerSource « fondée sur l’infrastructure » (ajouter une note de bas de page). 

Les processus de communication ont été conçus pour refléter les principes InnerSource présentés ci-dessus et, conformément à cette démarche, les outils déjà disponibles dans l’organisation ont été réutilisés. 

Un dépôt GitHub (« ep-innersource ») recensait tous les travaux et décisions du programme InnerSource. Un canal Slack dédié a été créé pour les discussions générales sur le programme.

Le dépôt GitHub offrait également un espace où expérimenter les processus et la technologie dans un environnement sûr, sans risque de perturber les systèmes de production.

• Le passage aux pull requests

Même si certains employés d’Europace connaissaient déjà GitHub, les équipes étaient désormais encouragées à utiliser les pull requests pour gérer l’interdépendance technologique.

Les contributeurs de toute équipe souhaitant apporter des modifications avaient l’autorisation de télécharger le code au moyen d’une pull request sur GitHub. Ils pouvaient ajouter ou modifier une fonctionnalité, puis la soumettre au Trusted Committer de l’équipe hôte pour approbation. Le code était ensuite intégré à la base principale ou le contributeur était invité à effectuer d’autres révisions. 

En quelques semaines, les pull requests ont été adoptées plus largement comme modèle de collaboration.

• Renforcer la responsabilité dans les projets InnerSource : le Trusted Committer

Le rôle de Trusted Committer (insérer ici un lien vers le parcours d’apprentissage ISC) a été introduit pour faciliter la collaboration entre équipes, préserver la mémoire des projets et renforcer la responsabilité envers ceux-ci dans la durée. 

Les Trusted Committers garantissaient la qualité des produits tout en réduisant les obstacles aux contributions. Ils accompagnaient également les développeurs souhaitant contribuer au code ou proposer des corrections.

Une fois qu’ils avaient gagné la confiance des responsables du dépôt, les contributeurs obtenaient un accès en écriture.

Développer une compréhension commune d’InnerSource en interne

Au départ, InnerSource était défini comme une manière d’appliquer les principes de l’open source aux projets de l’entreprise. 

À mesure que le programme évoluait, il devenait important que les employés comprennent non seulement « comment » pratiquer InnerSource, mais aussi les principes et les bonnes pratiques qui soutenaient son adoption réussie chez Europace.

Le programme InnerSource a développé la sensibilisation et les connaissances des équipes en facilitant un travail collectif pour : 

• Documenter les enseignements InnerSource sur le blog technique de l’entreprise.
• Soumettre un modèle InnerSource à InnerSource Commons.
• Créer un ensemble de principes InnerSource pour Europace.

Comme pour tous les programmes InnerSource, les demandes de contribution et de revue étaient diffusées sur le canal Slack. Les initiatives étaient aussi publiées sur GitHub et, au besoin, le responsable InnerSource contactait les personnes clés pour demander des revues.

Résultats d’InnerSource

En un an, les projets InnerSource déployés chez Europace avaient démontré les avantages de ce modèle de collaboration :

• Le passage à GitHub et l’encouragement, dans toute l’entreprise, à documenter les décisions sur les principales plateformes ont accru la transparence des projets et réduit la fragmentation des informations.
• Le rapprochement des décisions, des discussions d’architecture, de la documentation et du code sur GitHub a facilité le suivi et la compréhension des changements. Il a réduit le besoin de nombreuses exigences formelles de documentation préalable, suscitant ainsi davantage d’intérêt pour les projets chez les chefs de projet et les concepteurs UX.
• La prise de décision asynchrone via Slack et GitHub a facilité la participation de personnes qui n’étaient pas initialement impliquées dans les projets. Sans dépendre d’un lieu de travail commun ni de réunions en présentiel, les employés pouvaient partager leur expertise au-delà des frontières des équipes, des horaires et des lieux.
• Le rôle de Trusted Committer a renforcé la responsabilité des développeurs. Le mentorat étant intégré à ce processus, il a été reconnu comme une contribution précieuse du personnel.
• Les pull requests ont permis aux membres expérimentés d’apporter leur avis et leur soutien à des projets ne relevant pas de leurs responsabilités. Le filet de sécurité des pull requests et des revues de code a aussi offert aux nouveaux développeurs la possibilité d’apporter des contributions utiles.
• Les pull requests ont également favorisé « … une accélération du développement »

• La qualité du code et des revues de code s’est améliorée sensiblement.

Conclusion

La promotion des pratiques InnerSource dans l’entreprise et dans plusieurs projets a démontré leur valeur pour produire du code de meilleure qualité, encourager sa réutilisation et résoudre des problèmes existants comme la perte de mémoire des projets et la fragmentation des informations. L’utilisation d’InnerSource dans certains projets a établi les avantages de la collaboration entre équipes, pour les projets comme pour le personnel. Les nouveaux développeurs ont pu acquérir des compétences, tandis que les plus expérimentés étaient reconnus comme Trusted Committers et mentors.

La deuxième phase du programme InnerSource d’Europace devait se concentrer sur les nouveaux défis liés au passage à l’échelle et à l’extension du programme.

Du point de vue d’Europace, la phase initiale d’adoption était néanmoins considérée comme une grande réussite.