学習パス：プロジェクトリーダー

このセクションでは、InnerSourceは、アジャイル、オープンソース、キャパシティプランニングなど、プロジェクトのリーダーシップの他の側面とどのように合っているかについて説明します。

プロジェクトリーダーのためのInnerSource

このセグメントが完了すると、InnerSourceが製品開発をスピードアップする方法がよりよく理解できるようになります。また、アジャイル開発のベストプラクティスに関連する方法について説明します。

敏捷性を達成するために、組織は自律的なチームのために努力します。しかし、複雑で相互接続された世界では、依存関係は回避できません。 InnerSourceの特長代替手段を提供「待ってから」, 「ビルドの回避」と「エスカレーション」: 依存関係の修正が必要なチームは、助け手を提供することができます. InnerSourceは、クロスチームコラボレーションを容易にします。書面による通信に焦点を合わせ、リモート・ファースト・モードにも適しています。

このセクションでは、アジャイル開発とInnerSourceが同様の用語と技術を使用している場所を学びます – しかし、詳細に大きく異なります。一般的な誤解に陥る代わりに、文化の違いを知るだけでなく、使用されるツールの目的から利益を得ることができます。

InnerSourceの容量計画への影響を理解します。また、InnerSourceでは無料ランチはありません。ホストチームはコントリビューターをメンターするための時間が必要です。また、InnerSourceがもたらす追加の交渉の可能性を見ていきます。

しかし、簡単な例から始めましょう。素敵な新しい音楽アプリを作ってみませんか? ユーザーが何らかのインタラクションログを収集するアプリとやり取りする方法を理解するため。時間が経つにつれて、それらを分析するときに深く掘り下げ、学習を開発に戻します。今、あなたのアプリケーションにコンテンツをもたらす別のチームがいくつかのニーズを持っていることを想像してみてください – 彼らは彼らが到達した多くのユーザーに基づいてコンテンツクリエイターに報酬を与えたいと思うかもしれません。そのため、収集したログを使っても起動します。しかし、最初に考えていない追加の分析手順が必要です。彼らは今、課題に直面しています: 回避策を構築したり、バックログを通過して、彼らの要求を優先順位付けします。 InnerSourceでは3番目のオプションがあります:変更を自分で作成してください – あなたの助けを借りて。確かに、変更をしたよりも遅くなる可能性があります。しかし、それはまだあなたが変更を作るために周りを取得するために待つよりも速くなります。

理想的なInnerSource組織では、さらに拡張することができます。プラットフォーム全体でクロス切断の懸念修正を行う必要がある最後の時間を覚えていますか? 「各チームのバックログにそれを入力」すると、それが永遠にドラッグしているような感じがよくあります。一方、変更を実装するパッチで、そのチームを実質的に提供するために物事を高速化します。そのアプローチの修正の複雑さは、組織の成熟度と生成されたコードの維持性/修飾性に依存します。

InnerSourceとアジャイル

製品を改善し、顧客に迅速に届けたい。利害関係者を幸せにしたい InnerSourceは、あなたのチームが価値を提供し、非常に相互接続された世界で自律性を維持するのに役立ちます。

迅速にお客様に価値を届ける組織遅延の一般的な原因は、配送プロセスの依存性です。その結果、組織は、顧客コミュニケーション、設計、実装、テスト、および運用をカバーするクロス機能チームを好むため、コストを削減します。高い性能を達成するために、チームは無駄を除去し、既存のコンポーネントを再使用します。チーム観点から各再利用コンポーネントは、そのチームのコントロールの外側に別の依存性を追加します。この最適化の否定的な側面は明確です: チームは、使用されるコンポーネントの変更が必要な場合は、別のチームに依存します。多くの場合、長いロードマップの議論を実装できるようにするには、グローバルに詳細な優先順位を最適化する必要があります。複雑な状況では、大規模な組織では、ビジネスニーズの変化に合わせて調整する時間が増えています。非常に人気のある中央コンポーネントは、要求されたすべての変更を実装する能力の1つの中央コンポーネントチームが実行するので、多くの要求が伴います。

伝統的な組織では、依存関係への変更を行う2つの方法:

機能リクエスト/バグ報告を提出し、他のチームが変更を優先し、それを実装するのを待ちます。
バグを回避したり、ローカルで必要な機能を提供したりするための回避策を構築します。

これらのオプションが正常にない場合、問題はエスカレーションされ、より高い階層レベルで決定されます。

Neitherソリューションは、特に満足しています。明らかな解決策がありますが、オープンソースを見る:コンポーネントに応じてチームが貢献チームになり、ホストチームにヘルプハンドを提供します。

今、あなたは自分自身に尋ねるかもしれません: 「それは、人々がランダムにメンバーではないチームのコードリポジトリに書き込み、完全な混乱につながることはありませんか?」 InnerSourceは、そうでなければ、確かに混乱につながるものに明確をもたらす役割とプロセスのセットが付属しています:

各InnerSourceプロジェクトには、単にコードを見直して行く明確な責任を持つTrusted Committersのセットがあります。 Trusted Committersは貢献のための規則を置きました。
貢献は構造化された方法で起こります:
- 貢献の意図はホストのプロジェクトの視野および規模内の貢献の適合を確かめるために最初に共有されます。
- プログレスは初期に共有されるため、ホストチームはコントリビューターをメンターし、目的のデザインとアーキテクチャへのパスをガイドするチャンスがあります。プロセスの後半の貢献を低下させるため、その方法の不満は避けられます。
- 決定と重要なコミュニケーションは、異なるチームにおける人々の会議スケジュールの異なる状況で作業できるように非同期的に起こります。その結果、チームは、貢献しているコンポーネントの品質を犠牲にすることなく、上流のアーティファクトを修正するために自律性を得ることができました。

副作用として InnerSource リモートファーストカルチャーで作業を容易にするベストプラクティスチームを提供します.

InnerSourceで働く代わりに、チーム間のコラボレーションを促進します。オープンソースでは、巨人の肩に立っていることを意味します。InnerSourceの全てのコンポーネントをローカルに構築する代わりに、再利用を促進します。バグの修正と機能の実装の作業で、上流チームをサポートするための明確なパスを提供することで再利用コストを削減します。

オープンソースInnerSourceでは、すべての事業単位と製品チームが基礎として組み合わさるコンポーネントが一緒に構築できるという考えを築きます。その結果、すべてのボートが上昇しています。組織の1つの部分で作られたイノベーションは、企業全体で利益をもたらすことができます。 InnerSourceに精通しているチームは、このタイプのイノベーションを前進させるためのロードは、結果のコンポーネントとサービスに依存し、恩恵を受けるすべてのチームによって共有することができます。

InnerSourceは、お客様のチームに、顧客への配送機能をブロックする課題を解決するための取り組みとツールを提供します。コアコンポーネントとサービスの正しいメンテナンスを行うと、任意の特定の製品チームよりも大きい「仮想InnerSourceチーム」によってうまく構造化された方法で共有することができます。

高度な設定では、コントリビューターが顧客に直接利益をもたらすことができないシンプルな機能に取り組む価値を理解しています。これは、コントリビューターがビジネスに必要な複雑な変化に取り組むためにホストチームを解放する条件下にあります。

短い回答:いいえ、まったくありません。代わりに2は互いに補完します。

よく評価され、よくテストされたコードは、あらゆるアジャイルチームの1つの目標です。 InnerSource では、チームメンバーのオンランプ時間を設定しているだけでなく、チーム外部のコントリビューターが不足している。

タスクの割り当てを回避するコラボレーションに精通したチームは、柔軟な方法で外部の貢献に対処するための良い立場にあります。彼らはまた、彼らが直接影響を与えない優先的に、貢献者を動機づけるためにうまくいくマインドセットとコミュニケーションスタイルをもたらします。作業を指示するのではなく、本質的なモチベーションで作業することで、ホストチームはコントリビューターとうまくコラボレーションするツールを持っていることを意味します。

問題に対抗するチームは、早期に進行状況を共有して既に快適です。 InnerSourceに対の文化から移行する2つの課題があります。ホストチームは、コントリビューターをサポートし、計画された仕事をスケジュールするための時間を作る必要があります。チーム境界を横断するだけでなく、ペアリングのための時間スロットを見つけることはしばしば困難です。この場合、非同期コラボレーションと補完する必要があります。頻繁な混乱を避けるために、ホストチームメンバーは、InnerSourceの設定で、意図的に自分の日を計画する必要があります。多くの場合、貢献をメンターするための1週間または1日に特定の時間を設定するのが最も簡単です。チームレベルでそのexplicit を作ることは、自分のチームの目標を達成しようとするエンジニアから多くの圧力を奪うだけでなく、貢献者を支援します。ペアリングのもう1つの課題は、ペアが非常に迅速に移動できるようにすることです。多くの場合、チームの残りの部分のために重要な情報を書き留める費用で。 InnerSourceの設定では、関連するすべての決定を記憶するために訓練をとり、両方のコミュニケーションチャネル、ホストチーム、コントリビューターを共有することを忘れないでください。より透明性の高い製品観点から開発プロセスまで多岐にわたります。また、エンジニアリングレベルで受けているかもしれないという決定は、皆が関わった人だけに見えます。

あなたの製品がうまくテストされることを主張した最後の時間を覚えておいてください。, できれば自動化されたテストで, 導入は頻繁に、人間の介入なしで起こることができます? この目標は、InnerSourceと同様に役立ちます。コントリビューターが変更が安全であれば、ローカルでチェックできると、貢献ははるかに簡単です。テストでは、ホストチームは、失敗したテストでその理由を思い出させると、貢献した機能を維持することを忘れないようにします。

「見つけたよりも、より良い形でコードを保存」の目標に従うために時間を費やすあなたのチームに主張した最後の時間を覚えておいてください。その考え方は、InnerSourceモデルで役立ちます:異なるソースからの複数の貢献がある場合であっても、コードの品質と凝集が高ままであることを確認します。

InnerSourceとアジャイルは、異なる目的のために、同じツーリングの一部を使用しています。

課題トラッカー:アジャイルチームのユーザーストーリーは、顧客との会話です。多くの場合、ホワイトボードに粘着性のノートとして置かれます。しかし、多くの場合、それらは問題トラッカーに保存されます。その結果の問題トラッカーは、主に計画ツールとして認識されているため、基本的にはホワイトボード上のスティッキーノートの交換です。 InnerSourceでは、問題追跡者は顧客との会話のために機能しますが、信頼できるコミッタのチームのメンバー間のコミュニケーションのためにおよび1つの共通のInnerSourceの部品で働くコントリビューター。 InnerSourceの課題は、あなたの平均的な組織よりもはるかに長くて文脈になります。また、実装履歴と変更のための詳細な設計決定を追跡します。

コードレビュー: 伝統的な組織のコードレビューでは、多くの場合、監査の目的のために役立ちます。

開発が終わったら、それらは行われます。 InnerSource コードの変更は、プロセスの初期に非常に共有されます。時には、ラフなスケッチが終わらないとき。目標は、早期のフィードバックとメンタリングを求めることです。これは、多様なスケジュール上のチームにとって特に有用であり、ペアプログラミングの任意の時間を見つけることができません。多くの場合、チームは誰も一人で歩いていないという願望を持っています – 実際には、これはそれほど多くの願望を達成しません。具体的には、クロスチーム境界を貢献する。

InnerSourceで使用しているツールは、変更に関与する人以上がこの質問を正式にすることができます。

書面によるコミュニケーションに焦点を当てる: InnerSource との目標は、チームの一部ではない開発者がプロジェクトの決定を理解し、ソフトウェア作成のプロセスに沿って従うことができるように、プロジェクトが十分に透明になるためのものです。その結果、すべてのコミュニケーションは、会話に興味を持つすべての人がフォローできる場所にある必要があります: 書面、公共、検索可能、およびリンク可能な。目標は、他人への気配りを減らすことではありません – 目標は、すべてのプロジェクトの会話を透明にすることです。

結果ダイレクトメッセージやメールが回避されるため。 InnerSourceプロジェクトに関連するすべての人がInnerSourceプロジェクトのチームですべての人に手を差し伸べることは目標です。目標は、InnerSourceプロジェクトに焦点を合わせた議論をできるプロジェクトに関わるすべての人のための共通の共有部屋を見つけることです。

書面による通信に焦点を合わせることは、口頭通信が許可されていないという意味ではありません。コーヒーの共有カップには、まだ時間が必要です。また、問題の解決、他の人と対したり、ハッカソンをハッカソン人はすぐに解決策を見つける価値があります。チームは、すべてのプロジェクト関連の決定が、誰もがアクセスできるチャネルで保持されていることを確実にする必要があります。また、他の国で働いている人が今の休日にいる場合は、誰もが休暇から戻って、または別の日に待っているまで、重要なプロジェクトの決定を延期することを意味するかもしれません。これは、コーディングの決定だけでなく、一般的なプロジェクトミッション、ロードマップ、方向性にも関連しています。その情報コントリビューターなしでは、貢献が受け入れられる良いチャンスを持つ苦労した時間理解を持っています。

InnerSourceプロジェクトのすべての議論は、同社のみんなに表示されています。彼らのエラーのために人々を鼓舞し、彼らの間違いのためにそれらを嘲笑し、彼らが間違っていたことについて彼らの背中の後ろに話することは、その信頼を殺し、そのInnerSourceプロジェクトの失敗につながる確実な火の方法です。これは、リーダーシップやロールモデルの位置で誰にとっても特に重要です。

InnerSourceと計画

InnerSource の2つの重要な状況において、計画は役割を担っています。

チームに貢献することは、上流コードで作業することは通常、彼らがよくよく理解している独自のコードベースに匹敵する変更を作るよりも多くの時間を必要としていることを理解する必要があります。彼らは、ホストチームが変更を実装していない場合でも、彼らはまだメンターやレビューのために利用できる必要があるという事実を認識する必要があります。必要な変更のサイズで増加する時間。ホストチームとの初期通信は、特に大きな変更の場合に重要です。

ホストチームは、メンターやレビューに必要な時間を認識する必要があります。パッチとして変更を提出できるコントリビュートチームが、ホストチームの変更をゼロにする時間を削減しません。追加のホストチームは、プルリクエストでフラッドされているまれな状況で自分自身を見つけることができます。その場合、これらのプルリクエストを送信するプロジェクトのためのビジネス優先事項の明確な理解が必要です。パッチで圧倒されると、コンポーネントの所有権を共有することを考えるのに時間がかかります。定期的に戻って、ホストチームの信頼を獲得している特定のコントリビューターでは、タイトルTrusted Committerを受け取るために良い候補者です。

若干異なる作業文化による摩擦は避けられない。これらの場合、明示的に期待値を設定することが重要です。

次の状況を想像してください:最後に必要な変更をしたコントリビューターとして – ホストチームから少し助けを借りて。プルリクエストを誇りに思っています。それから – 何も起こりません。一日後 – まだ反応しません。ホストチームがパッチを見ているかどうか疑問に思います。更新についてチームをうまくいくのがどこなのか。このサイレンスは、初めてのコントリビューターのために特に非常に不満です。この状況にはいくつかの救済があります – コーディング知識を必要としない救済, しかし、少なくともいくつかの基本的なコミュニケーションスキルが必要です:

貢献文書のホストチームexplicitの期待できる反応時間を作る。
プルリクエストが受け取ったらすぐに、コントリビューターの待ち時間ではなく、かなりのフィードバックを受け取るようになります。
コントリビューターがホストチームと連絡を取り合い、そこでコミュニケーションを監視する方法を伝えます。

これらのタスクはコードを書くスキルを必要とします。プログラミングの知識を持っている人を超えて人の必要性を強調します。 InnerSourceプロジェクトにコミットし、Trusted Committersと同様にそれらを含むように、これらのタスクをカバーする人々を考慮するのは良い習慣です。

小さな変更やパッチの処理が簡単です – 彼らはレビューに迅速であり、多くの場合、合併したときに多くのリスクを運ぶことはありません。ホストチームを支援するための1つの方法は、小さなチャンクに変化を分割するための時間を作ることです。これらの変更が属するより広い文脈を必ず伝えてください。

多くの場合、より大きな変更を行うには、初期の意図と目的を伝達する必要があります。また、チームとホストチームが変更を一緒に作業するために十分な時間を設定していることを確認することも有益です。つまり、変化を優先するとき、チーム優先順位を設定することで、チーム自身のチームを超えて考える必要があります。しかし、協調は、通常、コントリビューションとホストチームのペアのみが関与しているため、独立して起こることがあります。

貢献チームから多くのパッチを受信するという課題に、稀にホストチームは実行されます。その場合、信頼できるコントリビューターをTrusted Committerの役割に動かすことを考えるのに役立ちます。単にレビューを支援するだけでなく、新しいTrusted Committersは、問題のトリアージ、新しいコントリビューターのメンターなどを支援することができます。

貢献に多くの関心に直面したとき、コントリビューターのためのメンタリングの助けを優先するときに考慮する1つの追加の要因は、ホストチームと長期的な関係におけるコントリビューターの利益を得ることができます。メンタリングには、コントリビューターが長持ちする可能性が高まります。

非常にアクティブなコントリビューターを持つコンポーネントの所有権を共有する練習では、新しいマイナー化されたTrusted Committersが長期にわたってプロジェクトに従事していることを証明しました。典型的には、コンポーネントを最新の状態に保ち、コントリビュートに対する初期のモチベーションが対処された後、メンターの新しいコントリビューターを長持ちさせます。

InnerSourceと交渉スキル

コーディングと交渉? これらの2人が一緒に行く方法を教えてください。特にInnerSourceのホストチームでは、交渉の変更に関しては、いくつかのギャンブルブロックを念頭に置いています。

最後のトレーニングセグメントで議論したように、より小さいコードの変更はより早く受け入れられる傾向があります。ホストチームにとって、利点は明確であり、チームに貢献するために伝えるべきです。

レビューが容易です。
彼らはより少ない影響を持っています – 両方、肯定的および否定的。
より速く統合できます。

アドホックのファッションに小さな変化を施すことで、摩擦が少なくなります。彼らはドライブバイの貢献のための甘いスポットであり、多くの場合、多くの調整サポートなしで処理することができます。通常、これはInnerSourceの貢献が始まる方法です:チーム内のエンジニアは、より小さな変化に協力し始め、非常に簡単で軽量な作業を見つける。より小さな変更は、エスカレーションの必要性なしに通過する傾向にある変更です。

これにより、InnerSource がソフトウェアエンジニアのみを対象としたマインドセットを採用するチームが発生することがあります。しかし、この学習したアドホックワーキングモデルは、貢献範囲が増加するとすぐに休みます。ソフトウェアエンジニアに純粋に保たれた場合、チーム内の他のロールからプッシュバックしても最悪の場合、エスカレーションはより頻繁に起こります。貢献して、ホストチームでは、より大きなスコープの他のロールを修正するために、InnerSourceの作業を認識し、テーブルに自分のスキルをもたらす必要があります。

2つのチームは、貢献に取り組むための良い時間を把握する必要があります。ホストチームは、貢献チームをメンターする時間がないなら、サポート不足のために不満を得られる可能性が高いです。彼らはまた、関与するすべての人のための不満を引き起こし、多くの努力を必要とする可能性があるソリューションを開発する可能性が高いかもしれません。貢献チームは、変更のための貢献の精製サイクルに焦点を合わせる時間がない場合には、あまりにも長くなり、中断も高くなります。
ソースコードはコントリビューターとホストチームは、変更がInnerSourceプロジェクトのビジョンに収まるかどうかを把握する必要があります。理想的には、テクノロジーとビジネスレベルの専門知識が一緒に来る必要があることを意味し、誰もが参加できる同じ通信チャネルで優先的に。変更がInnerSourceプロジェクトで行われるべきかどうかについての交渉のこの結果はしばしば – ホストチームによって覆われたメンテナンス。関係者が関与するすべての人に対する価値を明確にする必要があることを意味することができますが、貢献チームは、メンテナンスの負担を下げるホストチームを支援することができます。

「コードを書いてパッチを送ってください」 – 十分に聞こえます。現実を除いて、これは最も些細な変化のためにのみ真実です。特に大きな変化は、全員が参加する時間を持っているように調整が必要です。それ以外の場合、待ち時間が長くなります。チーム境界を横断することもしばしばコミュニケーション文化の微妙な変化を意味します。強いコミュニケーターである人々は、誤解の場合には、チーム間で翻訳することによって、これらのギャップを横断することができます。

ローカルコードInnerSourceのホストチームは、ロードマップとビジョンがすべての潜在的なコントリビューターと通信していることを確認する必要があります。ホストチームに加えて、設計、アーキテクチャ、および性能要件がコードベースで働くすべての人に明示的かつ明確であることを確認する必要があります。この移行は、非常に凝集的なローカル設定で作業するために使用されるチームにとって特に困難です。基本的には、非常にローカルチームでは、透明で明示的であることが明確です。短期的には、コスト時間がかかります – 長期的には、コントリビューターは、ホストチームからのより少ないサポートを必要とする速度を高速化するのに役立ちます。オープンソースで成功を収めた1つのことは、コントリビューターが正しいパスを歩くのが簡単です。ビルド時に失敗する自動品質チェックが含まれています。ホストチームの肩の肩を離れる作業を時間がかかりますが、明らかな問題が自動的に強調表示されます。

InnerSourceと通常のチーム交渉への1つの違いは、箱から考える機会です:アリスが維持したInnerSourceプロジェクトで非常に複雑な変化を必要とするコントリビューターボを想像してください。ボブはコードベースを理解し始めたばかりで、自分で理解してもらえるという問題があります。プロセスを通して彼をメンターする追加では、アリスは多くの時間がかかります。しかし、アリスは、いくつかの優先順位が高いが、バックログの機能を実装するのは簡単です。ボブが彼女のバックログからこれらの問題の一部を取ったと、それらを実装した場合 – アリスはボブが必要とする変更に取り組む時間を持っていますか? これらの透明性協定の酒については、主催者チームと貢献チームの両方に説明する必要があります。さもなければ、ボブとアリスが各顧客のニーズの変化に取り組んでいない理由を理解するのは難しいでしょう。

別の例では、非常に人気のあるInnerSourceプロジェクトで作業しているホストチームを想像してみてください。会社の事業の中心的である。より多くのコントリビューターは、ホストチームをレビューボトルネックに変える必要がある変更を作ることができます。その問題に対処するため、全体的なビジネスの優先順位と貢献チームの重要性に関する明確な視点は、どのパッチを優先し、常に焦点をシフトからホストチームメンバーを停止するかを理解するのに役立ちます。次のステップでは、InnerSourceプロジェクトで動作するTrusted Committersの拡大について考える必要があります。先に述べたように、異なるビジネスラインに報告するプロジェクトにコミットする人々を招待することができます。

特に、かなり複雑である多くの貢献に直面したとき、ホストチームはメンターコントリビューターに投資する時間が価値ある投資であることを理解する必要があります。これらのコントリビューターが長持ちする時間がある可能性が高いメンターに必要な時間が増えます。

共有所有権のオプション

「誰もがそれを所有している場合、誰も責任を負わない」伝統的な組織は、問題の場合には、単一の接点を持つことを好む。一方、誰もが変化を確かめることを可能にするだけで、もはや維持できない混乱が生じます。

InnerSourceプロジェクトごとに、Trusted Committersの専任チームがあります。 InnerSourceプロジェクトを維持することに興味は、多くの場合、自己の興味を啓発することによって動機づけられます。InnerSourceプロジェクトが顧客のニーズを満たし、貢献のためにプロジェクトを立ち上げることを理解することは、プロジェクトを前進させるためにワークロードを広げることができます。 Trusted Committersがすべての投稿を受け入れる必要があるという意味ではありませんが、貢献のためのプロジェクトを開く。 Trusted Committersのチームで、プロジェクトのミッションとゴールを設定します。その後、方向を設定し、それに応じて変更受諾を決定する位置にある。

「Trusted committers」は、InnerSourceプロジェクトを担当しています。投稿とメンターのコントリビューターをレビューしています。

これはTrusted Committerの役割がどのようなものの非常に単純に要約です。実際のところ、最初の質問の1つは、それぞれとすべての貢献を受け入れる必要性の周りに反発することが多いです。特に、コントリビューターがすでに貢献に多くの時間を費やした場合には、その作品が無駄だったと聞いて、その貢献が不満になる可能性があります。コミュニケーションスキルは、InnerSourceプロジェクトのロードマップがどのようなものなのか、コントリビューターが知っていることを確認することが重要です。彼らはまた、コントリビューターが結果なしで多くの仕事を費やすことを避けるために、インテントを共有し、非常に早期に進行することを知っていることを確認する必要があります。最後に、寄付を拒否することは、非常に良好なコミュニケーションスキルを必要とします。長いストーリーを短くするために: ソースコードを自分で記述していない場合でも、InnerSourceプロジェクトのビジョンを明確に伝え、貢献が拒否する必要があるときに潜在的に助ける必要があります。 InnerSourceプロジェクトがより普及するにつれて、より重要なもう一つの側面:レビューとメンタリングは、より時間の集中的になり、時間が経つにつれて一日に計画する必要があります。これは、一般的な容量計画に影響を及ぼし、「レーダーの下で」起こるべきではありません。

一方、コントリビューターでは、コードレビューが最終段階の品質ゲートではないことが重要です。代わりに、コード開発プロセスを通じて継続的にコントリビューターを導き、より良い結果をもたらす方法です。練習を実践するためには、チームビルディングのための時間とスペースが必要です – しかし、伝統的なチーム境界を越えて。チーム内の異なる文化の少なくとも漠然とした理解を持つことは、はるかに少ない可能性を誤解し、貢献プロセスがはるかにスムーズになります。

特に、ホストチームが貢献するプロジェクトリーダーにフラッドされている場合、ローカルチームのみに焦点を合わせると、よりグローバルな視点が必要です。 * チームは、全体的な企業戦略に応じて、貢献を克服するためのさまざまな優先事項を理解するのに役立ちます。多くの場合、すべての貢献が同様に緊急ではありません。 * チームを助けるためのもう一つの方法は、問題のトリエージなどのタスクを引き継ぎ、最初の応答をコントリビューターに処理し、プロセスを通じて大きな貢献を導き出すことです。変更の統合が少し時間がかかる場合は、コントリビューターにコミュニケーションすることでチームを支援できます。 * より大きなコントリビューションリクエストチームに直面した場合は、他のチームと交渉し、これらのコントリビューションで作業するのに最適な時間を得ることができます。自分のチームが自分の仕事をしているよりも、まだより速くなることが多い。特に初めてのコントリビューターは、特に大きな変化のために、いくつかのハンド保持を必要とする場合があります。そのメンターの周りのタイミングを調整することは、あなたのチームのための大きな助けになることができます。

「しかし、我々は単に永久にフォークすることができます」…潜在的なゲストチームは、単にコードをコピーすることがより速くなると信じている誤解.

正しい言葉で。長期的にはメンテナンスが加えられることを意味します。プロジェクトリーダーとして、あなたのチームが、あなたが依存するプロジェクトへの変更がビジネスの最良の利益にある理由を理解するのに役立ちます。全体的に作業を削減します。長期にわたるメンテナンスは、ホストチームによって行われます。

プルリクエストを使用してコンポーネントを開発しています。そのため、毎日InnerSourceを利用しています。プルリクエストとレビューは重要なコンポーネントですが、InnerSourceプロジェクトのためのベースラインです。プルリクエストを日常的に使用することに依存する2つのプロジェクトは、チーム外的な貢献への開放性が同じであるという意味ではありません。

InnerSourceは、さまざまなベストプラクティスが付属しています。コントリビューターの混乱や不満を避けるためには、ホストチームが採用したいInnerSourceプロジェクトを定義することが重要です。オープンソースではこのようなガバナンスレベルが大きく異なる可能性があります。

InnerSource Commonsでは、少なくとも3つのガバナンスレベルを定義するInnerSourceパターンを提供します。 *ソースコードは全員に表示されますが、チームはメンターコントリビューターに時間がありません。外部からは、InnerSourceプロジェクトのように見えます。メンターへの拒否を行い、InnerSource 手段を介してプロジェクトと対話しようとする同僚からの混乱を避けながら、貢献の明示を受け入れます。代わりに、このプロジェクトでは、リクエストとバグレポートのみがチームによって処理されることができるというプロジェクトに依存しています。基本的には、通常の伝統的なソフトウェア開発プロジェクトに戻って落ちることを意味します。 *ソースコードは誰にも見えます – そして、Trusted Committersのチームは、コントリビューターをメンターするための時間を設定しています。これらのプロジェクトのパッチやプルリクエストを歓迎します。 Trusted Committersのチームは、プロジェクト関連の通信が書かれた、アーカイブされた、検索可能でリンク可能なチャネルで起こることを確かめます。また、プロジェクト関連の決定は、コントリビューターがそれらを確認し、フォローできる場所をとっていることを確認してください。 Trusted Committers のチームと休息し、プロジェクトの Trusted Committer になる最終決定は、初期のプロジェクトチームのために作業するために結ばれています。 * 上記 – しかし、Trusted Committers のチームは、書き込みアクセスを共有するという考えに開かれています。このアプローチは、書き込みアクセスを共有するために、Trusted Committersのチームのコントリビューターと十分な信頼を築くためのプロセスを必要とします。これは、コントリビューターとの長期的な関係がある場合に特に役立ちます。共有書き込みアクセスは、レビューボトルの首を削除することができます。 *最終段階では、Trusted Committersのチームは、プロジェクトビジョンとミッションだけでなく、次の書き込みアクセスを取得して、制御を共有する準備ができています。これは多くの場合、コントリビューターからのコミットメントの最高レベルの結果、それはまた、チーム境界を交差する調整の高いレベルを必要とします。また、プロジェクトに関する決定を行う際の透明性の最高レベルが求められます。

各ガバナンスレベルをまとめるには、コラボレーションと協調への異なるアプローチが必要です。 * 共有の増加により、コミュニケーションと協調の必要性が増加します。 * 共有アカウントの増加により、意思決定を遅くすることができます。

プロジェクトが貢献を奨励したい場合は、チームメンバーにとって暗黙的に明確であるものは、最も効果的で文書化されています。 * 変更を提出する際に期待する応答時間 * 通信チャネルは、Trusted Committersのチームに触れるときに使用するため * 通信チャネルは、プロジェクトをコントリビューターとしてフォローしようとするとき * プロジェクトから期待するガバナンスレベルは、ホストチーム全体がコントリビューターに合意し、通信しなければならないすべてのトピックです。

InnerSourceプロジェクトにおける経理能力の共有が増加し、性能評価に影響します。階層的な設定では、多くの場合、チームへの貢献を検討しています。しかし、InnerSourceコントリビューターは、自分のチームの外に影響を与えるようになりました。 InnerSource Trusted Committersは、自分のチームの範囲の外にあるチームに影響を与えます。つまり、ダイレクトラインマネージャーは一定レベルの制御を失います。彼らはまた、直接的な監督を失います。その結果、潜在的なリモートチームからのパフォーマンスフィードバックは考慮に入れるべきです。

クロス機能チームの共通ベストプラクティスは「ビルドして実行」です。下流のユーザーから潜在的に来る貢献で、このベストプラクティスは壊れているようです。そのコンテキストでInnerSourceを使用する方法はいくつかあります:

オプション番号は、複数のモジュール化に移動し、チーム間で同じ部分だけをコラボレーションし、ローカルの操作を維持することです。
API の破損を避けるために、契約テストと連携する。
内部サービスレベルの合意と連携し、コントリビューターは、生産システムを破壊するホストチームの恐怖を取り除くために保証期間に署名します。

オープンソースとの関係

InnerSourceは、法人のお菓子の中でオープンソースのコラボレーションのベストプラクティスの適用です。これは、InnerSourceと並行してチームのためのオープンソースの2つの側面を理解しやすくします。

InnerSourceのように、オープンソースプロジェクトは異なるガバナンスレベルを持っています。すべてのオープンソースプロジェクトが同じように作成されるわけではありません。一部のグループがソースコードを公開するだけでなく、インタラクションを期待しないと、ダウンストリームのユーザーがアクティブになり、パッチを提出する必要もあります。その他のプロジェクトでは、オープンソースプロジェクトへのインパクトを共有できるプロセスを設定します。これらのガバナンスレベルを理解することは、オープンソースプロジェクトがオープンソースのガバナンスを考慮に入れるかどうかを判断することを意味します。 InnerSourceプロジェクトのダウンストリームユーザは、移動速度とプロジェクトの移動速度が遅くなるが、プロジェクトを一緒に影響することができないバランスを正しく評価するために学習しました。

InnerSourceプロジェクトで作業することで、チームがプラットフォームを一緒に構築するためのコストと労力を分かち合う手段を実践するのに役立ちます。チーム全体で作業を共有することで、より迅速に作業を革新することができます。異なる焦点領域を持つ製品チームは、必要なベースプラットフォームを開発し、その結果のメンテナンス負荷を迅速に共有することができます。

同じダイナミックは複数のオープンソースプロジェクトを駆動します。これらのプロジェクトへの参加は、InnerSourceの経験を持つチームにとって自然であることを意味します。実践的な経験から動的であることを知ることは、これらの原則に基づいて、オープンソースプロジェクトが開発されているかを認識するチームにとっても容易になります。典型的には、この理解は、オープンソースプロジェクトが内部での使用を決定する影響も持っています。

プラットフォームは、多くのチームが必要な機能で、ローカルに何度も何度も再実装するのではなく、コラボレーションすることで作成できます。つまり、共有の努力が皆のためにパイを大きくする方法の概念を理解しやすくなります。そして、内部でのみオープンソースの方法で行われる場合、業界標準を駆動するのに役立ちます。

メカニックの面では、両方の慣行が非常に似ています。主な違いは、企業に限られているInnerSourceのプロジェクトの可視性であり、オープンソースの公開です。

紙の小さな違いは、練習の大きな違いです。オープンソースは、各メッセージとすべてのメッセージが公開され、永遠にアーカイブされることを意味します。この影響は、従業員がその働き方に慣れていないために特に非常に不快であることができます。また、公正な行動手段として、パブリック・スカルチニにも入手可能であり、企業コミュニケーションの専門家によって、あらゆる動きを放棄することはできません。同様に、生産されたアーティファクトは、ライセンスの遵守、セキュリティ、および競合他社のなどに関して、潜在的な将来の新しい雇用のために、顧客のための公開のスクラッチのために利用可能です。

一方、それはまた、その上に、競合他社が共通の技術的なプラットフォームを構築し、革新し、互いに競合する共同競争をもたらすことができる極端に取られた1法人の壁の外で他の人とコラボレーションするためにドアを開きます。

オープンソースを利用すると、法的な組織の境界線を横断して連携する税制が減ります。多くのInnerSourceの努力のための熱い話題としてprizingを転送している間、それは任意のオープンソースプロジェクトのために無関係です。

「オープンソースとしてプロジェクトを出版する」ということは、オープンソース空間で活動するということを語る最初の考えです。 InnerSourceで経験すると、プロジェクト全体を公開する唯一のオープンソース空間でアクティブになっている方法であることが明らかになります。

代わりに、それは啓発された自己の関心ポイントを採用するためにはるかに自然です: * チームは、そのコンポーネントの重要な部分に特定のオープンソースの依存関係を使用している場合、それは上流であることを保証することが重要である – 唯一の目標は、プロジェクトの将来のロードマップを理解することです。 * チームは、彼らが依存するオープンソースプロジェクトの変化の必要性がある場合、InnerSourceの経験は、参加する利点を明らかにします。明らかに、それは「シェアリングはカーリング」だけでなく、貢献するマインドについてではありませんが、それは、経済上の利益を上回っています。

オープンソースプロジェクトが内部で採用し、使用することの決定でさえ、別のステップを取り戻すと、チームのInnerSourceの経験によって影響されます。 * InnerSourceは、プロジェクトが明確で、アーカイブされ、検索可能な通信チャネルを持っているために重要な理由を理解し、個人的な経験から、コラボレーションとコミュニケーションの方法の面で探すものを理解するためにチームを訓練します。彼らはまた、すべての主要なプロジェクト決定がこれらの通信チャネルで撮影されることが重要である理由を理解します。 * InnerSource チームの異なるガバナンスレベルを理解することは、さまざまなレベルのオープン性に応じて動作するオープンソースプロジェクトの影響を理解するために準備が整っています。