アジャイル開発において、コンポーネントチームが機能チームよりも優れているのはいつですか？
アジャイルなコンテキストでの組織構造に関しては、機能チームの方が一般にコンポーネントチームよりも優れていると多くの人が主張しています。これは少なくとも、私の現在の立場と以前の立場の両方で、同僚と話し合うときに見つけたものです。また、LarmanとVoddeは、コンポーネントチーム（リーンとアジャイル開発のスケーリングの実践）に激しく反対し、スクラムプライマー（ http://scrumprimer.org ）にもその立場をもたらしました。
ただし、機能チームとコンポーネントチームのどちらを選択するかが「オールオアナッシング」ではないこと、およびコンポーネントチームが（少なくとも数人）いる方が賢明な選択になる基準があることを示す出典は存在します。たとえば、 https://www.scaledagileframework.com/features-and-componentsの例 では、著者は、高度な再利用性と高度な技術的専門性がコンポーネントを作成する基準であることを示していますシステムのそのそれぞれの部分のチームは有利です。彼らの本の中でマイク・コーンとケン・ルービンもよりバランスのとれた見方をしています。
私の専門的な環境（自動車サプライヤー）には、伝統的に多くのコンポーネントチームがあります。アジャイルな作業方法への移行を行う際、多くの同僚は、コンポーネントチーム構造を維持すると、経営陣が根本的に何か間違っていると感じています。私はいくつかの理由でこのようにそれを見ていません：
- まず、自動車サプライヤーが製品として提供するのは、車両の観点からは単なるコンポーネントです。実際の顧客機能は車両レベルです。したがって、結果的かつ理想的には、機能チームは（サプライヤとOEMの境界を越えて）車両をまたがって作業する必要があります。しかし、それは可能な作業方法として議論されることすらありません。
- オペレーティングシステム（Linux、QNX、AutoSarなど）などの使用中のコンポーネントのロット、標準ライブラリ、サードパーティライブラリ（ナビゲーション、音声認識）、オープンソースライブラリなど...そして、これらのほとんどのライブラリでは、とにかくライブラリの内部を改善する専門知識はありません。ちょっと皮肉な言い方をすると、他のチームが使用するコンポーネントを開発することは便利ですが、独自のアジャイル組織でコンポーネントを開発することは悪い選択ですか？
- そして、確かに、人々とチームが年間にわたって深い専門知識を開発してきた多くの分野があり、この専門知識は、コストのかかるフィールドリターンを回避するために本当に不可欠です。 。パワードロップが任意の時間に発生するフィールドのすべての状況で機能するソフトウェア更新戦略を開発することは、ごく少数しかできないことです。したがって、より大きなプロジェクトの全員がそのソースツリーに変更を加えることができる場合、高いリスクがあります。同様に、セキュリティ機能は至る所にありますが、詳細や車両固有の通信プロトコルなどを理解しているものはほとんどありません。
さて、私の質問：アジャイルなコンテキストで作業しているときに、特定のソフトウェア開発シナリオのコンポーネントチームを有利にすることができる他の基準（再利用の程度と技術的な専門知識を除く）は何ですか。
「アジャイル」の重要なポイントの1つは、チームが短いサイクルで成果物を作成することを意味します（スクラムスピーチでは「スプリント」と呼ばれます）。したがって、このコンテキストで本当に重要な唯一のことは、IMHOです：より大きなシステムのコンポーネントは、ほとんどの場合独立したリリースサイクルを持つことができるため、個々のスプリントで開発できますか？
答えが「はい」の場合、コンポーネントチームで「アジャイル」を使用することを禁じる理由はありません。各コンポーネントは、明確に定義されたインターフェース、独自のバージョン管理、独自のテスト、独自のドキュメント、および異なるコンポーネントの開発を互いに絡み合わせないSprint計画を備えた「独自の成果物」である必要があります。
あなたはすでにこれがうまくいくいくつかの例を示しました：オペレーティングシステムや他の特別なサードパーティライブラリのようなコンポーネント：前者に依存するコンポーネントの開発はすでに利用可能な機能の上に計画されています各スプリントの（たとえば、Linuxシステムや音声認識システムなど）。そのため、チームがLinux V123.4の上に音声認識システムを利用して新しいマルチメディアセンターを開発する場合、「検出率が向上した音声認識コンポーネントの新しいリリース4.0」がいつ利用可能になるかは、スプリント計画にとって重要ではありません。そうでない場合、またはLinux V123.5が利用可能かどうか-チームは、新しいバージョンの有無にかかわらず、マルチメディアセンターの次の10のスプリントに取り組むことができます。
反例として、すべての新機能の開発で常に「フロントエンド」と「バックエンド」を並行して変更する必要がある多層Webアプリケーションを紹介します。バックエンドチームとは別にフロントエンドチームのスプリントを計画できない場合、スプリントで作業すると、チームの間に摩擦が生じます。なぜなら、一方が常に他方を待たなければならないためです。したがって、この種の開発は、機能横断型のチームでうまく機能するでしょう。計画されたスプリントが終了する前にフロントエンドアクティビティが行われる場合（またはその逆）、フロントエンドで作業した利用可能な開発者がバックエンドを完了するのに役立つためです。スプリントのアクティビティ（またはその逆）。
必要に応じて、既存の各コンポーネントチーム内で俊敏に対応できます。そして、それがどこに行くのか見てください。しかし、研ぎ澄まされた多分野の生産組織の最上位にアジャイルを課すことは、破壊的で破壊的であり、混乱を引き起こし、業務をひどく停止させます。
アジャイルは所有権を殺す
これはすべての状況で必ずしも悪いことではありません。単一障害点に対処するための方法かもしれません。尋ねる質問は常にあるべきです：私たちはこれをする余裕があり、そして突然それをする余裕があるのでしょうか？
品質だけでなく社会的にも影響があります。ジョンが彼が長年取り組んできたコンポーネント、彼が責任を感じていること、彼が誇りに思っていること、つまり彼の赤ちゃんが、誰もがいじり、おしっこをするために突然そこに出るとどう思いますか？彼はどのように「まあジョン、あなたはあなたが一生懸命働いていくつかの専門知識を積み上げたと感じるかもしれませんが、私たちにはあなたのためのニュースがあります：私たちはそれを信じていません、誰でもあなたの仕事をすることができると思います！後部座席に座って、これまでかなりうまくやってきた同僚が、あなたがしたことすべてを台無しにしてしまうのを見てください。」ジョンはいくつかの忠誠心の問題を抱えているでしょう。
慣れ親しんでいない部分の小さな火を消すためにあちこちに送られることは不満であり、有能な人々は最終的に去ります。そして、これはアジャイル/スクラムが不注意に実装された場合にしばしば悪化するものです。誰も何も所有していないため、誰も何に対しても責任を感じず、何も気にせず、何でも上手になります。
アジャイル/スクラムは、プロセスがまったくない場合に最適です。機能しているいくつかの履歴を持つシステムがある場合、得られる以上のものを失わないように非常に注意する必要があります。