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