Réparons-le. De préférence sans réinventer la roue.
Malheureusement, la réinvention de la roue est un phénomène courant dans les entreprises. La difficulté du problème est liée à la taille et au nombre d’équipes au sein d’une organisation.
La cause fondamentale est un manque de transparence et de communication entre les équipes.
De ce fait, les possibilités de collaboration sur des projets destinés aux utilisateurs ainsi que sur des outils et bibliothèques communs sont étouffées.
Il en résulte directement que les systèmes sont construits avec des objectifs qui se chevauchent.
Le code local est modulaire, mais sa réinvation et sa réinvation dans chaque entité ou domaine est infinie. Grand Dehors et petit dedans ….Chacun pense être spécifique, chaque implémentation est écrit pour satisfaire les objectifs de chaque projet plutôt que de partager et d’exploiter des solutions généralisées.
Tout le monde veut faire plus avec moins. La redondance des efforts et le chevauchement des systèmes deviennent l’anti-vision, ce qui entraîne une confusion générale (c’est-à-dire « quel système dois-je utiliser ? ») et une duplication des données.
Un plus grand nombre de systèmes entraîne une plus grande maintenance de la pile complète. Devops et GitOps pourraient être une voie, mais sans capacité à partager la route va être longue et risque fort d’améner de fort surcût, pour réussir les hommes doivent être mis au coeur de cette transformation.
La duplication des données dispersées dans les systèmes entraîne une augmentation des cibles potentielles d’exfiltration, DLP quanfd tu nous tiens.
L’approvisionnement interne vise à atténuer autant que possible ces problèmes et d’autres encore grâce à une collaboration et une communication ouvertes.
Approvisionnement interne : Qu’est-ce que l’approvisionnement interne ?
Le développement collaboratif n’est pas un concept nouveau.
Cependant, de nombreuses organisations ne parviennent pas à le mettre en œuvre pour de nombreuses raisons :
Le calendrier du projet, les aspects politiques, techniques (langages de programmation), etc.
Le terme « inner sourcing » a été inventé par PayPal.
Leur initiative « InnerSource commons » cherche à fournir des outils et des meilleures pratiques pour faire tomber les barrières et favoriser un développement ouvert et collaboratif.
Cet effort développe une culture beaucoup plus ouverte et collaborative, largement modelée sur la communauté open source. Pour avoir travailler durant plus de 20 ans à favoriser coutils collaboratifs et pratiques de collaboration, je suis heureux de revoir cette tendance reemergée.
De nombreuses communautés open source ont trouvé des moyens efficaces de collaborer et de travailler avec succès malgré les contraintes de fuseau horaire, la répartition des équipes et le manque de communication en personne.
Nombre de ces problèmes sont rencontrés par les organisations qui créé des solutions propriétaires, quelle que soit leur taille.
Pour optimiser la culture de collaboration au sein de ces organisations, il est possible de tirer parti des expériences et autres enseignements des communautés qui ont élaboré leurs méthodes et processus de collaboration sur plusieurs années.
Au cours de ma carriére et des projets, j’ai remarqué que ces différences philosophiques se répétaient :
Portée du projet
L’approche Open Source :
Faire le moins d’hypothèses possible.
Vous ne savez jamais comment vos utilisateurs vont utiliser votre code (si seulement je pouvais compter le nombre de fois où j’ai eu un PR rejeté parce que je ne pensais pas assez généralement)
Résultat :
Coût de développement initial généralement plus élevé en raison de la généralisation de l’architecture et des tests.
Des implémentations beaucoup plus extensibles, à l’épreuve du temps, qui ne nécessitent pas beaucoup de remaniement.
Approche d’entreprise :
Je dois résoudre ce problème (parfois très) spécifique.
Je vais écrire du code pour cette chose et seulement cette chose.
Résultat :
Conduit à des roues redessinées et à des facteurs de reformulation douloureux lors de la réutilisation/réutilisation du code existant.
Embauche
L’approche Open Source :
Le temps de montée en puissance doit être minimal afin de rendre la barrière d’entrée pour les contributeurs potentiels aussi basse que possible.
Résultat :
Grâce à l’effort de documentation, la documentation d’embarquement est déjà établie. L’assistance nécessaire pour que quelqu’un puisse se mettre à niveau facilement devrait être minimale, voire inexistante.
Approche entreprise
Le recrutement est lent et nous recrutons pas trop souvent de nouveaux collaborateurs, c’est pourquoi les documents d’embarquement sont considérés comme « un nice to have » au lieu d’être « Must to have ».
Résultat :
Les nouvelles recrues ont du mal à se familiariser avec une nouvelle équipe. Ils ne sont pas non plus les seuls à vouloir contribuer à votre base de données. En augmentant les temps de montée en compétence, vous empêchez également les personnes des autres équipes de contribuer à votre projet.
Documentation
L’approche Open Source :
Une documentation de haute qualité est d’une importance primordiale. Selon la nature du projet, des documents seront rédigés à la fois pour les utilisateurs et les développeurs.
Résultats:
Une bonne partie du temps est consacrée à la rédaction de la documentation. Cependant, grâce à cet investissement, les projets sont beaucoup plus accessibles aux nouveaux venus comme aux développeurs chevronnés.
Approche d’entreprise :
Nous savons tous que la documentation est importante, mais nous avons des délais qui précèdent le développement de la documentation.
Résultats :
La documentation est périmée, insuffisante, aléatoire ou même inexistante. Par conséquent, l’intégration des nouveaux employés et l’inclusion de collaborateurs externes s’avèrent difficiles.
Contributions entrantes
L’approche Open Source :
Tout le monde peut contribuer à notre base de code.
Résultat :
Tout le monde peut contribuer à la base de code. Par nature, le développement est ouvert et collaboratif.
Approche d’entreprise :
Nous n’attendons que des contributions de notre propre équipe.
Résultat :
Une hypothèse qui non seulement influe sur les décisions prises en matière de conception du système et de hiérarchisation des travaux, mais rend également les projets inaccessibles.
Collaboration
L’approche Open Source :
Je veux contribuer à d’autres bases de code.
Résultat :
Je peux parcourir les projets et contribuer à tout ce que je trouve intéressant.
Approche d’entreprise :
Je m’inquiète des implications politiques de mes contributions.
Résultat :
On a tendance à ne pas se séparer de son équipe pour des raisons politiques, même s’il y a une expertise de domaine à partager.
Déploiement
L’approche Open Source :
Tout le monde devrait pouvoir exécuter notre suite de tests avec le moins d’obstacles possible. L’exécution des déploiements devrait être entièrement automatisée.
Résultat :
Toute personne intéressée par le projet peut s’emparer du code source et exécuter la suite de tests facilement. Les déploiements se font par bouton-poussoir ou peuvent être simplement exécutés via une interface de ligne de commande (CLI). La barrière d’entrée pour contribuer de manière significative est presque inexistante.
Approche d’entreprise :
Personne en dehors de notre équipe ne contribuera jamais à notre code, il est donc normal d’avoir un runbook pour supporter un environnement de développement. Après tout, nous avons des mentors à bord pour aider les nouveaux membres de l’équipe à démarrer.
Résultat :
Les environnements de développement ne sont compris que par l’équipe. C’est pourquoi le coût de la mise en place d’un environnement de développement est élevé, ce qui augmente la barrière d’entrée initiale et décourage les personnes extérieures à l’équipe immédiate de contribuer.
Avec ces différentes philosophies, nous nous retrouvons avec des résultats (généralement) sous-optimaux :
Un certain nombre d’équipes qui sont en fait des boîtes noires les unes pour les autres
Une grande quantité d’efforts redondants et un chevauchement des systèmes
Le code qui est écrit est extrêmement difficile à réutiliser, même par l’équipe qui l’a rédigé
Documentation périmée
Temps de montée en puissance élevé, tant pour les nouvelles embauches que pour le développement collaboratif.
Un manque de cohérence entre les projets :
Normes de codage, outils et utilitaires, bibliothèques, construction de pipelines, etc.
Une pollinisation croisée inadéquate.
Nous savons tous qu’elles ne sont pas positives pour notre progression, alors faisons quelque chose pour changer cela !
| Nous pouvons éviter ces problèmes en appliquant les techniques de communication, les processus de développement et les meilleures pratiques employées par de nombreuses communautés à code source ouvert. |
