さまざまなプロジェクト領域での責任の分離
「エリア」とは、通常、製品全体の一部である比較的大きなユニットまたはサービス、つまりAPIサービス、位置情報サービス、倉庫サービスなどを意味します。
コンテキスト：7年間開発されている20以上の個別のサービスを備えたプロジェクト。最初から書き直されているので、数えれば25年以上の歴史があります。開発とメンテナンスを継続するために、1年ほど前に新しいチームが雇われました。現在10人の開発者がいます。
通常のワークフローは、新しいアイテムが到着すると、プロジェクトエリアに関係なく、開発者に割り当てられ、開発者がその解決を担当します。
私が見る限りコードベースは大きく、特にタスクによってランダムにさまざまな領域に配置されている場合は、アプリの隅々まで誰も知ることができないため、昨年はこのような方法で開発するのは少し無秩序でした。
質問：開発者に一部の領域（サービス）を担当するように割り当てて、1〜2のサービスを詳細に学習し、それについての知識を維持できるようにするのは合理的な考えですか？たとえば、同じ開発プロセスを維持することができますが、誰かが自分の領域にプルリクエストを作成したときに品質のコードレビューを実行したり、必要なときにアドバイスを提供できる人がいます。
近い将来、これについて社内で話し合う予定です。私は個人的にどんな欠点も見ません、そして誰かがそのようなアプローチ、その長所と短所、あるいはおそらく現在のワークフローを改善することができる方法に関する他のアイデアで経験をしたかどうか聞きたいです。
非常に複雑な製品の場合、「エリア」ごとに何らかの専門化を行うことは理にかなっています。
あなたが正しく指摘したように、誰もそれをすべて知ることはできません。したがって、すべての人にすべての責任を負わせると、（表面的な）コンポーネントの知識が失われ、最適ではない、または重複する変更、リグレッション、そして最終的には保守不可能な製品になる可能性があります。
一方、チームを「エリア」だけで編成すると、専門知識がブームになるサイロの世界が生まれる可能性がありますが、時間の経過とともに相互理解が低下し、システム全体が硬直し、リソースの使用が最適化されない可能性があります。
したがって、重要なのは、これら2つの極端なバランスを見つけることです。例えば：
- 「領域」ごとに1つまたは2つの「コンポーネント所有者」がいると、高いコンポーネント知識を維持し、各領域内の設計の一貫性を促進できるという利点があります。
- 2人の「共同所有者」が事業継続を促進します。それにもかかわらず、ペアは2回の作業を回避するために自己組織化する必要があります。
- コンポーネントの所有者は、新しい着信変更の割り当てをまとめて決定できます。これは、全体像を念頭に置き、相互理解を確保するのに役立ちます。
- 1人または複数の開発者による変更の実行は、コンポーネントの所有者と連携して実行されます。変更の実装者は所有者の知識から利益を得る一方、所有者はコンポーネントで何が変更されたかを理解します。
変更エグゼキュータと所有者は、場合によってはsamの個人が実行できる2つの役割です。
この組織はバランスが取れています。物事を成し遂げる孤独な開発者のモデルよりも少しオーバーヘッドが多いです。しかし、品質、保守性、およびチームワークの結果は、追加の対話の価値があります。
あなたの会社の正確な詳細はわかりませんが、よりスマートな方法は次のようになります。
何よりもトップレベルのプロジェクトマネージャーがいます。またはプロジェクトマネージャーのチーム。彼らは新しいプロジェクトを適切に分析し、適切なプロジェクトマネージャーに割り当てます。
プロジェクトマネージャーは要件を分析し、トップダウン 作業分解図（WBS） を実行します。
チームマネージャーは、WBSの各スライスを、エリア/サービスごとに1つずつ、適切なプロジェクトマネージャーに割り当てます。
明確なプロジェクト構造と明確なWBSがなければ、改善の方法はありません。
私が説明したのは、 プロジェクト管理 の「ABC」の「A」だけです。
会社での問題の修正は「簡単な」タスクかもしれませんが、プロジェクト管理と経験を適切に行うには、広範な知識が必要です。