Introduction

Consultez l’introduction pour en savoir plus sur les types de problèmes où InnerSource peut aider, comment le faire, les types d’avantages que vous pouvez attendre en participant, et les principes sous-jacents qui font que tout fonctionne.

Introduction

Ce chemin d’apprentissage donne une introduction à InnerSource. InnerSource est l’application de pratiques et de principes open source au développement de logiciels au sein de l’entreprise. Le logiciel InnerSource reste propriétaire de l’entreprise, mais il est ouvert à quiconque pour l’utiliser et y contribuer. Cette stratégie permet une collaboration large et efficace, produisant des logiciels qui répondent aux besoins changeants de ses nombreux intervenants internes.

Ce sentier d’apprentissage enseigne à reconnaître les situations qui sont de bons candidats pour InnerSource. Nous allons décrire à un niveau élevé comment InnerSource peut aider dans ces situations. Vous allez vous familiariser avec les termes partagés utilisés lors de la discussion de InnerSource. Nous énumérons également les principes clés sur lesquels repose InnerSource et les avantages constatés lorsqu’il est appliqué efficacement.

Quels problèmes InnerSource résout-il?

InnerSource encourage et récompense la collaboration et la réutilisation de code avec n’importe qui, indépendamment de leur position dans une structure organisationnelle de l’entreprise. Cette approche diffère de ce qui est vu dans les organisations traditionnelles où les idées et les produits de travail tendent à rester piégés dans les limites de la hiérarchie interne de l’entreprise et de ses silos. Laissez-nous explorer une situation qui donne un exemple de cette idée.

Imaginez que deux équipes de la même entreprise livrent des logiciels séparés avec un logiciel d’équipe en fonction de celui de l’autre. Un exemple pourrait être une expérience utilisateur qui dépend d’un service API pour récupérer des données pour l’affichage. Cette situation est courante dans une grande entreprise où une seule équipe produisant des logiciels peut avoir des dizaines ou des centaines de consommateurs.

Lorsque les équipes consommatrices ont besoin de nombreuses caractéristiques, elles ont normalement des exigences et un processus de hiérarchisation pour décider sur quelles caractéristiques elles travailleront. Pour les demandes de fonctionnalités critiques qui ne sont pas prioritaires pour le travail immédiat, l’équipe consommatrice peut généralement choisir l’une des trois options, chacune d’entre elles vient avec ses propres inconvénients.

1. Attendez.. L’équipe consommatrice peut ne rien faire sans la fonctionnalité demandée. Cette option nécessite le moins de travail de leur côté. Selon le bénéfice de la demande de fonctionnalité, l’attente peut être très bien. Cependant, il peut venir avec des quantités réelles de douleur, surtout si la fonctionnalité demandée n’est jamais livré.
2. Solutions envisagées. Une équipe consommatrice qui ne veut pas attendre peut faire un travail supplémentaire ailleurs pour compenser l’absence de leur fonction demandée. Ce travail supplémentaire peut venir comme changement dans le projet de consommation. Sinon, ils peuvent créer un nouveau projet qui répond à leurs besoins et remplace leur utilisation de tout ou partie du système de production de l’équipe (code/projet duplication). Cette stratégie permet à l’équipe consommatrice d’obtenir la fonctionnalité demandée uniquement par ses propres efforts. Il vient avec plusieurs inconvénients, cependant.
   1. Tout travail effectué par l’équipe consommatrice reste indisponible pour tout autre consommateur ayant la même demande de fonctionnalité.
   2. L’équipe consommatrice s’est par inadvertance engagée pour le fardeau à long terme de maintenir le nouveau code écrit, qui n’est pas dans le domaine de leurs compétences de base.
   3. L’entreprise tout entière acquiert des projets en double et code dans le même espace de problème.
3. Escalat. Il se peut que l’équipe consommatrice ne prenne pas « non » pour une réponse et, au contraire, plaide auprès de quelqu’un de la hiérarchie de gestion des producteurs pour influencer (ou forcer) l’équipe productrice à faire le travail. Cette option semble attrayante pour l’équipe consommatrice parce qu’elle obtient la fonction demandée sans faire le travail pour la mettre en œuvre ou la maintenir. Cependant, c’est toujours un problème pour l’équipe, car elle détourne nécessairement une partie de son attention et de son travail vers la tâche non-ingénierie de l’escalade. De plus, cette option n’a pas d’échelle car il n’y a que tellement de fois qu’un consommateur peut augmenter les demandes de fonctionnalités avant de nuire à sa crédibilité. L’escalation est tout aussi perturbatrice (et plus encore) pour les membres de l’équipe de production, qui sont retirés de leur flux de travail normal et de leurs méthodes de hiérarchisation pour faire face à la demande accrue de fonctionnalités.

Cette discussion ouvre la voie à InnerSource. InnerSource s’applique au même type de situation lorsqu’une équipe consommatrice n’est pas en mesure d’obtenir ce dont elle a besoin via une demande de fonctionnalités. InnerSource fournit un moyen pour les équipes de gagner les avantages deAttendez., des travauxetescaladesans les inconvénients associés.

InnerSource apporte également une amélioration générale à la culture d’ingénierie car les ingénieurs ont la chance de travailler avec une plus grande variété de nouvelles technologies et de personnes. Les développeurs se guident et apprennent les uns des autres en partageant des idées et des solutions à travers les silos organisationnels. Les ingénieurs et les équipes peuvent réutiliser des solutions internes aux problèmes de produits, ce qui leur permet de se concentrer sur des flux de travail de plus grande valeur pour l’organisation.

Comment fonctionne InnerSource?

Disons que l’équipe A utilise des logiciels produits par l’équipe B. L’équipe A soumet une demande de fonctionnalités à l’équipe B, mais l’équipe B n’est pas en mesure de mettre en œuvre cette fonctionnalité à temps pour l’équipe A. Dans un réglage InnerSource, si l’équipe A ne peut pas obtenir cette requête de fonctionnalité, elle soumet une requête de tirage à la place. C’est-à-dire que l’équipe A implémente la fonctionnalité directement dans le logiciel de l’équipe B.S. et soumet une demande de tirage avec les changements de code. Les partenaires de l’équipe B examineront et accepteront le code soumis.

Dans cet exemple, nous appelons l’équipe AInvitééquipe et équipe BHôtel’équipe. Les termesInvitéetHôtesuggérer une situation analogue à celle de recevoir un visiteur à la maison. Dans cette situation, la plupart des gens veulent être un bon hôte. Ils veillent à ce que les choses restent propres et rangées en prévision de l’arrivée de leurs invités. Les visiteurs sont accueillis à la porte et invités. Ils peuvent utiliser les caractéristiques et les services publics qui sont dans les zones publiques de la maison. Il peut y avoir quelques règles de la maison que les invités sont invités à suivre. De même, la plupart des clients veulent montrer du respect pour la maison et leur hôte. Ils sont prudents avec les articles dans la maison et suivent les règles pour la durée de leur séjour. Ils peuvent espérer ou attendre une invitation de retour aussi longtemps qu’ils ont été courtois et polis. Ces concepts autour d’une visite à domicile sont une métaphore de l’attitude et des comportements que les équipes devraient apporter comme un hôte l’un l’autre faisant une contribution invitée à la base de code.

Voyons de plus près comment la mécanique du processus InnerSource peut fonctionner. Pour aider dans cette explication, nous allons nommer quelques personnes clés dans les équipes d’invités et d’hôte. Premièrement, responsable produit détermine la fonctionnalité que l’équipe hôte accepte comme contribution. Les Contributeur est la personne de l’équipe invitée qui soumet la contribution au code pour examen par l’équipe hôte. Les Trusted Committer représente l’équipe d’accueil pour fournir en temps opportun tout soutien et mentorat dont le contributeur a besoin pour soumettre avec succès la demande de tirage. Sur les petites, les efforts de base une seule personne remplit souvent les deux le propriétaire du produit et les rôles de commiteur de confiance.

Avec ces définitions, voici les grandes lignes d’une contribution InnerSource.

• L’équipe invitée ou le contributeur demande une fonctionnalité de l’équipe hôte.
• Le propriétaire du produit s’assure que des histoires d’utilisateurs représentant la demande de fonctionnalités sont créées, soit par les membres de l’équipe invitée, soit par l’équipe hôte. Ces récits devraient décrire la caractéristique demandée en termes acceptables pour l’équipe invitée. Ils énumèrent également tous les détails de l’équipe hôte sur la façon dont la fonction doit être livrée pour que le travail soit accepté. Des exemples de ces détails incluent les contraintes d’architecture, les conventions de codage, les usages de dépendance, les contrats de données, etc.
• Soutenu par le commiteur de confiance, le contributeur soumet la demande de tirage pour mettre en œuvre la fonctionnalité demandée.

Notez que ces étapes ne supposent pas un système spécifique pour l’organisation générale d’une équipe. InnerSource suppose que les équipes ont déjà des méthodes d’organisation existantes et fournit un cadre pour les utiliser pour travailler ensemble là où il y a une équipe invitée qui souhaite contribuer au code d’un hôte.

Cette option fonctionne bien pour l’équipe d’invités car ils obtiennent la fonctionnalité dont ils ont besoin lorsqu’ils en ont besoin sans assumer le fardeau à long terme de la maintenance de la solution. Il fonctionne pour l’équipe d’accueil parce qu’elle est capable d’améliorer l’échelle et de servir ses consommateurs. Il fonctionne pour l’entreprise en général parce que les solutions aux problèmes partagés finissent dans des endroits partagés et centralisés où tout le monde peut les utiliser. Plus de temps d’ingénierie reste concentré sur la production de code qui résout les problèmes de l’entreprise plutôt que la mécanique du processus de négociation et d’escalade des fonctionnalités.

• L’équipe hôte peut être représentée parÉquipe de basemodèle.
• LesTrusted Committermodèle.

Quels sont les avantages de InnerSource?

La collaboration via InnerSource présente de nombreux avantages. InnerSource donne à une entreprise une stratégie évolutive pouréquipes invitées pour obtenir des demandes de fonctionnalités quand elles en ont besoinsans la charge à long terme de l’entretien. L’entreprise dans son ensemble gagne comme le temps des équipes invitées est mis en code que d’autres peuvent utiliser.

Bien que ce résultat soit un avantage éclatant de InnerSource, il existe de nombreux avantages pour les hôtes qui reçoivent des contributions régulières de InnerSource. Rappelons que, dans le cadre du processus InnerSource, le propriétaire du produit de l’équipe hôte convient dès le départ que les fonctionnalités fournies sont bonnes et souhaitables. InnerSource permet à l’équipe hôte de recevoiraider à créer un meilleur produitpour ses consommateurs!

InnerSource fournit à l’équipe hôte une stratégie évolutivepour satisfaire à des quantités variables de fonctionnalités demandées à ses nombreux consommateurs. Compte tenu de la capacité fixe des membres à temps plein de l’équipe hôte, il est probable que, parfois, les feuilles de route combinées de ses consommateurs exigeront beaucoup (ou même déraisonnablement) de travail à faire dans les produits de l’équipe hôte. Sans InnerSource, cette situation conduit facilement à une équipe stressée et surmenée qui traite de nombreuses demandes de fonctionnalités s’est intensifiée auprès de ses dirigeants.

Toutefois, si l’équipe hôte fonctionne via InnerSource, les ressources techniques nécessaires pour construire ces fonctionnalités apparaîtront proportionnellement à leur importance sous la forme de contributeurs invités.InnerSource devient un multiplicateur de forcequi permet à l’équipe hôte d’agir temporairement plus grand que sa taille réelle en période de forte demande. Lorsque la demande a pris fin, le débit de l’équipe revient à des niveaux normaux, le tout sans microgestion du nombre de membres de l’équipe ou des éléments de travail. InnerSource permet au temps d’ingénierie de circuler organiquement là où l’organisation en a besoin à un moment donné.

Au-delà du travail brut que l’équipe hôte est capable d’accomplir dans son système, les contributions régulières InnerSource donnent à l’équipe hôtede meilleures exigences et l’alignement des priorités avec tous ses consommateurs. Une équipe d’accueil peut faire ses meilleures exigences en rassemblant le travail qu’elle produit, mais lorsque le consommateur lui-même est celui qui soumet le travail, les chances sont beaucoup plus grandes que le changement résultant est aligné sur ce dont le consommateur a besoin. Bien que ce ne soit peut-être qu’une seule équipe invitée qui soumet le changement, cette équipe est probablement représentative de nombreux autres consommateurs.

En plus de cet alignement, il existe également une formation et une éducation générales de contributeurs comme ils travaillent avec et apprendre de des commiteurs de confiance. Cette interaction aide les contributeurs à apprendre et à grandir dans leur carrière, ce qui satisfaction professionnelle plus élevée. La documentation du projet s’améliore pour permettre ces contributions à l’échelle. Les intervenants se sentent concernés par le projet de l’équipe hôte. C’est quelque chose qu’ils recommandent à leurs collègues ou de nouvelles équipes qu’ils rejoignent. Ils comprennent mieux le projet et sont en mesure de répondre à des questions à ce sujet à d’autres, en allégeant l’équipe hôte d’une partie de ce fardeau. Plus de personnes contribuent à un projet naturellement polliniser les idées de toute l’entreprise. Cet apprentissage et cet alignement entre les équipes au fil du temps décomposer les silos traditionnels de l’entreprise.

Principes de InnerSource

Chaque entreprise, équipe, projet et individu est différent. De ce fait, la façon exacte dont fonctionne le concept de InnerSource variera d’une situation à l’autre. Cependant, quatre principes fondamentaux forment le socle de toute instance réussie de InnerSource. Ces principes s’inspirent de projets open source réussis et sont nécessaires pour que InnerSource puisse réaliser les avantages décrits précédemment.

Les principes sont les suivants :

• Ouverture
• Transparence
• Mentorat prioritaire
• Code volontaire Contribution

Voyons chacun de ces principes plus en détail.

La configuration d’un projet ouvert permet de contribuer sans friction. Les projets doivent être découverts et bien documentés par l’intermédiaire de fichiers README.md et CONTRIBUTING.md dans la racine de la repo. Toute personne au sein d’une organisation devrait être en mesure de trouver un projet désiré et d’aller de l’avant sans trop de conseils directs de la part des membres de l’équipe hôte. Les coordonnées de l’équipe hôte devraient être courantes avec autant de canaux que cela est logique pour le projet. Les intentions de l’équipe hôte d’accepter les contributions de InnerSource à leur projet devraient être partagées par les voies organisationnelles pertinentes pour sensibiliser le public. Particulièrement dans les petits paramètres, vous pouvez vouloir établir une « diffusion » régulière sur le travail InnerSource que votre équipe fait. Dans des contextes plus grands, cependant, une telle diffusion peut créer beaucoup de bruit, et il peut être plus approprié de s’assurer que le projet est découvrable dans un outil facile à utiliser. Rappelez-vous, l’objectif est la sensibilisation utiliser les canaux appropriés qui fonctionnent dans VOTRE entreprise.

La liste ci-dessus n’est nullement exhaustive. L’ouverture du projet sera généralement directement liée à la réussite d’un projet en termes de InnerSource. Plus elle est ouverte, moins de barrières sont mises en place pour les contributeurs potentiels. Moins elle est ouverte, plus il devient difficile pour quiconque de contribuer.

Pour que les équipes invitées puissent contribuer de façon significative à un projet, l’équipe hôte doit êtretransparent. Cela signifie que les équipes invitées devraient pouvoir comprendre :

• Le projet et sa direction
• Caractéristiques en suspens
• Progrès réalisés en ce qui concerne les caractéristiques requises
• Prise de décision de l’équipe hôte

Dans la mesure du possible, ces éléments devraient être communiqués clairement et en détail, depuis la définition interne des éléments par les équipes jusqu’aux scénarios spécifiques au projet. Cette communication devrait être faite d’une manière qui puisse être facilement interrogée et comprise par ceux qui ne font pas partie de l’équipe hôte.

Mentorat de l’équipe hôte à l’équipe invitée via des commiteurs de confiance est un aspect clé de InnerSource. Contributeurs sur les équipes invitées sont reclassées afin qu’elles comprennent assez au sujet de l’équipe hôte du projet / repo pour le changer avec succès. Dans le processus de le faire, ils viennent à mieux comprendre le système logiciel de l’équipe hôte en tant que consommateur général et ambassadeur pour le projet / logiciel. Ce contributeur individuel peut, avec le temps et l’expérience, jouer un rôle plus large dans le projet en tant qu’auteur de confiance.

Il est essentiel que ce mentorat pour les contributeurs soitPrioritépar l’équipe hôte. L’équipe hôte devrait s’efforcer de prendre le temps de guider les collaborateurs de l’équipe invitéeau moment où le contributeur en a besoinPar opposition à quand il est pratique pour l’équipe hôte. Parfois, il peut s’agir d’un changement de culture pour les ingénieurs de l’équipe hôte de passer du temps à aider les autres à coder plutôt que de simplement se codifier. Ce mentorat est précieux tant pour le donateur que pour l’hôte, et il vaut la peine de faire bien. Il s’avère mutuellement bénéfique à long terme. En améliorant le code, le contributeur forge ou améliore les relations au sein d’une organisation qui n’existe peut-être pas autrement. Open source reconnaît facilement ce point et le considère comme un honneur d’obtenir le statut de commiteur de confiance sur un projet.

Le premier motVolontairesignifie que l’engagement en InnerSource des équipes invitées et hôtes se produit de leur propre gré. L’équipe invitée fait un don volontaire du code à l’équipe hôte et l’équipe hôte l’accepte volontairement. Cela signifie que chaque équipe doit être certaine que leur participation ajoute de la valeur aux objectifs des autres. Jamais une équipe d’accueil n’est requise pour accepter une contribution qui n’est pas en adéquation avec sa mission globale. Jamais une équipe d’invités n’est tenue de présenter une contribution qui n’aboutit finalement à leur propre mission et à leurs propres priorités.

Le motCodesouligne que la collaboration entre l’invité et l’hôte va jusqu’au code. L’implication des invités dans les questions d’ouverture, la mise à jour des exigences, la fixation des documents, etc. est bonne, mais la collaboration doit atteindre jusqu’à soumettre le code pour obtenir tous les avantages dont nous avons discuté.

Conclusion

Dans ce parcours d’apprentissage, nous avons donné une introduction à InnerSource. InnerSource applique les meilleures pratiques et principes en libre accès au développement interne de logiciels. Il donne une option supplémentaire aux consommateurs lorsqu’ils produisent des équipes ne sont pas en mesure de fournir une demande de fonctionnalités nécessaires. Le succès de InnerSource implique Propriétaire du produit et commiteur de confiance des équipe hôte ainsi qu’un contributeur des équipe invitée. Fait efficacement, InnerSource apporte de nombreux avantages aux deux équipes participantes. Ils sont les principes clés sur lesquels fonctionne efficacement InnerSource code volontaire et Un mentorat prioritaire.

Bien que cette formation contienne un aperçu de haut niveau de InnerSource, il y a beaucoup d’autres détails utiles pour faire en sorte que InnerSource fonctionne réellement pour votre équipe. Si vous souhaitez rester connecté à la conversation en cours autour de InnerSource et de ses meilleures pratiques, alors rejoignezle InnerSource Commons. Les commons parrainent une chaîne Slack, un groupe de travail sur les modèles InnerSource et plusieurs sommets en personne chaque année. La participation au commons est un excellent moyen de rester connecté avec les dernières de InnerSource.

InnerSource est-il adapté à mon projet?

InnerSource est l’application des principes open source au développement logiciel interne de l’entreprise. Bien fait, il débloque les progrès et facilite l’adoption de services et de modules partagés. Cet article contient des conseils et des questions à vous poser lors de l’adoption d’une approche InnerSource pour exécuter votre projet.

Une approche InnerSource n’a de sens que si des contributions sont attendues des utilisateurs du projet. Vous pouvez vous attendre à des contributions si vous voyez ou anticipez des quantités notables d’énergie orientées vers votre secteur de projet par ses utilisateurs. Quelques exemples:

• Nombre élevé de projets utilisés et adoptés.
• Plus de demandes de fonctionnalités que votre équipe a le temps de remplir.
• Les utilisateurs font des solutions de rechange pour compenser le manque de fonctionnalités dans votre projet.
• Les demandes de fonctionnalités qui prennent presque autant de temps à expliquer qu’elles le feraient simplement pour mettre en œuvre.
• Plusieurs dépendances sur votre projet.

Même avec les contributeurs volontaires, le code ne s’écoule pas simplement. Vous devrez encourager et soutenir les contributions au moyen d’activités telles que :

• Comprendre les scénarios des utilisateurs et suggérer quelles contributions pourraient les aider à respecter ces scénarios.
• Inviter les utilisateurs à apporter les contributions dont ils ont besoin et à en assurer le suivi afin de s’assurer qu’ils les apportent.
• Maintenir uneCONTRIBUTION.mddocument qui contient tout ce qu’un ingénieur doit savoir pour contribuer au projet.
• Donner des orientations et des orientations initiales sur la façon de mettre en œuvre une contribution donnée.
• Être disponible pendant les heures normales pour toute question ad hoc que les contributeurs ont.
• Examen en temps opportun des demandes de tirage entrantes.
• Mise à jour continue du code soumis (aprèsfenêtre de garantie).

Les projets InnerSource ont un sens lorsque le projet est spécifique à l’entreprise ou lorsque son utilisation exclusive lui confère un avantage commercial stratégique. D’autres projets de collaboration devraient être menés en tant que sources ouvertes afin d’accroître le bassin de contributions et leur impact.

Si les contributions viennentetvous soutiendrez ces contributionsetvotre projet est spécifique à l’entreprise, puis InnerSource est adapté à votre projet.

La mentalité de InnerSource

InnerSource aide quand il y a plusieurs équipes dans notre entreprise qui ont un besoin partagé – entreprise ou technique. Nous voulons un projet partagé que tous peuvent exploiter. Ce partage permet à chaque équipe de passer autant de temps que possible dans son secteur d’activité unique au lieu de réinventer ce que quelqu’un a fait auparavant.

Nous gérons des projets partagés via InnerSource, ce qui signifie que nous appliquons les pratiques et les principes open source à leur fonctionnement. Ces projets sont ouverts à la réutilisation et à la contribution dans toute l’entreprise. En théorie, tout projet peut être un projet InnerSource, mais vous pouvez trouver les projets populaires InnerSource énumérés dans le portail de la société InnerSource.

InnerSource doit faire partie de notre façon de travailler. Lorsque vous livrez votre feuille de route logicielle, lorsque vous rencontrez un besoin qui est probablement partagé avec d’autres équipes, arrêtez-vous et réfléchissez. Quelqu’un d’autre à l’entreprise a déjà construit quelque chose qui (presque) résout ce besoin? Si oui, à bord de ce projet, même si cela signifie y contribuer d’abord pour l’étendre pour répondre à votre cas d’utilisation. S’il n’y a pas de projet existant, construisez-le de manière sombre avec vous-même comme premier consommateur, puis l’énumérez dans le portail InnerSource.

Travailler ainsi nous aide à tirer le meilleur parti possible du temps d’ingénierie que nous avons tous passé et nous permet de passer plus de temps dans notre mission unique en tant qu’entreprise. Adopter la mentalité InnerSource.

Manuel

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Votre équipe manque de ressources pour créer son logiciel de base
2. Vous blairez un gestionnaire de haut niveau pour obtenir une autre équipe pour implémenter un changement de logiciel
3. La plupart de vos logiciels sont achetés plutôt que construits
4. Pas assez de changements logiciels sont soumis à votre équipe

Pourquoi 1 est incorrect : InnerSource permet à d’autres équipes de mettre à jour votre logiciel pour répondre à leurs besoins. Vous ne pouvez pas dépendre d’autres équipes pour prendre vos propres priorités, ni vous pouvez assigner un projet à une autre équipe. InnerSource s’appuie sur des contributions volontaires et travaille là où les intérêts de l’invité et de l’équipe hôte s’alignent.

Pourquoi 2 est correct : Les grandes organisations qui assignent différentes équipes à différentes parties d’une base de codes subissent systématiquement des batailles sur les priorités. Ce qui est critique pour votre équipe Le plan d’affaires peut être considéré comme une gêne étrangère pour l’équipe hôte qui possède le code. Avec InnerSource, vous ajoutez le code dont vous avez besoin directement au projet de l’autre équipe, bien que vous soyez responsable de suivre leurs directives et que l’équipe d’accueil le vérifie avant qu’il n’entre.

Pourquoi 3 est incorrect: Si un tiers fournit une solution propriétaire, vous ne pouvez pas participer à son développement. Cependant, les logiciels libres et libres de tiers offrent d’excellentes possibilités de collaboration. Les compétences que vous apprenez à faire InnerSource peuvent être appliquées à des projets open source en dehors de votre entreprise, et vice versa.

Pourquoi 4 est incorrect : InnerSource exploite les désirs d’autres équipes pour améliorer votre logiciel. Si votre logiciel est mature et n’a pas besoin de beaucoup de changements, il n’y a aucune raison pour vous ou d’autres équipes de l’améliorer. Vos compétences peuvent être orientées vers de nouveaux projets.

1. Il empêche plusieurs équipes d’avoir à mettre en œuvre différentes solutions aux problèmes partagés
2. Il fait appel à des cadres de haut niveau pour aider les équipes à décider des priorités
3. Il faut moins de développeurs pour créer la même quantité de code
4. Il limite la maintenance aux personnes qui connaissent bien la base de code

Pourquoi 1 est correct : lorsque chaque équipe est responsable d’une base de code unique, différentes équipes ont tendance à ajouter du code à leurs bases de code particulières pour implémenter la même fonctionnalité. Ce n’est pas seulement un gaspillage, mais peut conduire à des incompatibilités. Avec InnerSource, les équipes collaborent à l’ajout de code à une base de code unique pour implémenter la fonctionnalité.

Pourquoi 2 est incorrect : InnerSource permet aux membres de l’équipe de fixer leurs propres priorités. Il s’agit d’un système volontaire qui comporte une participation populaire. En fait, au mieux, il réduit la participation des gestionnaires de haut niveau, ce qui leur permet de faire leurs efforts pour répondre à d’autres besoins stratégiques de l’organisation.

Pourquoi 3 est incorrect : InnerSource n’est pas magique. La même quantité de travail est nécessaire pour écrire mille lignes de code qu’auparavant. Les gens s’engagent dans InnerSource pour s’assurer qu’ils obtiennent le code dont leurs projets ont besoin, et investir le temps nécessaire pour l’écrire.

Pourquoi 4 est incorrect : toute l’idée de InnerSource est de se répartir autour de la maintenance ainsi que de nouvelles fonctionnalités. Toute personne de l’entreprise qui voit un problème est habilitée à le réparer. Les équipes utilisent InnerSource parce qu’elles voient la participation généralisée comme une force.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Utilisateur final
2. Contributeur
3. Engagement fiable
4. Propriétaire du produit

Pourquoi 1 est incorrect : InnerSource est une activité technique dans laquelle les développeurs (donateurs et commiteurs de confiance) participent, pris en charge par les propriétaires de produits. Bien que répondre aux besoins des utilisateurs finaux soit l’objectif ultime, les utilisateurs finaux ne déterminent pas qui fait le travail ou comment il est fait, et ne font donc pas partie des communications et des activités qui constituent InnerSource.

Pourquoi 2, 3 et 4 sont corrects : Les trois rôles clés dans InnerSource sont le contributeur qui crée les contributions de base (code, documentation et lignes directrices), le commiteur de confiance qui mentore les contributeurs, et le propriétaire du produit qui représente les besoins de l’organisation.

1. Formation rigoureuse pour s’assurer que tous les ingénieurs connaissent l’entreprise dans son intégralité
2. Obtenir des propriétaires de produits pour vérifier chaque changement
3. Examens de code par des commiteurs de confiance
4. Examens par des experts extérieurs à l’entreprise

Pourquoi 1 est incorrect: Il est déraisonnable de penser que chaque ingénieur peut comprendre tout le code de la compagnie. Chaque ingénieur doit comprendre seulement le code qui a un impact immédiat sur son travail. Cependant, InnerSource permet aux ingénieurs d’explorer le code d’autres équipes à la profondeur qu’ils veulent, et de contribuer à d’autres teams code tout en ayant une compréhension limitée de celui-ci. L’ingénieur peut simplement lire une fonction et fournir une correction de bug, par exemple.

Pourquoi 2 est incorrect : les commiteurs de confiance vérifient chaque changement. InnerSource place la responsabilité plus près des développeurs, plus bas dans la hiérarchie organisationnelle, et libère les propriétaires de produits pour se concentrer sur la stratégie et les exigences.

Pourquoi 3 est correct : Sont des engagés de confiance sont choisis par leur communauté pour leur capacité démontrée d’écrire un excellent code, leurs compétences en communication et en mentorat, et leur connaissance du code et des objectifs de l’équipe. Ils examinent toutes les contributions avant de les autoriser à entrer dans la base de codes.

Pourquoi 4 est incorrect : InnerSource, contrairement à open source, maintient le code au sein de l’entreprise. Bien sûr, les équipes sont libres de faire appel à des experts extérieurs (comme pour les examens de sécurité), mais cela ne fait pas partie de InnerSource.

1. Veiller à ce que le code corresponde aux lignes directrices de style de leur équipe.
2. Écrire le code comme demandé par le contributeur
3. Mentorat du contributeur
4. Fusionner le code du contributeur dans leur base de code team

Pourquoi 1 est correct : chaque équipe de développement doit maintenir des normes pour le style de codage, la structure, la qualité, la sécurité et le respect général des objectifs du projet. Bien qu’ils soient écrits et partagés avec les contributeurs, le commiteur de confiance est le point de transmission clé où l’équipe transmet ses lignes directrices à des tiers.

Pourquoi 2 est incorrect : L’objectif de InnerSource est d’habiliter les étrangers à contribuer à un code d’équipe, offrant le mentorat dans le contrôle de la qualité ainsi que des normes et des lignes directrices. Cela saperait tout le postulat de InnerSource si un membre de l’équipe faisait la rédaction demandée par l’externe; ce serait simplement une réponse traditionnelle à une demande de caractéristiques. De plus, si le commiteur de confiance écrivait le code, InnerSource imposerait simplement de nouveaux fardeaux de communication sans supprimer les charges de programmation.

Pourquoi 3 est correct: Un code contributeur est un excellent point de départ pour la formation du contributeur. Le mentorat peut produire une croissance éducative et personnelle encore plus bénéfique que la contribution du code lui-même. Et les contributeurs, même s’ils sont compétents et bien informés sur la base de code et les objectifs de l’équipe, peuvent bénéficier d’une orientation pour aligner leurs contributions sur les objectifs et les normes de l’équipe.

Pourquoi 4 est correct : Le commiteur de confiance, ainsi que les responsabilités éducatives et de mentorat, joue le rôle typique d’un commiteur sur un projet, s’assurant que le code fonctionne bien et ne rompt pas quelque chose d’autre dans l’application.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Il améliore le code avec les contributions de ses utilisateurs
2. Il les libère d’avoir à comprendre leurs besoins de l’utilisateur
3. Ils reçoivent moins d’interruptions pendant les périodes d’activité à volume élevé
4. Il souligne leur importance pour l’ensemble de l’organisation

Pourquoi 1 est correct : les équipes hôtes ouvrent leur base de code aux autres et mettent de l’effort pour vérifier les contributions précisément parce que leur code finit mieux et avec plus de fonctionnalités que s’ils faisaient tous les codages eux-mêmes.

Pourquoi 2 est incorrect : InnerSource n’a aucun impact sur la définition des besoins et des priorités. Comme pour tout développement logiciel professionnel, les développeurs doivent comprendre leurs utilisateurs.

Pourquoi 3 est incorrect : Les contributeurs de nombreuses équipes soumettent des changements au code, on espère, pendant les périodes d’activité à volume élevé. Cela signifie que l’équipe hôte doit jongler avec de nombreuses interactions avec des étrangers. Le résultat, cependant, est plus de code dans un court laps de temps.

Pourquoi 4 est incorrect: Les étrangers font des contributions viennent à des projets qu’ils reconnaissent comme importants, L’importance précède les dons volontaires de code. Comme InnerSource sollicite des contributions volontaires, les étrangers ne travaillent que sur des projets qu’ils jugent importants. Cependant, une équipe peut demander aux étrangers de contribuer, en les persuadant que le projet est important.

1. Les gestionnaires allouent plus d’argent à l’équipe
2. Les personnes en dehors de l’entreprise peuvent voir et commenter le code
3. Les contributeurs peuvent compléter le travail de l’équipe hôte sur la base de code propre de l’équipe.
4. Il conduit à un élargissement permanent de l’équipe

Pourquoi 1 est incorrect : InnerSource n’a aucun effet sur le financement d’une équipe. Il est vrai que les gestionnaires d’autres équipes peuvent allouer de l’argent pour que leurs propres membres puissent travailler sur un code hautement prioritaire dans d’autres équipes. Ils paient les membres de leur propre équipe pour travailler sur le code, et non les membres des autres équipes.

Pourquoi 2 est incorrect : InnerSource n’est pas open source. Le code n’est pas publié en dehors de l’entreprise. Cependant, certaines entreprises choisissent d’ouvrir leur code à un moment donné, transformant un projet InnerSource en un projet open source.

Pourquoi 3 est correct : InnerSource invite le personnel de l’entreprise en dehors de l’équipe hôte à travailler sur le code de l’équipe hôte. L’équipe hôte bénéficie de la compréhension des besoins de leurs utilisateurs ou consommateurs, ainsi que des nouvelles fonctionnalités ajoutées.

Pourquoi 4 est incorrect: InnerSource peut être un multiplicateur de force précieux pendant les écrasements de temps, réunissant des personnes de nombreuses équipes pour compléter rapidement le code hautement prioritaire. Mais après la crise, les gens retournent travailler sur des projets au sein de leurs propres équipes.

1. Établir des barrières claires entre les responsabilités de l’équipe
2. Remplacer la formation traditionnelle par le mentorat
3. Apportez les idées d’une équipe dans une autre
4. Établir toutes les exigences avant le début du codage

Pourquoi 1 est incorrect : InnerSource brouille les responsabilités assumées par chaque équipe. Son objectif est de permettre aux personnes d’une équipe de collaborer avec une autre. Les étrangers apprennent non seulement le code de l’équipe hôte, mais aussi son style et ses normes. En InnerSource, l’équipe hôte encourage les étrangers à assumer une responsabilité accrue pour son code.

Pourquoi 2 est incorrect : La formation traditionnelle est toujours importante pour les compétences de base comme l’apprentissage des langages de programmation, des outils de développement et de bonnes techniques d’ingénierie logicielle. Cependant, le mentorat peut améliorer cette formation et constitue une partie importante de InnerSource.

Pourquoi 3 est correct : Sur un grand projet, une équipe produit souvent des services consommés par d’autres équipes. L’équipe codant le service ne comprend souvent pas le but ultime et les exigences ainsi que les équipes qui s’appuient sur le service. InnerSource améliore la communication entre les équipes, et permet à l’équipe avec la plus grande connaissance de l’utilisateur de mettre son code directement dans une autre base de code de team.

Pourquoi 4 est incorrecte : les exigences ne sont pas étroitement liées à la décision d’utiliser InnerSource. Par exemple, InnerSource permet aux développeurs à l’intérieur et à l’extérieur d’une équipe de négocier les fonctionnalités au fur et à mesure qu’elles vont. Il est compatible soit avec un réglage d’exigence rigide (modèle de cascade) soit avec un réglage d’exigence lâche (modèle agile). Mais parce que InnerSource tend à transférer le pouvoir et la prise de décision aux feuilles extérieures de l’organisation, y compris les développeurs individuels, il encourage les gens à fixer leurs propres exigences dans le contexte du projet, et à les changer pour répondre à de nouveaux aspects de l’environnement.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Servir de modèles
2. Arrêtez leur propre codage pour prendre le rôle
3. Accroître l’examen du code de contribution
4. Code de révision rédigé par leur propre équipe

Pourquoi 1 est correct : Les auteurs d’engagements de confiance sont choisis en raison de leur rendement supérieur aux tâches de codage et de leur engagement à bâtir une communauté. Par conséquent, leur comportement sert de modèle aux autres dans la recherche d’un meilleur code et d’une communauté plus forte. De nombreux contributeurs cherchent à devenir des acteurs de confiance.

Pourquoi 2 est incorrecte : les commiteurs de confiance continuent de participer pleinement à toutes les activités de leur équipe. Le rôle d’engagement de confiance intensifie leurs contributions, plutôt que de les remplacer. Ils doivent également garder le codage (bien que probablement pas autant qu’avant) pour comprendre le code de leur équipe assez bien pour aider les contributeurs extérieurs et juger leur travail. Enfin, le rôle de commiteur de confiance est temporaire pour certains développeurs, et ils prévoient de revenir au codage à temps plein.

Pourquoi 3 est correct : quand une seule équipe développe son propre code, les membres de l’équipe ont tendance à partager une compréhension tacite du code et de ses objectifs. Ils peuvent n’avoir besoin d’aucun contrôle, ou peuvent fournir un contrôle minimal. InnerSource apporte des codeurs extérieurs qui ont besoin de vérifications plus minutieuses de leur code, car ils viendront au projet avec leurs propres vues et expériences.

Pourquoi 4 est correct : toutes les contributions peuvent bénéficier d’une seconde paire d’yeux. Donc, les commiteurs de confiance examinent le code à la fois de l’extérieur et de leur propre équipe.

1. Répondre aux soumissions de code avec une rétroaction et des conseils constructifs.
2. C’est un excellent code.
3. Organisation de formations et de présentations en personne.
4. Paire la programmation.

Pourquoi 1 est correct : l’éducation est souvent plus efficace et durable lorsque les apprenants se concentrent sur des projets spécifiques et tirent des leçons générales de leurs propres efforts. Peu d’expériences d’apprentissage sont plus puissantes que de demander à quelqu’un d’écrire du code, puis d’expliquer comment il peut être amélioré. C’est un rôle clé pour l’auteur de la confiance.

Pourquoi 2 est incorrect: écrire un grand code est une merveilleuse préparation et une condition préalable pour être un commiteur de confiance, mais le mentorat est plus que l’exemple. Le mentorat doit s’efforcer activement d’enseigner aux autres et d’améliorer leur capacité à coder dans le projet.

Pourquoi 3 est incorrect : chaque rôle de commiteur de confiance est couplé à un projet spécifique et est conçu pour aider les contributions de code individuelles à avoir le soutien dont ils ont besoin pour que leurs contributions soient acceptées dans la base de code. La plupart des formations et des présentations sont conçues avec un large public à l’esprit et ont donc un sujet plus général. Le mentorat de l’engagement de confiance se fait surtout au niveau individuel.

Pourquoi 4 est incorrect : alors que la programmation de paires peut être faite à distance, il n’y a aucune garantie que les contributeurs puissent coordonner des temps spécifiques avec des committers de confiance. Le mentorat de l’engagement de confiance se produit principalement de façon asynchrone et numérique.