Parcours d’apprentissage : responsable de projet

Cette section traite de la façon dont InnerSource s’adapte à d’autres aspects de la direction du projet, y compris l’agilité, l’open source, la planification des capacités, etc.

InnerSource pour les chefs de projet

Après avoir terminé ce segment, vous aurez une meilleure compréhension de la façon dont InnerSource accélère le développement de produits. Nous traiterons également de la façon dont elle est liée aux meilleures pratiques de développement Agile.

Pour parvenir à l’agilité, les organisations s’efforcent de former des équipes autonomes. Cependant, dans un monde complexe et interconnecté, certaines dépendances ne peuvent être évitées. InnerSource offre une alternative pour « attendre », « construire des solutions de rechange » et « augmenter » : les équipes qui ont besoin de modifications dans leurs dépendances peuvent offrir une aide. InnerSource facilite la collaboration entre les équipes. En mettant l’accent sur la communication écrite, il est bien adapté même pour le mode distant.

Dans cette section, vous apprendrez où le développement Agile et InnerSource utilisent une terminologie similaire et même la technologie – mais diffèrent considérablement dans les détails. Au lieu de tomber dans des malentendus communs, vous bénéficierez de connaître les différences de culture mais aussi dans le but des outils utilisés.

Vous comprendrez l’impact de InnerSource sur la planification des capacités. Aussi avec InnerSource il n’y a pas de déjeuner gratuit – les équipes hôtes ont besoin de temps pour les contributeurs de mentorat. Nous examinerons également les possibilités de négociation supplémentaires que InnerSource apporte – en maintenant l’équilibre de donner et prendre.

Mais commençons par un bref exemple. Imaginez que vous construisiez une belle nouvelle application musicale. Afin de comprendre comment vos utilisateurs interagissent avec l’application, vous commencez à collecter des journaux d’interaction. Au fil du temps, vous approfondissez votre analyse en alimentant vos apprentissages en développement. Maintenant, imaginez une autre équipe qui apporte du contenu dans votre application a aussi quelques besoins – ils peuvent vouloir récompenser les créateurs de contenu en fonction du nombre d’utilisateurs qu’ils ont rejoints. Donc eux aussi, ils commencent à utiliser vos journaux collectés. Mais ils ont besoin de quelques étapes d’analyse supplémentaires que vous n’aviez pas pensé au début. Ils sont maintenant confrontés à un défi : Construisez une solution de rechange, ou passez par votre arriéré pour obtenir la priorité de leur demande. Avec InnerSource ils auront une troisième option : Faire les changements eux-mêmes – avec votre aide. Bien sûr, cela peut être plus lent que si vous aviez fait les changements. Mais il sera encore plus rapide que d’attendre que vous vous voyiez pour faire les modifications.

Dans une organisation idéale de InnerSource, vous pouvez l’étendre encore plus: Rappelez-vous la dernière fois que vous avez dû faire des modifications de coupe transversales sur toute votre plateforme? Quand on va « la mettre dans l’arriéré de chaque équipe » cela a souvent l’impression qu’elle traîne pour toujours. D’autre part, il accélère considérablement les choses pour fournir à ces équipes un patch qui implémente la modification. La complexité des modifications de cette approche dépend de la maturité de l’organisation et de la viabilité/modularité du code produit.

InnerSource et Agile

Vous souhaitez améliorer votre produit et fournir plus rapidement aux clients. Vous voulez rendre les parties prenantes heureuses. InnerSource aide votre équipe à offrir de la valeur et à maintenir son autonomie dans un monde fortement interconnecté.

Les organisations essaient de fournir rapidement de la valeur aux clients. L’une des causes courantes des retards est la dépendance dans le processus d’exécution. En conséquence, les organisations préfèrent des équipes interfonctionnelles couvrant la communication avec les clients, la conception, la mise en œuvre, les essais et les opérations, éliminant ainsi les transferts coûteux. Pour atteindre des performances élevées, les équipes éliminent les déchets et réutilisent les composants existants. Du point de vue de l’équipe, chaque composante réutilisée ajoute une autre dépendance en dehors du contrôle de l’équipe. Le côté négatif de cette optimisation est clair : l’équipe dépend d’une autre équipe si elle a besoin de changements dans le composant utilisé. Pour être en mesure de mettre en œuvre ces discussions souvent longues sur la feuille de route sont programmées, conduisant parfois à la nécessité d’optimiser les priorités détaillées à l’échelle mondiale. Dans les situations complexes autant que dans les grandes organisations, cela entraîne une augmentation du temps nécessaire pour s’adapter aux besoins changeants des entreprises. Pour les composantes centrales très populaires, il y a souvent tellement de demandes que l’une d’elles manque de capacité pour mettre en œuvre tous les changements demandés.

Dans les organisations traditionnelles, il n’y a que deux façons d’apporter des changements aux dépendances:

Soumettre un rapport de requête de fonctionnalité / bug et attendre que l’autre équipe pour prioriser ce changement et le mettre en œuvre.
Construisez une solution de rechange pour éviter le bogue ou fournir localement les fonctionnalités nécessaires.

Si aucune de ces options n’est réussie, le problème est en général aggravé et décidé à un niveau hiérarchique supérieur.

Aucune solution n’est particulièrement satisfaisante. En regardant l’Open Source bien qu’il y ait une solution évidente : une équipe en fonction d’un composant devient une équipe contributive et fournit une aide à l’équipe hôte.

Maintenant, vous pouvez vous demander: « Est-ce que cela mène à un chaos complet où les gens écrivent au hasard dans les dépôts de code des équipes dont ils ne sont pas membres? » InnerSource vient avec un ensemble de rôles et de processus qui apportent la clarté à ce qui autrement conduirait effectivement au chaos:

Chaque projet InnerSource a un ensemble de Trusted Committers avec des responsabilités claires qui vont au-delà de la simple révision du code. Trusted Committers fixe les règles pour les contributions.
Les contributions se font de manière structurée :
- L’intention de contribution est partagée tôt pour s’assurer que la contribution corresponde à la vision et à la portée des projets hôtes.
- Les progrès sont communiqués tôt, de sorte que l’équipe hôte a la chance de guider le contributeur et de le guider sur la voie d’un design et d’une architecture souhaités. De cette façon, la frustration due au fait de devoir refuser une contribution tardivement dans le processus est évitée.
- Les décisions et la communication vitale se produisent asynchronement pour pouvoir travailler autour de différents horaires de réunions de personnes dans différentes équipes. Par conséquent, les équipes de contribution acquièrent l’autonomie pour réparer les artefacts en amont sans sacrifier la qualité de la composante à laquelle on contribue.

Comme effet secondaire InnerSource fournit aux équipes des pratiques exemplaires qui rendent le travail dans une première culture à distance facile.

Au lieu de travailler en silos InnerSource favorise la collaboration entre les équipes. Tout comme dans Open Source qui signifie se tenir sur les épaules des géants : Au lieu de construire chaque composant localement InnerSource favorise la réutilisation. Il réduit le coût de la réutilisation en fournissant un chemin clair pour soutenir l’équipe amont avec le travail de correction des bogues et des fonctionnalités d’implémentation.

Tout comme dans Open Source InnerSource favorise une pensée de forces combinées : des composants dont toutes les unités d’affaires et les équipes de produits ont besoin comme base peuvent être construits ensemble. En conséquence, tous les bateaux s’élèvent ensemble: l’innovation créée dans une partie de l’organisation peut créer des avantages dans toute la société. Avec les équipes qui connaissent bien InnerSource la charge de faire avancer ce type d’innovation peut être partagée par toutes les équipes qui bénéficient et dépendent des composants et services qui en résultent.

InnerSource donne à votre équipe l’initiative et l’outil pour résoudre les problèmes qui bloquent les fonctionnalités d’expédition aux clients. Une bonne maintenance des composants et services de base peut être partagée d’une manière bien structurée par une « équipe virtuelle InnerSource » plus grande que n’importe quelle équipe de produits spécifique.

Dans les paramètres avancés, les participants comprennent la valeur des contributeurs travaillant sur des fonctionnalités plus simples qui peuvent ne pas bénéficier directement à leurs clients – à condition qu’il libère l’équipe hôte de travailler sur des changements plus complexes que les contributeurs ont besoin d’une entreprise.

Réponse courte : Non, pas du tout. Les deux se complètent :

Un code bien adapté et bien testé est un objectif de toute équipe agile. Dans un réglage InnerSource, les temps d’attente pour les membres de l’équipe mais aussi pour les contributeurs externes de l’équipe deviennent plus courts.

Les équipes qui connaissent bien la collaboration et qui évitent d’assigner des tâches sont en bonne position pour traiter les contributions externes avec souplesse. Ils apportent également un style d’esprit et de communication qui fonctionne bien pour motiver les contributeurs sur la priorité dont ils n’ont aucune influence directe. Travailler avec une motivation intrinsèque au lieu de diriger le travail signifie que les équipes hôtes ont les outils pour collaborer avec les contributeurs.

Les équipes qui s’associent pour travailler sur les problèmes sont déjà à l’aise avec le partage des progrès tôt. Il y a deux défis à passer à InnerSource à partir d’une culture d’appariement seulement : L’équipe d’accueil doit prendre le temps de soutenir les contributeurs et de programmer cela dans leur travail prévu. En outre, lorsqu’on franchit les limites de l’équipe, il est souvent difficile de trouver des créneaux horaires pour l’appariement – dans ces cas, il devrait être complété par une collaboration asynchrone. Pour éviter des perturbations fréquentes, les membres de l’équipe hôte doivent souvent planifier leur journée de façon plus rigoureuse dans les paramètres InnerSource. Souvent, il est plus simple de réserver certaines heures dans la journée ou un jour par semaine pour des contributions de mentorat. Le rendre explicite au niveau de l’équipe prend beaucoup de pression sur les ingénieurs essayant d’atteindre leurs propres objectifs d’équipe mais aussi aider les contributeurs. Un autre défi avec l’appariement est qu’il permet aux paires de se déplacer très rapidement ensemble – souvent au détriment de l’écriture d’informations importantes vers le bas pour le reste de l’équipe. Dans un réglage InnerSource il faut de la formation pour se rappeler de ramener toutes les décisions pertinentes aux canaux de communication partagés pour l’équipe hôte et les contributeurs. Du point de vue des produits, cela apporte beaucoup plus de transparence au processus de développement. Cela signifie également que les décisions qui autrement auraient pu être prises au niveau de l’ingénierie seulement sont désormais visibles pour toutes les parties concernées.

Rappelez-vous la dernière fois que vous avez insisté pour que votre produit soit bien testé, de préférence avec des tests automatisés afin que les déploiements puissent se produire fréquemment et sans intervention humaine? Cet objectif aide également InnerSource : Les contributions sont beaucoup plus faciles si les contributeurs peuvent vérifier localement si leurs changements sont sûrs. Les tests s’assurent également que l’équipe hôte se souvient de conserver la fonctionnalité fournie si on lui rappelle la raison de son échec.

Rappelez-vous la dernière fois que vous avez insisté pour que votre équipe passe du temps à suivre l’objectif de « laisser le code dans une meilleure forme que vous l’avez trouvé »? Cet état d’esprit aide dans le modèle InnerSource : Il veille à ce que la qualité et la cohésion du code restent élevées même lorsqu’il y a des contributions multiples de différentes sources.

InnerSource et Agile utilisent certains des mêmes outils – à des fins différentes.

Release trackers: Dans les équipes agiles, les histoires d’utilisateurs sont une conversation avec le client. Souvent les sont mis comme des notes collantes sur un tableau blanc. Mais aussi souvent ils sont stockés dans un tracker de problèmes. Par conséquent, les trackers sont principalement perçus comme des outils de planification, essentiellement un remplacement des notes collantes sur un tableau blanc. Dans InnerSource, les trackers d’émission servent à une conversation avec le client, mais aussi pour la communication entre les membres d’une équipe de commiteurs de confiance et les contributeurs travaillant sur un composant commun de InnerSource. Les problèmes de InnerSource deviennent beaucoup plus longs et plus verbaux que dans votre organisation moyenne. Ils suivent également l’historique de la mise en oeuvre et les décisions de conception détaillées pour un changement.

Examens de codes : Dans les organisations traditionnelles, les examens de codes servent souvent à des fins de vérification.

Ils sont faits lorsque le développement est terminé. Dans InnerSource les changements de code sont partagés très tôt dans le processus, parfois quand rien de plus qu’un croquis brut est fait. L’objectif est de solliciter une rétroaction et un mentorat rapides. Cela est particulièrement utile pour les équipes qui sont sur divers horaires et ne trouvent pas de temps pour la programmation par paires. Souvent les équipes ont l’aspiration que personne ne marche seul – en réalité, bien que ce soit souvent beaucoup plus qu’une aspiration jamais réalisée. En particulier, lorsque les contributions dépassent les limites de l’équipe.

Les outils utilisés dans InnerSource peuvent formaliser cette demande que plus d’un humain soit impliqué dans tout changement.

Focus sur la communication écrite: Le but avec InnerSource est que le projet soit suffisamment transparent pour que les développeurs qui ne font pas partie de l’équipe puissent comprendre les décisions du projet et suivre le processus de création de logiciels. Par conséquent, toute communication doit être dans un endroit que tous ceux qui s’intéressent à la conversation peuvent suivre : écrit, public, consultable et linkable. L’objectif n’est pas de réduire les distractions aux autres – l’objectif est de rendre transparentes toutes les conversations de projet.

Il faut donc éviter les messages et les mails directs. Afin de faciliter les conversations suivantes pour tout le monde, les messages liés à un projet InnerSource doivent être suivis dans un seul canal de communication : Le but n’est pas d’atteindre tous les membres de l’équipe du projet InnerSource. L’objectif est de trouver une salle commune pour tous ceux qui participent au projet où ils peuvent avoir des discussions centrées sur ce projet InnerSource.

L’accent mis sur la communication écrite ne signifie pas que la communication verbale est refusée. Il faut encore du temps pour une tasse de café partagée. Aussi résoudre les problèmes ensemble, l’appariement avec d’autres ou en personne hackathons sont précieux pour trouver des solutions rapidement. L’équipe doit s’assurer que toutes les décisions pertinentes du projet sont maintenues dans les canaux auxquels chacun a accès. Cela peut également signifier reporter les décisions importantes du projet jusqu’à ce que tout le monde soit de retour de vacances ou d’attente pour un autre jour ou deux si ceux qui travaillent dans un autre pays sont maintenant en vacances. Cela n’est pas seulement pertinent pour les décisions de codage, mais concerne également la mission, la feuille de route et l’orientation générales du projet. Sans cette information, les contributeurs auront du mal à comprendre quelles contributions auront de bonnes chances d’être acceptées.

Toutes les discussions dans les projets InnerSource sont visibles pour tout le monde dans l’entreprise. Clamer les gens pour leurs erreurs, les ridiculiser pour leurs erreurs, parler derrière leur dos de ce qu’ils ont fait de mal est un moyen sûr de tuer cette confiance et mène à l’échec de ce projet InnerSource. Cela est particulièrement important pour toute personne occupant un poste de leadership ou de modèle.

InnerSource et planification

La planification joue un rôle dans InnerSource dans deux situations importantes :

Les équipes contributrices doivent comprendre que le travail sur le code en amont nécessite généralement plus de temps que d’apporter des changements comparables à leur propre base de codes qu’elles connaissent bien. Ils doivent être conscients du fait que même si l’équipe hôte n’a pas à mettre en oeuvre le changement, elle doit encore être disponible pour le mentorat et l’examen. Le temps nécessaire pour cela augmente avec la taille du changement requis. En conséquence, une communication précoce avec l’équipe hôte est importante, en particulier en cas de changements plus importants.

Les équipes hôtes doivent également être conscientes du temps nécessaire au mentorat et à l’examen. Il suffit de dire aux équipes participantes qu’elles peuvent soumettre des modifications car les correctifs ne réduisent pas le temps de faire le changement à zéro pour l’équipe hôte. En outre, les équipes hôtes peuvent se retrouver dans la situation rare où elles sont inondées de demandes de tirage. Pour ce faire, il faut bien comprendre les priorités opérationnelles des projets qui envoient ces demandes. Lorsque les patchs sont dépassés, il est souvent temps de penser à partager la propriété du composant. En particulier, les contributeurs qui reviennent régulièrement et qui ont gagné la confiance de l’équipe hôte sont de bons candidats pour recevoir le titre Trusted Committer.

On ne peut cependant éviter certaines frictions dues à une culture de travail légèrement différente. Pour ces cas, il est important de définir explicitement les attentes.

Imaginez la situation suivante : En tant que contributeur, vous avez finalement fait le changement nécessaire – probablement avec un peu d’aide de l’équipe hôte. Vous soumettez fièrement la demande de tirage. Alors, il ne se passe rien. Un jour plus tard – toujours aucune réaction. Vous vous demandez si l’équipe hôte a vu votre patch. Vous vous demandez où faire le meilleur ping à l’équipe sur une mise à jour. Ce silence est particulièrement frustrant pour les premiers contributeurs. Il existe plusieurs remèdes à cette situation – des remèdes qui n’ont pas besoin de connaissances de codage, mais qui nécessitent au moins quelques compétences de base en communication:

Faire expliciter les temps de réaction que l’équipe hôte peut attendre – par exemple dans la documentation de contribution.
Dès qu’une demande de tirage est reçue, communiquez le temps qu’il faudra pour recevoir des commentaires substantiels au lieu de laisser les contributeurs attendre.
Communiquer des façons pour les contributeurs d’entrer en contact avec l’équipe hôte et regarder la communication là-bas.

Aucune de ces tâches n’a besoin de compétences en écriture de code. Cela souligne le besoin de personnes au-delà de celles qui ont des connaissances en programmation. Il est de bonne pratique de considérer les personnes couvrant ces tâches comme engagées dans le projet InnerSource et de les inclure comme Trusted Committers également.

Les petits changements et correctifs sont faciles à gérer – ils sont rapides à examiner et souvent ne comportent pas beaucoup de risque lors de la fusion. Une façon d’aider les équipes hôtes est de prendre le temps de diviser les changements en petits morceaux. Assurez-vous de communiquer le contexte plus large auquel ces changements appartiennent.

Souvent, pour apporter des changements plus importants, il faut communiquer rapidement l’intention et le but. Il peut également être bénéfique de s’assurer que l’équipe participante et l’équipe hôte disposent de suffisamment de temps pour travailler ensemble au changement. Cela signifie que les gens qui établissent les priorités de l’équipe doivent penser au-delà de leur propre équipe lorsqu’ils hiérarchisent les changements. Toutefois, la coordination peut encore se faire de façon assez indépendante, car en général, seule l’équipe participante et l’équipe hôte sont impliquées.

Rarement, les équipes hôtes se heurtent au défi de recevoir trop de patchs d’équipes participantes. Dans ce cas, il aide à penser à déplacer des contributeurs de confiance au rôle Trusted Committer. En plus d’aider simplement avec les évaluations, le nouveau Trusted Committers peut aider avec le triage des numéros, mentorer de nouveaux contributeurs et autres.

Lorsqu’on est confronté à beaucoup d’intérêt pour les contributions, un facteur supplémentaire à prendre en considération lorsqu’on donne la priorité à l’aide au mentorat pour les contributeurs peut intéresser les contributeurs dans une relation à long terme avec l’équipe hôte. Plus il faut de temps pour le mentorat, plus il est probable que les contributeurs restent longtemps.

Dans la pratique, le partage de la propriété du composant avec des contributeurs très actifs a prouvé que le nouveau Trusted Committers a été engagé dans le projet sur une plus longue période. Habituellement, ils aident à tenir le volet à jour et à encadrer les nouveaux contributeurs bien après que la motivation initiale de la contribution a été abordée.

InnerSource et compétences en négociation

Codage et négociation ? Vous pouvez vous demander comment ces deux-là vont ensemble. En particulier pour les équipes hôtes InnerSource il aide à avoir quelques obstacles à l’esprit quand il s’agit de changer la négociation.

Comme on l’a vu dans le dernier segment de formation, les changements de code plus petits ont tendance à être acceptés plus rapidement. Pour l’équipe hôte, les avantages sont clairs et devraient être communiqués aux équipes participantes :

Ils sont plus faciles à examiner.
Ils ont moins d’impact – à la fois positif et négatif.
Ils sont plus rapides à intégrer.

Par conséquent, faire de petits changements dans une mode ad hoc entraîne généralement peu ou pas de friction. Ils sont un endroit doux pour les contributions en voiture et peuvent souvent être manipulés sans beaucoup de soutien de coordination. C’est généralement ainsi que commencent les contributions de InnerSource : Les ingénieurs en équipe commencent à collaborer sur de petits changements et trouvent que le travail est très facile et léger. Les changements plus petits sont aussi des changements qui ont tendance à se produire sans aucune escalade.

Cela peut amener les équipes à adopter un état d’esprit où InnerSource est uniquement pour les ingénieurs logiciels. Toutefois, ce modèle de travail ad hoc s’interrompt dès que la portée des contributions augmente. Si elle est réservée uniquement aux ingénieurs en logiciels, dans le pire des cas, même avec le recul d’autres rôles dans les équipes, cela signifie que les escalades se produiront beaucoup plus souvent. Pour les modifications ayant une portée plus large, d’autres rôles dans l’équipe participante et dans l’équipe hôte doivent être au courant du travail de InnerSource et doivent apporter leurs compétences à la table :

Ensemble, les deux équipes doivent trouver un bon moment pour travailler sur la contribution. Si l’équipe hôte n’a pas le temps de guider l’équipe contributrice, elle risque davantage d’être frustrée faute de soutien. Ils peuvent également être plus susceptibles de développer une solution qui est susceptible d’avoir besoin de beaucoup de retravail entraînant la frustration pour tous les participants. Si l’équipe participante n’a pas le temps de se concentrer sur les cycles de perfectionnement des contributions pour les changements peut devenir trop long et les interruptions trop élevées.
Avant qu’un code source ne soit écrit, le contributeur et l’équipe hôte doivent comprendre si les changements s’inscrivent dans la vision du projet InnerSource. Idéalement, cela signifie aussi que l’expertise technique et commerciale doit se réunir, de préférence sur le même canal de communication où chacun peut participer. Il en résulte souvent des négociations sur l’opportunité d’apporter des modifications au projet InnerSource – la maintenance étant ensuite assurée par l’équipe hôte. Cela peut signifier que les participants doivent préciser quelle est la valeur pour chacun, mais aussi si et comment l’équipe qui contribue peut aider l’équipe hôte à réduire le fardeau de maintenance.

« Il suffit d’écrire le code et de nous envoyer votre patch » – semble assez facile. Sauf en réalité, cela n’est vrai que pour les changements les plus insignifiants. En particulier, des changements plus importants nécessitent une coordination afin que toutes les parties concernées aient le temps de participer. Sinon, des temps d’attente plus longs sont attendus. Traverser les frontières de l’équipe signifie aussi souvent des changements subtils dans la culture de la communication. Les personnes qui sont de puissants communicateurs peuvent aider à combler ces lacunes en traduisant entre les équipes en cas de malentendus.

Contrairement aux équipes travaillant uniquement sur le code local InnerSource, les équipes hôtes doivent s’assurer que leur feuille de route et leur vision sont communiquées à tous les contributeurs potentiels. En outre, l’équipe hôte doit s’assurer que les exigences de conception, d’architecture et de performance sont explicites et claires pour tous ceux qui travaillent sur la base de code – y compris les contributeurs occasionnels. Cette transition est particulièrement difficile pour les équipes qui travaillent dans des contextes locaux très cohérents. Essentiellement tout ce qui dans une équipe très locale est clair doit implicitement être rendu transparent et explicite. À court terme, cela coûte du temps – à long terme, cela aide les contributeurs à accélérer plus rapidement en exigeant moins de soutien de l’équipe hôte. Une chose qui a été prouvée avec succès dans Open Source est de rendre facile pour les contributeurs de marcher le bon chemin. Cela comprend des contrôles de qualité automatisés qui échouent au moment de la construction. Bien que le temps nécessaire pour écrire et maintenir ceux qui prennent le travail hors des épaules de l’équipe hôte que les problèmes évidents sont mis en évidence automatiquement.

Une différence avec InnerSource par rapport aux négociations interéquipes régulières est l’occasion de penser hors de la boîte : Imaginez un contributeur Bob qui a besoin d’un changement très complexe dans le projet InnerSource maintenu par Alice. Bob commence juste à comprendre la base de code et aurait du mal à la comprendre par lui-même. En outre, le mentorat au cours du processus prendrait beaucoup de temps à Alice. Cependant, Alice a plusieurs caractéristiques hautement prioritaires mais faciles à mettre en œuvre sur son arriéré. Que faire si Bob a retiré une partie de ces problèmes de son arriéré et les a mis en œuvre – en retour Alice a le temps de travailler sur le changement dont Bob a besoin? Dans un souci de transparence, ces accords devraient être expliqués à la fois à l’équipe hôte et à l’équipe qui les contribue. Sinon, ils auront du mal à comprendre pourquoi Bob et Alice ne travaillent pas sur les changements dont chacun de leurs clients a besoin.

Pour un autre exemple, imaginez une équipe hôte qui travaille sur un projet InnerSource très populaire. Il est probablement au centre des affaires de l’entreprise. Avec le temps, de plus en plus de contributeurs sont capables d’apporter les changements dont ils ont besoin pour transformer l’équipe hôte en un goulot d’étranglement d’examen. Pour faire face à cette question, une perspective claire des priorités opérationnelles globales et de l’importance des équipes participantes aide à comprendre les correctifs à prioriser et empêche les membres de l’équipe hôte de se concentrer constamment. Dans une prochaine étape, l’équipe hôte doit penser à augmenter le nombre de Trusted Committers travaillant sur ce projet InnerSource. Comme nous l’avons déjà mentionné, une option pourrait consister à inviter les personnes engagées dans le projet qui relèvent d’un secteur d’activité différent.

En particulier, lorsque les équipes d’accueil sont confrontées à un grand nombre de contributions assez complexes, elles doivent comprendre où le temps d’investir pour encadrer les contributeurs est un investissement digne. Plus il faudra de temps pour le mentorat, plus il sera probable que ces contributeurs auront le temps de rester longtemps.

Options de propriété partagée

« Si tout le monde en est propriétaire, personne n’est responsable. » Les organisations traditionnelles préfèrent avoir un point de contact unique en cas de problèmes. D’un autre côté, permettre à tout le monde d’apporter des changements entraînera certainement un désordre qui ne peut plus être maintenu.

Sur la base de cette observation, chaque projet InnerSource dispose d’une équipe dédiée de Trusted Committers. L’intérêt pour le maintien d’un projet InnerSource est souvent motivé par un intérêt personnel éclairé : une équipe comprend qu’elle a elle-même besoin du projet InnerSource pour répondre aux besoins de ses clients et comprendre que l’ouverture du projet aux contributions peut répartir la charge de travail pour faire avancer le projet. L’ouverture d’un projet pour les contributions ne signifie pas que Trusted Committers doit accepter toutes les soumissions. C’est l’équipe de Trusted Committers qui fixe la mission et les objectifs du projet. Ils sont alors en mesure d’orienter et de décider de l’acceptation du changement en conséquence.

« Les commiteurs fiables sont responsables d’un projet InnerSource. Ils examinent les soumissions et les mentors.

C’est un résumé très simpliste de ce à quoi ressemble le rôle d’un Trusted Committer. En réalité, une des premières questions porte souvent sur la nécessité d’accepter chaque contribution. En particulier, lorsque les contributeurs ont déjà investi beaucoup de temps dans les contributions peut devenir frustré en entendant que leur travail était en vain. Les compétences en communication sont importantes pour que les contributeurs sachent à peu près à quoi ressemble la feuille de route du projet InnerSource. Ils sont également nécessaires pour s’assurer que les contributeurs savent partager l’intention et progresser très tôt afin d’éviter de dépenser beaucoup de travail sans résultats. Enfin, le rejet des contributions nécessite de très bonnes compétences en communication. Pour faire court : Même si vous n’écrivez pas de code source vous-même, votre support est nécessaire pour communiquer clairement la vision du projet InnerSource, afin d’aider éventuellement lorsque les contributions doivent être rejetées. Un autre aspect qui devient plus important à mesure que le projet InnerSource devient plus populaire : l’examen et le mentorat deviennent plus intensifs et doivent être programmés explicitement dans la journée. Cela a une incidence sur la planification générale des capacités et ne devrait pas se produire « au radar ».

D’autre part, pour les contributeurs, il est important que l’examen du code ne soit pas une dernière étape de la qualité. Il s’agit plutôt d’un moyen pour guider continuellement les contributeurs à travers le processus de développement de code conduisant idéalement à de meilleurs résultats plus rapidement. Pour que cela fonctionne dans la pratique, il doit y avoir du temps et de l’espace pour le team building – mais au-delà des frontières traditionnelles de l’équipe. Avoir au moins une compréhension vague des différentes cultures dans les équipes rend les malentendus beaucoup moins probables et le processus de contribution beaucoup plus fluide.

En particulier, lorsque les équipes d’accueil sont inondées de contributions, les chefs de projet qui ne se concentrent autrement que sur leur équipe locale doivent adopter une perspective plus globale : * Aider l’équipe à comprendre différentes priorités pour les contributions entrantes en fonction de la stratégie globale de l’entreprise. Souvent, toutes les contributions ne sont pas aussi urgentes. * Une autre façon d’aider l’équipe est de prendre en charge des tâches comme le tri des questions, le traitement des premières réponses aux contributeurs et l’orientation de contributions plus importantes tout au long du processus. Vous pouvez aider votre équipe en communiquant avec les contributeurs si l’intégration du changement prend un peu plus de temps. * Face à des demandes de contribution plus importantes, les équipes peuvent bénéficier de l’aide pour négocier avec d’autres équipes le meilleur moment pour travailler sur ces contributions. Souvent, cela est encore beaucoup plus rapide que votre équipe faisant tout le travail sur leur propre. En particulier la première fois que les contributeurs peuvent avoir besoin d’une certaine main – en particulier pour des changements plus importants. La coordination du moment autour de ce mentorat peut être une grande aide pour votre équipe.

« Mais nous pourrions simplement nous en tirer définitivement » … une idée fausse où les équipes invitées potentielles croient que la simple copie du code serait plus rapide.

À court terme, c’est vrai. À long terme, cela signifie un entretien supplémentaire. En tant que chef de projet, vous pouvez aider votre équipe à comprendre pourquoi contribuer aux changements au projet sur lequel vous dépendez est dans le meilleur intérêt de l’entreprise : Moins de travail en général. La maintenance à long terme est assurée par l’équipe hôte.

« Nous utilisons des requêtes de tirage pour développer notre composant – donc nous utilisons InnerSource quotidiennement ». Bien que l’utilisation des demandes de tirage et des examens soit un élément crucial, elle n’est que le point de départ des projets InnerSource. Ce n’est pas parce que deux projets dépendent des demandes de tirage d’utilisation sur une base quotidienne que leur ouverture aux contributions team-externes est la même.

InnerSource est livré avec différentes meilleures pratiques. Afin d’éviter la confusion et la frustration pour les contributeurs, il est important que les équipes hôtes définissent pour leur projet InnerSource quel modèle de gouvernance elles souhaitent adopter. Comme dans Open Source, ces niveaux de gouvernance peuvent varier considérablement.

Dans le InnerSource Commons nous fournissons un modèle InnerSource qui définit au moins trois niveaux de gouvernance : * Le code source est visible pour tout le monde – mais l’équipe n’a pas le temps de guider les contributeurs. De l’extérieur cela peut ressembler à votre projet quotidien InnerSource. Rendre le refus de mentorer et d’accepter des contributions explicites, mais évite la confusion des collègues qui tentent d’interagir avec le projet par l’intermédiaire des moyens InnerSource. Au lieu de cela communique à ceux qui dépendent du projet que seules les requêtes de fonctionnalités et les rapports de bogues peuvent être traités par l’équipe. Essentiellement, cela signifie revenir à un projet de développement de logiciel traditionnel régulier. * Code source est visible pour tout le monde – plus l’équipe de Trusted Committers a réservé du temps pour le mentorat des contributeurs. Pour ces projets, les patchs et les demandes de tirage sont les bienvenus. L’équipe de Trusted Committers s’assure que la communication pertinente du projet se déroule dans un canal écrit, archivé, consultable et linkable. L’équipe veille également à ce que les décisions pertinentes du projet soient prises là où les contributeurs peuvent les voir et les suivre. La prise de décision finale repose cependant sur l’équipe de Trusted Committers – et devenir un Trusted Committer du projet est lié à travailler pour l’équipe de projet initiale. * Comme ci-dessus – mais l’équipe de Trusted Committers est ouverte à l’idée de partager l’accès écrit. Cette approche nécessite un processus permettant d’établir suffisamment de confiance avec les contributeurs pour que l’équipe de Trusted Committers puisse partager l’accès écrit. Ceci est particulièrement utile lorsqu’il existe une relation à long terme avec les contributeurs. L’accès par écrit partagé peut supprimer le goulot de bouteille d’examen. * Dans la dernière étape, l’équipe de Trusted Committers est également prête à partager le contrôle sur qui obtient l’accès par écrit prochain ainsi que la vision du projet et la mission. Bien que cela entraîne souvent le plus haut niveau d’engagement de la part des contributeurs, il faut aussi un haut niveau de coordination pour franchir les frontières des équipes. Elle exige également le plus haut niveau de transparence lors de la prise de décisions concernant le projet.

Pour résumer chaque niveau de gouvernance, il faut adopter une approche différente en matière de collaboration et de coordination. * Le partage accru accroît le besoin de communication et de coordination.

Ce qui est implicitement clair pour les membres de l’équipe est mieux explicite et documenté si le projet souhaite encourager les contributions. Sujets comme * Temps de réponse à prévoir lors de la soumission des changements, * canaux de communication à utiliser lors de la prise de contact avec l’équipe de Trusted Committers, * canaux de communication à utiliser lors de l’essai de suivre le projet en tant que contributeur * niveaux de gouvernance à attendre du projet sont tous des sujets que l’équipe hôte entière doit accepter et communiquer aux contributeurs.

Le partage accru des responsabilités pour les projets InnerSource a également une incidence sur les examens du rendement. Dans les cadres hiérarchiques, ceux-ci considèrent souvent les contributions locales à l’équipe. Les contributeurs InnerSource commencent cependant à avoir un impact en dehors de leurs propres équipes. InnerSource Trusted Committers a un impact sur les équipes qui peuvent être en dehors de la portée de leur propre équipe. Cela signifie que les gestionnaires de ligne directe perdent un certain niveau de contrôle. Ils perdent également une surveillance directe. Il faut donc tenir compte des réactions des équipes potentiellement éloignées.

Une bonne pratique courante pour les équipes interfonctionnelles est une configuration « vous la construisez, vous la exécutez ». Avec les contributions potentielles des utilisateurs en aval, cette meilleure pratique semble se rompre. Il existe plusieurs façons d’utiliser InnerSource dans ce contexte :

L’option numéro un est de passer à une plus grande modularisation et de collaborer uniquement sur les pièces qui sont les mêmes entre les équipes et garder les opérations locales.
Alternativement travailler avec des tests contractuels pour éviter les ruptures d’API.
Travailler avec les accords de niveau de service interne, faire des contributeurs s’inscrire aux périodes de garantie pour éliminer la crainte de l’équipe hôte que les contributions brisent les systèmes de production.

Relation avec les sources ouvertes

InnerSource est l’application des meilleures pratiques de collaboration Open Source dans les limites des sociétés. Cela facilite la compréhension de deux aspects de l’Open Source pour les équipes à travers des parallèles avec InnerSource:

Comme dans InnerSource, les projets Open Source ont différents niveaux de gouvernance. Tous les projets Open Source ne sont pas créés à égalité : alors que certains groupes ne publient que le code source, ne s’attendent à aucune interaction, d’autres veulent que les utilisateurs en aval deviennent actifs et soumettent des correctifs. D’autres projets ont mis en place des processus permettant de partager l’impact sur le projet Open Source. Comprendre ces niveaux de gouvernance signifie que décider quel projet open source utilisera en interne prendra également en considération la gouvernance Open Source. Un utilisateur en aval d’un projet InnerSource aura appris à évaluer correctement l’équilibre entre un mouvement rapide mais incapable d’influencer un projet contre un mouvement plus lent mais capable d’influencer un projet ensemble.

Travailler dans des projets InnerSource aide les équipes à pratiquer ce que signifie partager les coûts et les efforts pour construire des plateformes ensemble. Partager le travail entre les équipes aide à innover plus rapidement dans l’ensemble: les équipes de produits avec différents domaines d’intérêt peuvent unir leurs forces pour développer une plateforme de base nécessaire plus rapidement et partager la charge de maintenance résultante.

La même dynamique conduit également plusieurs projets Open Source. Comprendre cela signifie que la participation à ces projets est naturelle pour toute équipe ayant une expérience avec InnerSource. Sachant que la dynamique de l’expérience pratique permet également aux équipes de reconnaître plus facilement quels projets open source sont développés conformément à ces principes. Généralement, cette compréhension a aussi un impact sur lequel les équipes de projets Open Source décident d’utiliser en interne.

Les fonctionnalités de la plate-forme dont de nombreuses équipes ont besoin peuvent alors être créées en collaborant au lieu de les mettre à nouveau en œuvre localement. Cela facilite la compréhension du concept de la façon dont l’effort de partage peut aider à rendre le gâteau plus grand pour tout le monde et comment il peut aider à conduire les normes de l’industrie si fait d’une manière open source au lieu de seulement interne.

En termes de mécanique, les deux pratiques sont très similaires. La principale différence est la visibilité des projets : Pour InnerSource qui est limité à la société, pour Open Source ils sont publics.

Ce qui ressemble à une petite différence sur le papier est une énorme différence dans la pratique. Going Open Source signifie que chaque message est visible publiquement et potentiellement archivé pour toujours. Cette implication peut être très inconfortable en particulier pour les employés qui ne sont pas habitués à cette façon de travailler. En outre, toutes les actions étant publiques, elles sont également accessibles au public et ne peuvent plus être examinées par des experts en communication d’entreprise. Des artefacts produits de la même manière sont disponibles pour examen public en ce qui concerne la conformité des licences, la sécurité et d’autres produits similaires – par exemple pour les concurrents, pour les nouvelles embauches potentielles, pour les clients.

D’autre part, il ouvre également la porte à la collaboration avec d’autres en dehors des murs d’une société – pris à l’extrême qui peut conduire à la co-opetition où les concurrents unissent leurs forces pour construire une plate-forme technique commune, innovant et rivalisant entre eux en plus de cela.

L’ouverture des sources réduit également les incidences fiscales de la collaboration au-delà des frontières des entités juridiques. Alors que le transfert en tant que sujet chaud pour de nombreux efforts de InnerSource il n’est pas pertinent pour tout projet Open Source.

Alors que « qu’en est-il de l’édition de projets comme Open Source » est souvent la première pensée quand on parle de devenir actif dans l’espace Open Source. Lorsqu’il est expérimenté avec InnerSource, il devient clair que la publication de projets entiers n’est qu’une façon d’être actif dans l’espace open source.

Au lieu de cela, il est beaucoup plus naturel d’adopter un point de vue de soi éclairé : * Lorsque les équipes utilisent certaines dépendances d’Open Source dans des parties vitales de leurs composants, il est important de s’assurer d’être impliquées en amont – même si le seul objectif est de comprendre la future feuille de route du projet. * Lorsque les équipes ont besoin de changements dans les projets open Source dont elles dépendent, l’expérience avec InnerSource rend évident l’avantage de participer en amont : il ne s’agit pas seulement d’un état d’esprit « partager est attentionné » – mais il a des avantages économiques évidents lorsque les équipes participantes ont des frais d’entretien fortement réduits si leurs changements sont intégrés en amont.

Reprenant un autre pas en arrière même la décision du projet Open Source d’adopter et d’utiliser en interne sera influencée par l’expérience InnerSource d’une équipe : * InnerSource forme des équipes pour comprendre ce qu’il faut chercher en termes de collaboration et de communication – de l’expérience personnelle ils comprendront pourquoi il est important pour le projet d’avoir des canaux de communication clairs, archivés et consultables. Ils comprendront également pourquoi il est important que chaque grande décision de projet soit prise sur ces canaux de communication. * Comprendre les différents niveaux de gouvernance dans les équipes InnerSource sont bien préparés à comprendre les implications des projets Open Source fonctionnant selon différents niveaux d’ouverture.