学習パス：プロダクトオーナー

プロダクトオーナー セクションでは、このロールが InnerSource に適合する方法について説明します。

導入

中間管理が困難である方法

主要な利点はInnerSourceプロセスに造られます

新しい役割と責任

リキャップとテイクアウト

オープニング

ワークブック

TIP: 複数の回答は、いくつかの質問で正しいかもしれません。

1. 従業員のための市場での厳しい競争のために有能な開発者の欠如
2. プロジェクトを成功させるために、マネージャーの役割に対する認識の欠如
3. 組織のビジョンへの入力の欠如
4. 資金配分における明快さの欠如

なぜ 1 が間違っているのか: 資格のある開発スタッフのための競争は確かにこの時点でコンピュータ分野の問題ですが、InnerSource はそれに対処することができません。 開発者が地面から湧き上がることはありません。

なぜ2が正しいのか:ビデオは、中間管理の多くの活動の不可視性を強調した。 InnerSourceは、これらの管理者は、組織の境界を横断する議論に関与する機会を与え、その記録トレイルは、貢献の証拠を維持します。

なぜ 3 が正しいのか: ミドル マネージャーは、上司の管理によって作られた選択肢を遂行する責任があると感じますが、それらの選択肢に影響を与えることはできません。 対照的に、InnerSourceは管理者が他のチームとコミュニケーションをとるようになり、自身の影響力を拡充し、プロジェクトの背後にある目標とビジョンの形成でより活発に参加する機会を提供します。

なぜ 4 が間違っているのか: InnerSource は資金に対する直接的な影響を持っていないので、このビデオセグメントでは資金調達は議論されていません。 しかしながら、InnerSourceの採用は資金に対する間接的な影響を持っています。プロジェクト上の作業は複数のチームによって共有され、管理は資源が異なることを認識しなければなりません。 具体的には、チームメンバーごとのコーディングの量は、コミュニケーションとドキュメントの恩恵にわずかに縮小されますが、プロジェクト全体の出力はコラボレーションのおかげで増加する必要があります。

TIP: 複数の回答は、いくつかの質問で正しいかもしれません。

1. 責任あるチームが優先的に割り当てるので重要な機能を実装する遅延
2. 外部から提出されたバグ修正のスロー統合
3. ミドルマネージャーの貢献の価値を認める失敗
4. いくつかの主要な開発者に制限されている知識

なぜ 1 と 2 が正しいのか: 従来の組織では、ホストチームだけがコードを変更することができます。 他のチームは、要求を提出し、重要性が認められているまで待つ必要があります。 InnerSourceでは、緊急に変化が必要な外部チームが、ホストチームからのガイダンスでコード化できます。

なぜ3が正しいのか:InnerSourceは多くの異なるチームからの貢献を必要とするので、計画は公開され、共有する必要があります。 これは、協調だけでなく、マネージャーと彼女のチームがより大きな組織を作る貢献を強調するだけでなく、.

なぜ 4 が正しいのか: InnerSource は、コードとガイドラインの両方で文書と透明性を呼び出します。 主要な開発者が葉を離れるか、忙しい場合は、他の人に知識が利用可能になります。

1. 企業基準
2. プロセス
3. ドキュメント
4. 達成のためのクレジット

なぜ1、2、3が正しいのか:標準、プロセス、およびドキュメントは、複数のチームが共有プロジェクトのコードを生成することを可能にするコラボレーションの重要な要素です。 規格、プロセス、および文書をコードとともに共有することで、それらを明示的かつ簡単に消費し、維持することができます。

なぜ4が正しいのか:バージョン管理、メッセージボード、その他のツールは、何が起こったのかを記録し、誰が貢献したかを保存します。 透明性とオープンなアクセスにより、可視性を確保し、InnerSourceプロジェクトで達成するための適切なクレジットを有効にします。

1. 必要な機能を実装する他のチームに対するより大きな依存性
2. Looserは、アプリケーションライフサイクル管理へのアプローチ
3. 異なるチームで製品所有者の間でより多くの議論
4. 異なるチーム間で製品の多様なビュー

なぜ1が間違っているのか:各チームは、その要件を満たす必要があるスタッフとリソースを持っている必要があります。 InnerSource で実行すると、外部チームがホスティングチームで必要な機能やバグ修正を実施する場合があります。 しかしながら、ホスティングチームの商品プランの一部ではなく、ラッキーな偶然とみなされるべきです。

なぜ2が間違っているのか:要件定義、コード開発、テスト、コードベッティング、およびデプロイメント—アプリケーションライフサイクルのさまざまな部分は、常に重要である。 信頼できるコミッタは、外部者がライフサイクルを尊重し、チーム基準に従って品質を確保することを確認します。

なぜ3が正しいのか:コントリビューター、信頼できるコミッタ、および製品所有者は、InnerSourceプロジェクトに関するより多くの議論をすべて保持し、ソリューションを見つけることに協力しています。 他の製品所有者からの入力は、ユーザーの貴重な知識、プロジェクトの歴史、スタンブルブロック、およびその他の事柄を体現しています。 これらは価値のある余分な通信をします。.

なぜ 4 が間違っているのか: InnerSource は、誰もが何をすべきかを一貫したビューを持っているように、チーム間のコミュニケーションを促進します。 チームには異なる目標があり、その目標を達成するためのプロジェクトに取り組むことができますが、彼らは彼らの製品を見ることに統一する必要があります。

1. チームがコードベースを共有しているため、必要が少ない
2. プロジェクトリーダーが効果的なコラボレーションを行うため、トレーニングやメンタリングが必要
3. ミドルマネージャーのパワーアップ
4. できるだけ多くの書式を書く必要があります

なぜ1が間違っているのか:InnerSourceでこれまで以上にコラボレーションと交渉が重要になります。 貢献者は、彼らが変更したいことを説明し、なぜ. 信頼できるコミッタは、プロジェクトが成功し、コードベースでうまく機能していることを確認するためにそれらと連携します。

なぜ2が正しいのか:一般的には、プログラミングのスキルを持つ大学や他のトレーニングプログラムから出て来て、おそらくエンジニアリングとプロジェクト管理。 しかし、そのようなプログラムは、InnerSourceに重要なトレーニングとメンタリングの価値を認識したり、教えることはめったにありません。 企業は、自分のトレーニングでギャップを埋めることを検討する必要があります。

なぜ 3 が正しいのか: ミドルマネージャーが参加できるので、ファッション、他のチームの決定、チーム自身の目標をより簡単に達成できます。

なぜ 4 が正しいのか: 重要な目標と進行方法の同じビューを持っていない場合は、共有目標に参加することはできません。 ドキュメントは、重要なタスクや手順を開始する前に、誰もが同意することを確認するのに役立ちます。

TIP: 複数の回答は、いくつかの質問で正しいかもしれません。

1. コントリビューターが次の作業をするべきことを知らせます。
2. すべてのコントリビューターのリクエストが製品に入ることを保証します。
3. チームが他のチームと同じプロセスを使用するようにします。
4. 外部のコントリビューターを招待して、コーディング基準とUI/UX基準を記述します。

なぜ 1 が間違っているのか: InnerSource はコントリビューターに依存して、自分のニーズに基づいて作業することを決定します。 InnerSourceは、製品所有者は、次の作業を行うために、自分のチームのために決定することができますが、独自の基準に基づいて動作するように自己選択を貢献します。 信頼できるコミッタは、特定のプロジェクトで作業するコントリビューターを奨励することができますが、そうする決定は、コントリビューターと休む。

なぜ2が間違っているのか:InnerSourceコントリビューターは、作業が終わるまで自分の運命を所有しています。 製品の所有者は、作業が行われるべき仕事に同意するかもしれませんが、最終的にはコントリビューターが時間を作るために、作業を行い、作業がホストチームの製品の一部になることができるように、信頼できるコミッタフィードバックに応答します。

なぜ3が間違っているのか: DIfferentチームは、製品が異なるツールやプログラミング言語を選択したり、歴史や文化的な理由から、異なるプロセスを使用する可能性がある。 プロセスの違いは、InnerSourceの方法でチームを一緒に作業することを防ぐものではありません。 しかし、各チームは、そのチームのコードで作業する際に、そのプロセスを文書化し、別のチームのプロセスを学ぶ必要があります。 外部は、チームのプロセス、コーディング基準、UI/UX基準を文書化するのに役立ちます。

なぜ 4 が正しいのか: 外部の人たちは、ユーザーのニーズとこれらのニーズを満たすための堅牢な方法について、重要な視点を持ってくることが多いです。 チームの基準を審査し、貢献できる。 製品の所有者と信頼できるコミッタは、基準への勧誘をすべきである。

1. リソースのニーズと期限を推定するのに役立ちます
2. ユーザーインターフェイスまたはユーザーエクスペリエンス(UI/UX)のドキュメントを作成する
3. 他のチームで作業を重複する
4. トレーニングコントリビューターでアドバイスを書く

なぜ 1 が間違っているのか: 信頼できるコミッタは、リソースのニーズと期限を決定するのに価値のある入力を提供できます。なぜなら、コントリビューターのコードと機能の状況をよく理解しているためです。

なぜ2が間違っているのか: 信頼できるコミッタは、それらのニーズを満たすコードを作成するためにエンドユーザーのニーズも理解する必要があります。 そのため、信頼できるコミッタがUI/UXのドキュメントで動作するのは合理的かもしれません。

なぜ3が正しいのか:InnerSourceのポイントは、一緒に機能に興味を持っているすべての人をもたらすことです。そのため、必要なコードを単一の場所に作成することに協力することができます。 重複はアーキテクチャが悪いため、無駄です。

なぜ 4 が間違っているのか: 信頼できるコミッタとコントリビューター間のほとんどの通信は頻繁に異なる場所にあるため、書かれ、非同期です。 さらに、書面によるコミュニケーションは、何をしたのか、なぜかの記録として残っています。 将来のコントリビューターのトレーニングに役立ちます。 書面による通信を記録するメール以外にも、メールは人気があり便利な媒体です。

1. 上部管理。
2. 外部コントリビューター。
3. スクラムマスターズ。
4. 信頼できるコミッタ。

なぜ 1 が間違っているのか: 上層管理は、ビジネスの戦略的な優先順位を設定することができますが、一般的に InnerSource による地上実装に関与していません。

なぜ2が間違っているのか:コントリビューターが見つかったら、信頼できるコミッタはプロジェクトへの貢献を成功させるためにそれらをサポートする主要な責任を持っています。

なぜ3が間違っているのか:スクラムはInnerSourceプロジェクトで使用されていないか、またチーム(特に地理的に遠隔にあるチーム)全体でうまく機能しないかもしれません。 重要なInnerSourceプロセスは、スクラムなどのチームの努力ではなく、意欲的な個人へのサポートを含みます。

なぜ 4 が正しいのか: 信頼できるコミッタは InnerSource を地面で動かします。 彼らは、他のチームが両方のチームのために動作する方法でコードベースを作る変更を促進することに鍵です。

1. プロジェクトのアップデートは、プロジェクトを進めるために必要です。
2. あなたのプロジェクトが会社にいかに重要であるか、そしてそれを助けたいと思うか見ます。
3. 貢献は、新しい技術領域で仕事をすることで、エンジニアリングスキルを成熟させることができます。
4. 彼らのチームプロジェクトは、あなたの貢献と重複し、チームリソースの両方をプールする方法です。

なぜ 1 が正しいのか: バックログの機能は、特定のチームにまだ非常に重要なプロジェクト全体に重要でないとき、InnerSource の貢献は、あなたのバックログやプロジェクトにアイテムを出すための素晴らしい方法です。

なぜ2が間違っているのか:誰もが自分の仕事で忙しくなります。 あなたのプロジェクトでの仕事が会社の成功に不可欠である場合でも、それは単独でaltruismによって他の人からの追加の助けを得るのとは異なります。

なぜ3が正しいのか:実際に新しい技術で働いているのは、それを学ぶための最良の方法です。 エンジニアは、常に新しいスキルを学習し、InnerSourceの貢献を通じて、同時に会社を助けるための素晴らしい方法です。

なぜ4が正しいのか:InnerSourceは、重複したエンジニアリングサイロではなく、単一のコードでコラボレーションするプロジェクトを重複または重複させることで、開発コストを節約します。

TIP: 複数の回答は、いくつかの質問で正しいかもしれません。

1. チームの他のチームでのアウトプットに対する責任
2. プロジェクトをコントロールする
3. 他のチームとの時間のかかる相互作用を減らす
4. 他のチームの入力を活用することで、より多くのタスクに対応し、より迅速に対応

なぜ 1 が間違っているのか: チームはタスクに割り当てられた責任を負います。 InnerSourceは、他のチームがコードベースをアップグレードして、ニーズを満たすのに役立ちますが、タスクを引き継ぎません。

なぜ 2 が正しいのか: チームが別のチームのコードベースに貢献したときに、必要な時間枠で必要な機能を実装し、開発者の時間を必要としているものを投資することができます。 別のチームがあなたのものに貢献すると、機能がどのように実装されているかを少し制御を解除しますが、外部の助けを借りてオーバーラップのニーズをより効果的に満たすことができます。

なぜ3が間違っているのか:InnerSourceを採用した後、他のチームとの相互作用が大幅に増加します。 インタラクションに費やした増加した時間は、チームがより効率的にニーズを満たしているため、オフになります。

なぜ 4 が正しいのか: InnerSource は、ペントアップの需要や時間を持つチームのための出口を提供し、プロジェクトの機能を強化しながら、彼らが必要とするものを与える方法であなたのプロジェクトに貢献します。

1. 他のプロダクト所有者と交渉して下さい。
2. チームのプロジェクトを会社の他の部分に販売します。
3. 信頼できるコミッタの役割を支えて下さい。
4. オープン計画の実践を採用。

なぜ 1 が正しいのか: InnerSource は、製品所有者が 1 つのチームから他のチームへの貢献を設定するために直接交渉することを可能にします。

なぜ2が正しいのか:コントリビューターは「開く」と宣言されているため、プロジェクトに常に群れていません。 貢献し、それがそうする素晴らしい考えである理由を彼らに伝えることに興味がある人々を見つけて見つけます。

なぜ3が正しいのか:コントリビューションが整ったら、信頼できるコミッタロールは、提出されたコードが実際にゲストとホストチームの両方の必要性を満たしていることを確認してください。

なぜ 4 が正しいのか: 計画を開くと、他の人とのコラボレーションが容易になります。 決定と情報はオープンにあるので、組織の政治は減少し、人々が行うべき仕事とそれを達成する方法に焦点を当てることができます。