機能の所有権は良い習慣ですか？
最近私の会社では、1人の開発者が1つの機能に集中する（そして1つだけ）ように提案されています。これは、通常のチームルーチンの脇に開発者を置き、他のいくつかの責任（会議など）を解放するようなものを意味し、この人は機能、テクノロジーに関して「唯一」の責任があります。
記録のために、私たちはSAFe内でSCRUMを使用しており、チームごとにフルタイムの開発者のために、2つのチーム（AndroidとiOS）の間でQAと製品所有者を共有しています。
これにより短期的に生産性が向上することに同意しますが、これは多くの理由で悪い習慣であると感じています（大学で学んだと思います）。
- コードレビューは価値を失います。
- 最小限の知識の共有。
- リスクの増分。
- チームの柔軟性の喪失。
私は正しいですか、それともまったく悪い習慣ではありませんか？
私の20年間の経験では、コードの所有者に設計者間の責任をローテーションさせるか、少なくとも1組の所有者がいる方がよいでしょう。単一機能の所有権には次の問題があり、そのうちのいくつかはあなたが言及したものです。
- それは設計者に穴を開け、成長機会を制限する傾向があります
- それはすべての卵を1つのバスケットに入れるので、誰かがバスにぶつかったり、やめたりした場合、知識に穴が開く可能性があります
- 一人の人がコードに問題を表示しない可能性があり、ピアオーナーのコードレビューなしでははるかに効果的ではありません
- 全員が独自のスタイルを使用してコードに取り組んでいる場合、コードの一貫性と読みやすさを維持することは困難です。これはスタイルガイドラインで回避できますが、特にデフォルトの動作に依存している構成で規約を使用している場合、微妙な問題が発生する可能性があります。
- 開発者は、コードを所有している場合、コードを保護および防御する傾向があり、コードの進化を阻害する可能性があります-複数の人がコードを所有している場合、この傾向は減少します
機能の所有権は不可避であり、うまく機能することは良いことです。それは習熟の構築を助け、自律性を可能にします-2つ 一般に認められたエンゲージメントの柱 。誰がそのコードの説明責任を持っているかが明確になり、委任、通信、およびその他のたわごとを行うのに役立ちます。
しかし、あなたはそれについて話していません。あなたは1つの新しいチームを作ることについて話している-この人を残りのコードから切り離す。それは素晴らしいことではありません。それは彼らのキャリアを制限します。プロジェクト/会社にリスクを追加します。それは仲間に害を及ぼします。
したがって、これを悪い考えから遠ざけるために、ある程度の緩和が必要かもしれません。