多数のアジャイルスクラムチームを持つ組織には、「エンタープライズアーキテクト」として任命された少数の人々のグループもいます。EAグループは、品質と意思決定の遵守のためのコントロールおよびゲートキーパーとして機能します。これにより、チームの決定とEAの決定が重複します。
たとえば、チームはライブラリXを使用するか、SOAPの代わりにRESTを使用する場合がありますが、EAはそれを承認しません。
現在、これはチームの決定が却下された場合にフラストレーションにつながる可能性があります。十分に考えれば、EAの人々がすべての力を「つかむ」可能性があり、チームはやる気がなく、あまり機敏ではないという感じになります。
スクラムガイドこれはそれについて言いたいことがあります。
自己組織化：開発チームに、製品バックログをリリース可能な機能の増分に変換する方法を教えてくれる人はいません（スクラムマスターでさえも）。
それは合理的ですか？EAチームは解散すべきですか？チームは拒否するべきですか、それとも単に従うべきですか？
回答:
開発チームは、実際の作業を行う職域を超えたスキルを持つ3〜9人で構成されています。
スクラムマスターは、「エンタープライズアーキテクト」をプロジェクトチームの一員として招待する必要があります。そうすれば、建築家とプログラマーの間のコミュニケーションは素晴らしいものになるでしょう。
使用するテクノロジーの選択はソフトウェアの要件の一部です。つまり、何らかの理由で特定のテクノロジーを使用しないという機能要求の一部です。
アーキテクトは、システムとコードベースが自分で話すことができないため、システムとコードベースを代弁します。一般的に、アーキテクトを持つことは、企業、特に社内で構築されたソフトウェアに依存している企業の長期的な最大の利益になります。
アーキテクトは、開発者にバックログを増分（スプリント）に変換する方法を教えているのではなく、どのテクノロジーを使用できるか、使用できないかを言っています。2つの異なる問題を統合しています。
解決策は何も変更しないことです。アーキテクトの制限が厳しすぎる、または強すぎるためにチームが不満を抱いている場合、それはSCRUMとは関係のない人事問題であり、従業員の満足度、そして可能であれば収益の問題としてビジネスの利害関係者に取り上げられるべきです（「アーキテクトがTurbo Pascalを使用できないx%ためy、機能の開発に時間がかかりますz。」）
この種のことは、プロジェクトを完了するために大規模なチームを必要とすることと、アジャイルなチームを小さく保つ必要性との間のバランスを維持するために必要です。
通常、「チームリードスクラム」は、各小規模チームから選出された1人のメンバーで構成されます。これは、自己組織化の性質の一部を提供するだけでなく、高レベルのグループによって行われた決定がアジャイルグループによって受け入れられるように、何らかの表現方法を提供します。
特定のシナリオでは、アジャイルチームの動機付けを止めるために何かを行う必要がありますが、反乱や単純な受け入れはおそらくしないでください。チームは、理想に向かってではなく、優れたソフトウェアを作成するためにあなたがいることを認識する必要があります。同じプロジェクトで同様のことを行うために、それぞれが異なるテクノロジーを使用する異なるチームの束を持つことは、より悪いソフトウェアにつながります。多数の異なるチームが同じプロジェクトで異なるコーディング標準を使用すると、ソフトウェアの品質が低下します。
あなたが必要としているので、いくつかのプロジェクトが仕事に起こっているかについていくつかの合意に来て道を。チームリードスクラムは、他の場所で効果的に使用されます。あなたは何か違うことをする必要があるかもしれません、またはあなたのグループがなぜそれを効果的にしていないのかを調べてください。
質問：このアーキテクトチームが存在する理由は何ですか？考えられる唯一の理由は、さまざまなチーム間の相互運用性を強化することです。または、チームは単一の製品のさまざまな部分に取り組んでおり、このアーキテクトチームは、すべての部分を一緒に機能させるために存在しています。
あなたが言う正確な理由から、このスキームがアジャイル環境でうまく機能するとは本当に思わない。さまざまなチームは自己完結型である必要があり、入力と出力もそうでなければなりません。したがって、出力の制約は、入力の要件の一部としてのみ行う必要があります。しかし、これらの制約は合理的でなければなりません。「ライブラリXを使用しないでください」などの要件は適切ではありませんが、「使用するサードパーティライブラリの数を最小限に制限する」または「他のチームでは使用しない新しいライブラリを追加する」ことを制限する必要があります。大丈夫です。
次に、すべてのチームでアーキテクトチームを解散させ、アーキテクチャの質問に専門知識を活用します。チームの一員になることで、彼らはチームが抱えている問題をよりよく見ることができるようになり、アーキテクチャのコア部分の変更について、より良いアイデアや教育的な意見を持つことができます。また、チーム間でアーキテクチャの一貫性を維持するために、チーム間でアーキテクトが通信することをお勧めします。
Scaled Agile Frameworkのグループはこれについて非常によく話します。私たちのほとんどはチームレベルで対処しますが、規模を拡大するときは、プログラムレベルとポートフォリオレベルでも果たすべき役割があることを認識する必要があります。アーキテクチャの決定は組織全体で行う必要があり、それは組織の下位レベルで起こっていることを反映する必要があります。アーキテクチャの決定に問題はありません！
これに関連して、Dean Leffingwellのアジャイルソフトウェア要件に関する最近の本は、このトピックに関する良い読み物であり、私は自分で読んでいます。
また、複数のアジャイルチーム（一部はカンバン、一部はスクラム）、およびアーキテクトもいます。アーキテクトは、すべての製品（ヘルパーライブラリ、認証、インフラストラクチャの構築）などにまたがるインフラストラクチャを担当します。技術的な決定を下しますが、大部分はインフラストラクチャコンポーネントを実装します。
これはうまく機能し、通常は競合はありません。1つの重要なポイントは次のとおりです。
建築家はチームに対する正式な権限を持たず、単にチームを覆すことはできません。通常、設計者はすべての製品に適用される決定を行い、チームは製品について決定を行います。競合が発生した場合、アーキテクトとチームは合意に達するか、経営陣にエスカレートするだけで済みます（めったに起こりません）。
建築家と開発者を同輩にすることは本当に重要だと思います。両方とも、異なる分野でのみ共通の目標に向かって働きます。誰も他方を単に「覆す」ことができないなら、協力はより良くなるでしょう。
ここには競合は見られません。私が理解していることから、すべてのEA（私はそう思いますが、タイトルは尊大です）はQAです。誰もがそれを知っている必要があります。
あなたはにいることを、考慮しなければならない任意の（1検討されているに値する）開発方法論の要件が集まって、それが反復的または先行のかどうかの重要なステップです。
これらの要件の一部は、会社のポリシーによって設定されています。そして、これらは基本的なルールを設定します：
しかし、どちらにしても、要件は満たされているかどうかのどちらかです。その決定を下すのが難しい場合、要件は不足しており、真にテスト可能になるために（より広い意味で）繰り返す必要があります。これを要件の繰り返しとして処理する必要があります。
アーキテクトは、アジャイルチームが下した決定を無効にすべきではありません。アーキテクトは、これらをチームに渡す要件/ストーリーに含める必要があります。プロジェクトの状況が変化し、新しい相互運用性要件が導入された場合、チームは常に最新の状態に保つ必要があります。
建築家が注文を出し、技術的な決定を審査することは文化的な欠陥です。彼らは自分自身を単に共有された目標/ビジョンを維持し、同じページに別々のチームを維持するのではなく、「ボス」と見なします。アジャイル手法は、コミュニケーションと連絡に基づいています。建築家が決定を下すまで関与しないと、彼らはアジャイルに失敗します。
マーティン、自己組織化チームがその環境でどのように機能するかについて誤解しているかもしれないと思います。
あなたはスクラムガイドを引用しました：「誰も（スクラムマスターでさえ）開発チームに、製品バックログをリリース可能な機能の増分に変える方法を教えません。」
これは、スクラムチームが、会社全体のテクノロジーとビジネスニーズ、および他のチームのニーズを考慮せずに、（提供する限り）何でもするためのライセンスではありません。
確かに利害関係者は彼らの影響を濫用することができます。これはコラボレーションの課題の1つであり、EAに限定されるものではありません。しかし、コラボレーションはチームの境界で終わるわけではありません。
ウォーターフォールまたはスクラム（これは2つを混合しているように見えますが、これは機能しません）、そもそも私にとってかなり無意味な管理層のように聞こえます。技術決定のゲートキーパーは、開発者がアプリを技術選択のハイドラに変えないようにするための仕事である開発の全体的なマネージャーであり、予算が潜在的な法案を立てなければならないリード開発者でなければなりません。
開発者以外の人たちが実際にテクノロジーの決定をするためのゴールを持っているように、それらの決定の結果に苦しむ実際の人々に相談することさえしなければ、私をumb然としません。