✌🏽 🧒🏼 👷 Comment amener les voisins à travailler sur leur projet, ou InnerSource pour une banque 👵🏾 🥒 😖

Qu'est-ce que le développement chez Sber? Aux yeux d'un informaticien ordinaire: «C'est là que le code a été écrit, allez-y!» Mais cela a longtemps été un stéréotype, et ils ne sont pas bons. Le développement rapide de l'open source prouve qu'une telle culture est depuis longtemps obsolète, et l'entreprise (si elle est intelligente) a depuis longtemps révisé l'approche du développement basée sur des silos. La publication de tous les logiciels bancaires en open source est un ~~moyen efficace de se suicider, une~~ décision plutôt controversée et une sorte d'étape intermédiaire est nécessaire. Avec l'échelle de la banque, nous pouvons lancer notre open source interne, plutôt que d'essayer de vérifier ce que nous pouvons montrer à tout le monde et de trembler de peur pour nos petits grands secrets.

Qu'est-ce qu'une InnerSource?

En 2000, Tim O'Reilly a décrit le terme source interne comme une étape possible vers une entreprise fermée entrant dans le magnifique monde open source. Il s'agit de l'application des meilleures pratiques de l'open source au sein de l'entreprise: de l'ouverture générale et de l'entraide proactive à la formation d'un marché pour les meilleures solutions. L'entreprise continue d'écrire du code propriétaire, mais chacun de ses employés a la possibilité d'affiner tout système interne.

Les avantages d'InnerSource peuvent être énumérés depuis longtemps: réduire le délai de mise sur le marché, améliorer la qualité du code, remplacer les recrutements externes par des internes, améliorer l'interaction entre équipes, etc.

La difficulté réside dans le fait que tout ce qui est décrit ci-dessus nécessite un changement dans la culture de communication entre les employés et les équipes, et ce n'est pas si facile à faire dans une organisation qui fonctionne différemment depuis des décennies.

Bien sûr, Sberbank n'est pas la seule entreprise à avoir fait quelque chose comme ça. En 2015, la communauté InnerSource Commons a été créée , qui a popularisé l'approche et a supprimé l'écart du terme pour le rendre plus facile à trouver dans les moteurs de recherche. Cette communauté a rassemblé l'expérience de dizaines d'entreprises et fait des recommandations efficaces pour la mise en œuvre d'InnerSource dans votre entreprise, et organise une conférence d'échange d'expérience deux fois par an. Il existe encore de nombreuses entreprises technologiques bien connues qui ont fait cela ~~depuis les Pechenegs et Polovtsy~~ avant qu'elles ne deviennent courantes.

En Russie, à notre connaissance, un seul grand détaillant sur le marché des services de construction avec un logo vert est activement engagé dans la mise en œuvre intentionnelle d'InnerSource, d'autres entreprises ne font pas la publicité de leur expérience ou ne participent pas à la communauté.

Chacune de ces entreprises a ses propres expériences positives et négatives. La conclusion générale dans ce cas est très similaire: les avantages les plus délicieux ne peuvent être obtenus qu'avec la participation de la grande majorité.

Pourquoi devrais-je le récupérer?

Presque toutes les conversations sur le développement dans Sberbank se posent la question «combien de programmeurs avez-vous là-bas?». Dans tout le pays, nous en avons plus de dix mille, ils travaillent activement sur des milliers de composants, systèmes, bibliothèques et autres comme eux. En conséquence de ces volumes, nous devons chaque jour résoudre les problèmes de gestion des dépendances sur les équipes liées, la relation de leadership et les phases de Mercure.

À la fin de l'enquête sur ce qui a blessé les ingénieurs, à la fin de 2018 à Sber, il a été décidé de créer une tribu SberWorks, qui a repris tout ce qui concerne les processus et les outils de production de logiciels dans la banque. Les tâches et les objectifs de l'unité découlaient presque complètement de la liste des douleurs collectées des développeurs.

J'ai honte d'admettre que la plus grande douleur à la fin de l'année dernière a été le manque de connaissance de ce que font les voisins dans l'atelier ou même dans le bloc voisin en espace ouvert. Pour cette raison, nous avons inventé non seulement la roue, mais aussi deux (remplacer le nombre souhaité) des mêmes roues dans des unités différentes, à la fois dans différentes villes et dans les lieux de travail voisins. En conséquence, ayant d'énormes ressources dans l'entreprise, souvent au lieu de voler vers Mars, nos équipes ont utilisé des râteaux, ne sachant pas que les râteaux voisins étaient depuis longtemps collectés.

Que faire de tout ça?

Temps. Pour résoudre les problèmes d'intégration et de trouver les bonnes personnes, créez un registre d'API unique pour tous les systèmes de la banque avec un grand nombre d'automatisation: génération d'appels, stubs pour la prochaine version de l'API, gestion des versions et autres. Maintenant, ce registre est devenu un produit sympa distinct, qui est certainement digne de son article, mais c'est une autre histoire.

Deux. Créez une sorte de "parapluie" avec un moteur de recherche unique sur tous les outils d'ingénierie (JIRA, Confluence, Bitbucket, Nexus), combinant les segments internes et externes (oui, alpha et sigma infâmes).

Trois. Le code, les backlogs et les artefacts, à l'exception de ceux qui interdisent explicitement l'ouverture de la sécurité, devraient être ouverts à tous les employés de l'entreprise.

Qu'est-ce qui a été suggéré?

Dans le processus de communication avec les développeurs, nous avons identifié la raison principale d'une telle équipe fermée en nous: les modes d'interaction actuels entre les produits. Toute discussion sur le perfectionnement des systèmes connexes s'est déroulée selon l'un des trois scénarios.

"Attendez"

La façon la plus courante d'interagir. L'équipe adjacente fixe un délai, cela nous convient généralement, nous reportons la tâche plus en profondeur dans l'arriéré.
En général, une option acceptable. Mais si la chaîne a des dépendances sur plusieurs équipes et que la fonctionnalité, comme d'habitude, doit être affichée en production hier, alors vous devez rechercher des compromis.

Compromis

Populairement, cette méthode est appelée escalade. Emmenez un gestionnaire plus important avec vous et venez dans une équipe adjacente afin de faire progresser votre tâche dans l'arriéré. Les inconvénients de cette approche sont évidents: la plupart des équipes ne peuvent jouer cette carte que quelques fois, après quoi la relation entre les équipes se détériore.

"Talon permanent temporaire" A

vu votre vélo Frankenstein avec des béquilles et des bazookas temporaires qui reproduisent la fonctionnalité du système sur lequel la dépendance est apparue. Le plus triste, car il reste presque toujours longtemps (sinon pour toujours), génère une duplication de code, et l'équipe est obligée de prendre en charge une solution de béquille.

Nous avons proposé une quatrième voie. Affinez dans la base de code de l'équipe adjacente sous leur supervision sensible, ce qui réduit le temps d'exécution.

InnerSource

À l'issue de cette interaction, l'équipe «A» de l'image reçoit de précieux commentaires, nourrit l'expertise dans un domaine adjacent et réduit le TTM de son raffinement. À l'avenir, dans la banque, de telles interactions ont rapidement acquis des formats de troc de différents types: l'équipe «A» clôt les tâches de la dette technique de l'équipe «B» tout en effectuant le raffinement nécessaire.

Notre chemin

Au tout début, il nous a semblé que nous devions trouver des endroits dans lesquels InnerSource serait actuellement en demande maximale. Pendant que nous réfléchissions à la façon de procéder, sans tomber dans un cycle de sondages sans fin, les dirigeants avisés ont apprécié l'idée et proposé de garantir la disponibilité à cent pour cent de cent pour cent des systèmes Sberbank d'ici la fin de l'année. Nous nous sommes tendus, notre directeur a demandé «qu'est-ce que cent pour cent?», Et le nombre de systèmes a été réduit d'environ 20 fois pour devenir moderne et / ou critique pour l'entreprise.

Après cela, le processus de circulation de cette pratique au sein des équipes a commencé, à la fin duquel nous avons vu un pré couvert avec une liste de référentiels et des règles pour travailler avec chacun d'eux.

Nous avons eu un tas de réunions à différents niveaux, d'abord avec les responsables techniques des départements, puis avec les chefs d'équipe et les propriétaires de services, et enfin avec les membres de l'équipe. Nous avons demandé aux représentants du service de fournir des informations sur le système lui-même, la pile de développement et les liens vers les référentiels, le backlog et la documentation. Lors des mêmes réunions, nous avons pu obtenir des informations de première main sur la douleur: arriéré sans fin, manque de ressources, ancienne pile technologique (par exemple, Delphi).

En cours de circulation, nous avons acquis une compréhension des maillons forts et faibles de la banque. Il y avait des équipes très matures (par exemple, le développement mobile) qui travaillent déjà sur les principes d'InnerSource à l'échelle industrielle et partageaient un grand nombre de cônes et d'approches. Mais plusieurs équipes (bonjour aux Petchenègues) nous ont découragés par le manque de tests automatiques, de journalisation et de pratiques de révision de code.

Parmi nos équipes, il y a un énorme fossé culturel entre «mon unité militaire travaille sur les tâches les plus correctes» et «faisons-le ensemble cool». La plupart des réactions étaient assez monotones: "nous ne voulons pas prendre le code de quelqu'un d'autre et ensuite répondre", "nous ne voulons pas donner à nos développeurs car ils partiront, mais il n'y a pas de ressources de toute façon". À ce stade, il a été décidé d'investir davantage dans la culture que dans la technologie:

HR : Google, , 10 % .
PR : Microsoft, open source.
: , - Delphi GraphQL, 10 % , !
, API, JIRA- .

Avec une erreur, nous avons appris à suivre les interactions inter-équipes qui se déroulent dans BitBucket et avons reçu des informations selon lesquelles nous avons environ 30 à 50 nouveaux auteurs de modifications InnerSource ajoutés chaque mois. Le chiffre en termes de nombre de développeurs dans la banque n'est pas très impressionnant, mais ce ne sont que des améliorations sur les tâches commerciales.

De manière attendue, les changements basés sur les données dans divers bus d'intégration et services ETL sont devenus très populaires. Cela s'explique facilement par le grand nombre de tâches et le faible coût des améliorations.

Nous avons soigneusement étudié ces améliorations sur l'exemple de notre ESB. Une transition vers une nouvelle solution est prévue pour elle dans un avenir proche, donc aucune ressource supplémentaire n'a été allouée à l'équipe, alors que les demandes de révision n'ont fait qu'augmenter. Chez InnerSource, les gars ont vu le salut, ont rapidement agité et assemblé un prioriseur qui soulève votre tâche autant que possible si vous êtes prêt à le faire vous-même. En chiffres, cela ressemble à ceci: en octobre-novembre, près de la moitié (101 sur 209) des demandes de révision ont été traitées par les équipes elles-mêmes. Cela a permis de réduire de quatre fois les temps d'attente de 2,5 mois à 2,5 semaines.

De façon assez inattendue, les concepteurs ont pris une part active, qui sont heureux d'aider les équipes liées lorsque ces dernières manquent de ressources ou nécessitent un nouveau look. Il s'est avéré que de nombreuses équipes peuvent utiliser des designers à 100% et elles-mêmes sont créatives et adorent changer d'orientation pour un nouveau produit.

Épilogue

Les premières étapes pour introduire la transparence et les interactions entre les équipes d'une entreprise habituée à respecter les lois de l'entreprise sont toujours les plus difficiles. Nous pouvons dire en toute sécurité que les premiers murs ont été franchis et qu'une quantité suffisante d'histoires InnerSource réussies a été accumulée pour que le mouvement à l'intérieur de la Sberbank prenne de l'ampleur.

Le principal défi que nous envisageons à l'avenir est d'éviter la loi de Goodhart . Dans toute entreprise de taille moyenne et grande, l'efficacité doit être mesurée: trouver un chiffre et le faire grandir. Lors d'une conférence à Baltimore l'automne dernier, plusieurs cas ont été présentés où la fixation d'objectifs pour la préparation des équipes et le nombre d'améliorations ont conduit au sabotage des mesures et à l'épuisement des dirigeants du mouvement.

Nous pensons que les avantages qui en résultent découragent complètement l'effort investi et l'ouverture en elle-même présente d'innombrables avantages. Nous sommes prêts à raconter notre chemin plus en détail et à échanger nos expériences, écrivez-appel - innersource@sberbank.ru . Bisous, Sberbank.