Inner Sourcing: la mécanique

Une série de blogs sur le sourcing interne: qu’est-ce que c’est, comment procéder pour le mettre en œuvre et quels sont les avantages et les pièges potentiels?

L’application à l’échelle d’une entreprise d’envergure mondiale et dont les métiers et les enjeux sont divers, régulés demande humilité et prise d’élan.

Les developments in house étaient légions il y a 25 ans,

il n’y avaient que gofer et les newsgroup.Les équipes collaboraient et partageraient au travers de news group gofer et de serveur de communauté et des dépôts de librairies, de mécanisme évolué de configuration de système complexes de bout en bout. Je me souviens utiliser skype en audio et vidéo entre la France et le Canada des 2003 avec une ligne RNIS). Il n’y avait01# grand chose et tout le monde inventait et collaborait, ca c’était avant l’arrivée de la taylorisation et des DSI, avant que les marketeurs ne relooke les techniques et méthodes. Mais trêve de nostalgie, ce qui hier était bon le redevient aujourd’hui avec des techniques et des outils démocratisés, l’experience et la mise en commun de toutes les forces pourraient bien devenir un succès. D’ailleurs au delà des compagnies du CAC40 en compte propre, l’initiative gagne l’europe. Oublier la dictature de l’utilisation sur étagère ? Le chemin est long et les embuches nombreuses ..

Quels sont les aspects fondamentaux de la création d’une culture collaborative de sourcing interne dans les limites d’une société avec du code source fermé.

Les piliers d’une culture de développement interne


undefined
Communication ouverte, intersociétés, collaborative et créative
La collaboration, la créativité et l’innovation réelle dépendent d’une bonne communication. Que ce soit par le biais de discussions en personne, de chats en temps réel, de listes de distribution ou de forums, il est important que les mécanismes soient détectables et cohérents.

Détectable – Découverte

Tout le monde dans l’entreprise peut facilement trouver des discussions qui se sont produites dans le passé.

Tous le monde doit utiliser le même mécanisme ou dépendre des intégrations qui regroupent leurs discussions d’équipe hors ligne dans un système commun.

Cohérent

Cela ne signifie pas qu’une seule méthode doit être utilisée.
Différents outils permettent d’atteindre différents objectifs.

Par exemple, Teams est un outil qui doit effectivement être utilisé à la place des e-mails.
Il permet un niveau de découverte beaucoup plus élevé que les e-mails, car toute personne disposant des privilèges requis pour voir le contenu peut trouver des fils de conversation dans les résultats de recherche. Il est également cohérent car tout le monde l’utilise.
A rapprocher de Confluence.

Vous trouverez de bonnes piste de réflexions sur la communication de groupe sur communicationtheory.org

Développement collaboratif inter-entreprises

De nouvelles fonctionnalités sont créées à partir de demandes de fonctionnalités entrées dans un système et sont hiérarchisées. Finalement, elles sont développées, testées et publiées par l’équipe projet sans assistance supplémentaire de l’équipe requérante. Bien que ce processus réponde aux exigences de la relation client, il ne se traduit pas par un partenariat de développement collaboratif.

Toutes les entreprises regorgent de talents inexploités. L’activation et l’encouragement des contributions inter-équipes profitent à l’équipe propriétaire du projet en enrichissant l’ensemble des fonctionnalités de leur produit.

Les contributeurs en profitent également car ils ne sont plus bloqués en attendant qu’une demande de fonctionnalité soit implémentée, ce sui un risque récurrent dans les grosses organisations qui n’ont pas muté à l’échelle.

L’une des habitudes est de nommer les équipes qui consomment leur production comme des clients. Cela doit être redéfini: le terme «client» implique des limites. Les «clients» doivent vraiment être considérés comme des «partenaires».

«Partenaire» implique l’ouverture et l’effort de collaboration. Tout le monde au sein d’une organisation doit être considéré comme un partenaire plutôt que comme un client, une distinction subtile mais importante.

Mise en œuvre et adoption


Malheureusement, la mise en œuvre et l’adoption ne sont pas normatives; une chaussure ne convient pas à tous.
Cependant, quelques pratiques clés peuvent être adoptées pour rendre un environnement de développement plus collaboratif.
Généralement, dans le monde des sources fermées, les équipes ont un propriétaire de produit ou un responsable technique.

Beaucoup de contributeurs, peu de committers

Les autres développeurs de l’équipe sont considérés comme des contributeurs. Pour aller vers une culture collaborative optimale, l’équipe doit évoluer. Bien que le propriétaire du produit ou le responsable technique ne change pas, à moins d’être exposé à un public (potentiellement) beaucoup plus large, le vrai changement s’applique au reste de l’équipe.

Ils deviennent des committers plutôt que des contributeurs. La différence est subtile et donne de meilleurs résultats.

Un responsable technique ou propriétaire de produit est responsable de la vision globale, de l’architecture et de la feuille de route technique du projet. Ils sont chargés de fournir l’approbation finale des demandes de fonctionnalités et des documents de conception ainsi que de l’intégrité globale du projet.

Considérez les différences

Un committer est un acteur clé dans la vision, la feuille de route technique et l’architecture du projet. Le chef de file et tous les commettants doivent tous être sur la même longueur d’onde en ce qui concerne l’orientation et la vision du projet et être en mesure de communiquer cette orientation et cette vision aux autres parties prenantes.


Les committers et les leads ont les autorisations nécessaires pour fusionner leur propre code ainsi que les contributions des contributeurs externes.

Un contributeur contribue au projet, qu’il s’agisse de code, de documentation ou de tests, mais n’a pas accès au code de fusion directement au référentiel canonique ou à la branche principale du projet.

Automatisation


Les projets collaboratifs les plus réussis sont ceux qui maximisent l’automatisation. Mon mntra no code is a bug.

Il ne devrait pas être plus difficile de mettre en place et d’exécuter un projet de manière cohérente entre les anciens combattants et les nouveaux arrivants que «make build», «make install», «make run», etc. Rien de plus ne devrait être exigé. Les projets devraient également disposer de pipelines de construction et de test entièrement automatisés, permettant aux nouveaux contributeurs d’avoir confiance dans leurs soumissions avant la fusion du code. Les Infrastructures Sont en inclure à l’équation.

Les meilleures pratiques


En ayant un ensemble de bonnes pratiques bien défini à l’échelle de l’entreprise, vous favorisez la cohérence. La cohérence abaisse la barrière d’entrée pour les contributeurs de sauter d’un projet à l’autre. Dans la mesure du possible, les meilleures pratiques devraient être basées sur les meilleures pratiques open source, ce qui permet de garantir que:

  1. S’ils ont contribué à des projets open source et connaissent les meilleures pratiques, les nouveaux employés ont une barrière d’entrée plus faible.
  2. La barrière d’entrée pour l’inspection des dépendances (débogage, contributions, etc.) est abaissée.


Tout le monde n’adoptera pas les meilleures pratiques de la communauté open source pour son équipe. Utilisez ce qui vous convient.


Les meilleures pratiques à considérer pour l’adoption sont spécifiques à:

Configuration du projet (structure de répertoires, fichiers communs, etc.)
Utilitaires de test et d’analyse statique
Bibliothèques couramment utilisées
Normes de codage partagées

En assurant la cohérence entre les projets et les équipes dans ces domaines, vous contribuez à minimiser les frais généraux pour les contributeurs potentiels.
Un développeur travaillant sur un projet en Python devrait pouvoir passer à un autre projet Python appartenant à une autre équipe avec peu ou pas de frais généraux.

Marketing et communication

Le code est écrit. Le code est déployé. Code pourrit. Si personne d’autre ne le sait, personne ne le maintiendra activement.

«Construisez-le et ils viendront»
ne s’applique pas au code.

C’est plus « Construisez-le, commercialisez-le et essayez de construire une communauté active autour de lui »

C’ est un peu plus proche de ce qui est réellement requis pour un projet collaboratif réussi.

Exemple concret:

Docker. S’agit-il de la première technologie de conteneurisation? Nan.
Était-ce le mieux commercialisé et le plus accessible? Absolument!
Une méthode de communication cohérente est un pilier fondamental du succès de l’approvisionnement interne.

Sans une méthode de communication cohérente qui transcende les barrières de l’équipe, l’efficacité des efforts de sourcing interne est intrinsèquement limitée par un manque de transparence et de communication ouverte.
Lors de l’évaluation des outils de collaboration, il est important de définir les problèmes de communication que vous essayez de résoudre:

  • Allez-vous principalement discuter de la conception et de l’architecture du système?
  • Avez-vous principalement besoin de canaux pour faciliter la lutte contre les incendies des opérations?

Il est très important de définir les problèmes réels que vous essayez de résoudre (et non les conséquences de vos biais), car certains outils et méthodes peuvent en fait dégrader votre capacité à communiquer efficacement en tant que groupe.

Pour plus d’informations à ce sujet, voir http://communicationtheory.org/creativity-in-groups/.

VCS<>DVCS

VCS (c’est-à-dire Perforce, un système de contrôle de version centralisé), n’offre généralement pas les mêmes fonctions prêtes à l’emploi qui facilitent un modèle de sourcing interne que le DVCS (c’est-à-dire git, un système de contrôle de version distribué).
Bien sûr, vous pouvez sauter à travers des cercles dans certains VSC pour imiter les propriétés de DVCS (par exemple, configurer des cycles de révision de code ou verrouiller des branches), mais les flux de travail DVCS sont beaucoup plus adaptés aux modèles de développement et d’intégration flexibles de contributeurs externes (par exemple, flux de demande fork et pull à l’aide de GitHub).
Non seulement cela, mais prêt à l’emploi avec DVCS, les projets sont destinés à être divisés en référentiels distincts, chacun pouvant avoir une liste de committers entièrement indépendante des autres projets. Avec cette séparation claire des contrôles administratifs entre les projets, il est beaucoup plus facile d’adopter des contributeurs externes avec git qu’avec VCS.

Documentation

Une documentation de haute qualité doit être d’une importance capitale pour l’équipe.


Ce devrait être un citoyen de première classe, tout aussi important que le code deployé. Elle rend ou brise durablement votre capacité à contribuer au projet. Plus le développeur ou les documents d’intégration sont incomplets, plus la barrière d’entrée est élevée. Plus les documents utilisateur et les références d’API sont incompletes, plus il est difficile pour les gens d’intégrer efficacement le projet.
De manière optimale, chaque projet doit avoir une répartition entre les documents développeur et utilisateur.
Les premiers adaptés spécifiquement aux développeurs du projet et les seconds permettent aux gens d’utiliser simplement le projet.

Cette répartition permet aux utilisateurs et aux développeurs de se concentrer uniquement sur ce qui est le plus important pour eux. La documentation doit être générée à partir du code et des commentaires de code là où il est logique de préserver l’intégrité de la documentation. Les développeurs sont beaucoup plus abituer à mettre à jour les commentaires en ligne avec leur code que de mettre à jour les documents externes. Une documentation périmée peut être tout aussi mauvaise, sinon pire, qu’un manque global de documentation, car elle peut conduire le lecteur sur le mauvais chemin.

Ceci est délicat. Il s’agit d’une approche différente de éflexion et de réalisation des opportunités de généralisation, de modularité et de réutilisabilité lors de la conception des systèmes. Généralement, une réaction immédiate d’un développeur est «Hé, j’ai besoin de la fonctionnalité X dans le projet Y. Je vais juste plonger dans le code. « 
Même si une conception complète est effectuée, c’est généralement pour un projet spécifique.
Dans les deux cas, vous vous retrouvez avec du code spécifique au projet qui n’est pas modulaire, extensible ou réutilisable.

Solutions généralisées


Les solutions généralisées prennent du temps à concevoir, à mettre en œuvre et à tester.
Avoir la capacité de reconnaître où vous faites des hypothèses et de valider ce sont les bonnes à faire ou à déterminer une solution alternative sans hypothèses peut être une chose difficile à faire et necessite beaucoup d’essais et d’erreurs, c’est là que le culture no Blame est importante, il faut savoir expérimenter pour apprendre, inutile de blamer un bébé qui aprend à marcher, c’est la maitrise de ses chutes successives qui lui permettra un jour d’avancer avec assurance.

Cependant, à long terme, penser aux problèmes et développer des solutions généralisées ne profite pas seulement à vous, mais aux autres au sein de votre organisation. Au lieu de copier / coller et de refactoriser, le code modulaire et les bibliothèques peuvent être réutilisés par plusieurs équipes et étendus. Attention toutefois au risque de forte dépendance.

Important: Ce n’est pas une règle stricte!
Ce ne sont que quelques-uns des outils et des meilleures pratiques adoptés par les projets open source afin de créer une culture de développement ouverte et collaborative.

Beaucoup d’autres peuvent être découverts lorsque les équipes commencent à travailler avec plus de collaboration.
De plus, toutes les implémentations de ces concepts ne seront pas également répartis entre les équipes et les organisations, et ils ne doivent pas non plus l’être. Ce qui est important, c’est que les concepts soient appliqués et que des interfaces cohérentes soient fournies entre les organisations afin d’avoir la plus faible barrière d’entrée possible pour les nouveaux contributeurs et d’atténuer autant que possible la duplication des efforts.

Dans le prochain article de cette série, nous verrons quels sont les principaux avantages de la culture de sourcing interne et évidement les pièges potentiels à connaître.

La barrière de Corail

Catégories :Communication, Manager, technique

Votre commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s