機能の所有権は良い習慣ですか？

最近、私の会社では、1人の開発者が1つの機能に集中する（そして1人だけ）ことが推奨されています。それは、開発者を通常のチームルーチンとは別に設定し、他の責任（会議など）から解放するようなものを意味します。この人は、テクノロジに関して「唯一の」責任を負います。

記録のために、SAFe内でSCRUMを使用し、チームごとにフルタイムの開発者がいて、2つのチーム（AndroidとiOS）の間でQAと製品所有者を共有しています。

これは短期的に生産性を高めることに同意しますが、多くの理由でこれは悪い習慣であると感じています（そして大学で学んだと思います）。

コードレビューは価値を失います。
最小限の知識共有。
リスクの増加。
チームの柔軟性の喪失。

私は正しいですか、それとも悪い習慣ではありませんか？

agile team code-ownership

— ムデロルモ
ソース

私の当面の反応は、これが適度に行われればうまくいくかもしれないということです。しかし、それが行き過ぎた場合、あなたは問題について正しいです。一方、私の経験では、すべての機能には既に事実上の所有者がいます。つまり、多くの時間を費やした最後の人です。

— Ixrec

「1人の開発者が集中する必要があります（1人のみ）」-SPOFが必要な場合は、そのようにすることをお勧めします。私は最近、あなたが特定の状況（「で最も必要人は旨を実証的理論策定WTF？！？なぜ彼がそのように書いたの？」）は、一般的に、実際に絶対に到達できない正確に一つです。

— JensG

@JensG：まあ、私は私が最も頻繁に必要とする人（「wtf？なぜ彼はそのように書いたのですか？」）が私であり、そのように「書き留められるべきものを記憶する」ためのバス要因であるという経験的理論を持っていますそれは、他の誰かにブロックされたときにもっと注目に値します。なぜなら、既存のコードをゼロから再検討する代わりに、それ自体のメリットを再検討するのではなく;-)

— スティーブジェソップ

@SteveJessop：もちろん、顧客があなたに今解決策が必要だと叫んでいる間（または他の！）無駄に時間を割いて面白いものを見るほどオタクではないので、代わりにもっと生産的に過ごすことができます。

— JensG

@JensG：幸いなことに、私の顧客はあなたの顧客よりも社交的です。したがって、私にとって重要なことは本当に人々が私に到達しにくくなるという結論に至るような魔法の思考に従事するほどプレッシャーはありません。そのため、あなたが言ったことに冗談を言う要素があると思ったので、はい、私はあなたがそれがどのように機能するかを覚えている複数の人を引き留めようとすることによって理解できないコードを補うという面白い状況を見つけるのに十分オタクです。特に、そのようなwtfsは頻繁に私自身の愚かな欠陥であり、同僚のものではありません。

— スティーブジェソップ

回答:

私の20年の経験では、コードの所有者に設計者間で責任を交代させるか、少なくとも2人の所有者を持つことが望ましいです。単一の機能の所有権には次の問題がありますが、そのうちのいくつかについて言及しました。

穴の設計者にハトをかけ、成長の機会を制限する傾向がある
すべての卵を1つのバスケットに入れるので、誰かがバスにぶつかったり、やめたりすると、知識に穴が開く可能性があります。
一人の人はコードに問題を見つけないかもしれませんし、ピアの所有者なしではコードレビューははるかに効果的ではありません
誰もが独自のスタイルを使用してコードで作業している場合、コードの一貫性と可読性を維持するのは困難です-これはスタイルのガイドラインで回避できますが、特にデフォルトの動作に依存している設定より規約を使用する場合は微妙に忍び寄ることがあります
開発者は、コードを所有している場合、コードの保護と防御になる傾向があり、コードの進化を妨げる可能性があります-複数の人がそれを所有している場合、この傾向は減少します

— ジェイソン・K
ソース

絶対に。バスファクターは、1人だけの所有権を持つ最も明白な問題として言及することが重要です。

— JensG

ただし、バスファクターは、コストとYAGNI、およびバスが実際に組織を損なうか、単に多くの面倒を引き起こすかとトレードする必要があります。場合、それは永遠に、たとえば、3時間、週を失う二人が代わりに一つだけ、または失うのコードの特定のビットについて教育されていることを確実にすることの間の選択だった、と言う、一回限りの誰かのために自分自身を育てるのように60時間開発者の1人が攻撃を受けた場合にスピードアップするために、多くの場合、1回限りのコストを選択します。しかし、述べられている理由により、知識サイロには他の不利な点がより重要です（それほど明白ではありませんが）。

— スティーブジェソップ

機能の所有権は避けられないものであり、うまくやることは良いことです。それは習熟を築き、自律- 一般的に認められているエンゲージメントの 2つの柱を可能にします。誰がそのコードに対する説明責任を持っているかを明確にし、委任、コミュニケーション、その他の面倒な作業を支援します。

しかし、あなたはそれについて話していません。あなたは1つの新しいチームを作ることについて話している-この人を残りのコードから切り離す。それは素晴らしいことではありません。それは彼らのキャリアを制限します。プロジェクト/会社にリスクを追加します。それは仲間を傷つけます。

したがって、これを悪い考えから遠ざけるために、ある程度の節度が必要かもしれません。

— テラスティン
ソース

単一の人によるコードの所有は避けられませんが、少数の人が所有することに同意しません。私は、コードを共有するという悪い仕事をしたが、同じことをした組織を見てきました。私が見た中で最も効果的なセットアップは、2〜3人がコードを知って共同作業を行ったときでした。これにより、コーダー間のストレスと孤立が軽減されました。これは、障害が発生したときに彼らが自分でフックしていなかったためです。

— ジェイソンK.

@jason-確かに、チームの一員が快適で、コードの一部を扱うことができるはずです。しかし、1人の人間は、主題の専門家が単に最も多くの作業をするだけで終わるでしょう。

— テラスティン

唯一の不一致は、それが避けられない中である私はかなりのオーバーラップを持つことによって、いくつかの人々が地域の中小企業であることとのより良い成功を見ているというだけの理由-最も可能性の高いシナリオであり、その主題の専門知識は、良いことである、それが頻繁に発生することに同意

— ジェイソン・Kを。