ソフトウェアアーキテクチャを担当するアジャイル環境

アジャイルチームでは、現在のスプリントで行われている作業だけでなく、システム全体に影響する高レベルのアーキテクチャと設計の決定を担当するのは誰ですか？

プロダクトオーナー、スクラムマスター、スクラムチーム、または他の誰かでしょうか？

「ソフトウェアアーキテクチャはチーム全体によって実行されます。このプラクティスは、ソフトウェアアーキテクトの必要性を排除するものではありません。ソフトウェアのアーキテクチャ。」

• ソース：http : //www.executivebrief.com/blogs/software-architecture-agile-environment-sashimi-approach/

もちろん建築家ですが、おそらく伝統的な種類の建築家ではありません。

私はすべての思考を行い、サルにすべてのタイピングを任せるリード外科医のような建築家を意味しません。私は経験豊富なリードプログラマを意味します。このプログラマは、逆戻りが困難な決定のコストと利点のトレードオフを理解し、チームに何をすべきかアドバイスします。

効果的なアーキテクトを見つけるのは難しいですが、素晴らしいポジションになる可能性があります。そのため、おそらく、少なくとも1人の経験豊富で思慮深いプログラマーがいて、うまくやれるはずです。そのような人はする必要があります

• もちろん、適切なアーキテクチャを決定するだけでなく、
• アドバイスを効果的に行う方法を知って、他の人が快適にアドバイスできるようにし、また
• アーキテクチャの決定をゆっくりとチームに委任する

この最後のポイントは多くの人をつまずかせます。善意のアギリストが「チームはアーキテクチャを所有している」などと言うとき、彼らはその「正しい」ことを持っていますが、私はその適用においてアドバイスはほとんど完全に無意味であると思います。チームが自分のアーキテクチャに責任を持つと信頼している場合、そもそも質問をすることはないでしょう。そのため、次のいずれかの懸念があるため、質問をすると仮定します。

• 誰も責任を負いませんし、私たちは貧弱なアーキテクチャを持つでしょう、または
• 間違った人々が責任を負い、貧弱なアーキテクチャを手にするか、
• 責任を取る人はスケープゴートになり、あなたはそれを避けたい

誰かが責任を取る必要がある場合は、それを受け入れたい人にそれを与えてください。真剣に。その人は少なくとも気にします。その人が仕事をするのに必要なリソースを与え、必要なときに助けてください。その人がどれほど有能であるかはおそらく関係ありません。気にかければ、学習する必要があるものを学習しようとするからです。当然、そのような人は読むのに良い本の形での支援と、助けや助言を求めることができる仲間やメンターのコミュニティが必要です。

もしあなたが間違った人が責任を取ることを心配しているなら、私はあなたが「正しい人」が誰であるかを知り、彼らを建築家として設置するために戦うことを望みます。The New Strategic Sellingのような本は、それを実現するための販売テクニックを学ぶのに役立ちます。

スケープゴートだけが必要な場合は、他の人を静かに動かして、あなたが最も破壊したり損したい人のキャリアに責任を与えてください。少なくとも正直に言ってください。

効果的なアーキテクトの仕事に戻ると、彼らは自分の仕事を単なる意思決定の立場ではなく、管理の立場と考えることができます。少なくとも最も日常的な決定をチームに委任しないと、彼らはボトルネックになり、組織全体の速度が低下します。トップにアーキテクトを追加しても、それは速くなりません。アーキテクチャの意思決定を一からやり直すこと。委任ボードの技術は、これらのチームは能力を示すことで信頼を得るようチームに、より多くの意思決定を委任時間をかけて、あなたの建築家がより快適になるのに役立ちます。

優れたアーキテクトは、システムをより良く設計する方法を理解するのを助け、私がそれを求めたときに辛抱強く助言し、時には非常に貧弱な決定を下すのをやめる人として考えています。そのような建築家は、言葉の本当の意味でのリーダーのように行動します：他の人が自発的に従う誰か。

私はそれがたくさんあったことを知っています。

参照資料

ミラー、新しい戦略的販売。この本には、特定の販売を成立できなかった理由を理解するためのモデルが含まれています。同僚が私が提案している明らかに素晴らしいことをしない理由を理解する上で、これは非常に貴重だと思います。

ワインバーグ、技術リーダーになります。この本は、私が効果的な建築家の仕事の非建築家の部分をする方法を学ぶのを助けました。

Appelo、委任委員会、および委任ポーカー。委任の難しさと、それをどれほどひどく過小評価しないでください。より効果的かつ快適にそれを行うことを学びます。

最高のアーキテクチャ、要件、および設計は、自己組織化チームから生まれます

- アジャイル宣言

そのため、チームは自己組織化して、適切と思われる方法でアーキテクチャを決定します。厳格なルールはありません。コンセンサスから最も上級のメンバーの「評議会」、特定のメンバーを建築当局として指定すること、建築家にそのような役職を持つメンバーがいるかどうかを選択させることなどがあります。 。

「高レベルのアーキテクチャと設計の決定を担当するのは誰ですか」に対する答えは、チームの規模と数に依存すると思います。

各チームに3〜7の1つまたは2つのチームの場合、自己組織化されたチームはシニアメンバーからのリードで行うことができます。

3つ以上のチームの場合、複雑さが増すため、さまざまなサブチームが他のチームと連携する作業を行っているかどうかを確認できるアーキテクチャチームが必要になります。私の経験では、約8チームまたは約50人のチームがいるときにそのポイントに達します。

サイトには、Scaled Agile Framework（SAFe）チームからの素晴らしいリソースがいくつかあります。

基本的に、組織全体でアジャイルをスケールアウトし、単一のリリースを超えてポートフォリオおよびプログラムの計画を立てるのに役立ちます。彼らのドキュメントは、リリーストレインにアーキテクチャの叙事詩を導入するプロセスにエンタープライズおよびシステムアーキテクトを関与させる方法に関する提案を示しています。

質問をより直接的に解決するために、明確にするために編集します。

スケーリングされたアジャイル環境では、アーキテクチャーに複数の所有権があります。アジャイル実装チームは、バックログの実装を継続するために必要に応じてリファクタリングすることにより、低レベルの新しいアーキテクチャを所有します。より高いレベルのアーキテクチャの決定（サポートされているオペレーティングシステム、ブラウザ、プラットフォーム、ライブラリ）は、システムおよびエンタープライズアーキテクトの責任下にあります。これらの変更が発生する必要がある場合のビジネスケースを作成し、これらのアーキテクチャの変更を実装チームのリリーストレインに追加することを推奨します。

したがって、スプリントを超えた高レベルのアーキテクチャの決定に関しては、通常、チームの上位レベルでこれらを決定します。これらの専門家は伝統的に、企業内ですでに「アーキテクト」の役割を担っています。

他の答えのほとんどは、プロジェクト内にいるという観点からこれについて考えていると思います。

それが組織内のアーキテクチャの唯一のレベルである場合、結果は率直にカオスになります。私はこのカオスを直接目撃しましたが、悲しいことにそれが起こります。

TOGAFによると、エンタープライズアーキテクチャ部門は、IT環境を作成および置換するためのビジネスの高度な計画を作成しています。エンタープライズアーキテクトは、アーキテクチャの原則を定義し、それらを組織の最高レベルで承認し、各プロジェクトの高度なアーキテクチャと要件の作成を支援します。各プロジェクトは、その高レベルアーキテクチャのアーキテクチャビルディングブロックを提供するために開始されます。

そのため、プロジェクトレベルで、ソリューションアーキテクトはプロジェクトアーキテクチャを作成し（場合によっては反復的に）、エンタープライズアーキテクトからサインオフします。

次に、アジャイルプロジェクトに焦点を当てます。アジャイルプロジェクトには要件があります。それらは大規模な「要件文書」の形ではなく、叙事詩や物語です。これらの叙事詩にはまだ計画が必要です。いくつかのスプリントで開発者チームを未知の世界に送り込むことはありません。システムが何をする必要があるのか​​、他のどのシステムとやり取りする必要があるのか​​、組織がどのハードウェア/オペレーティングシステム/言語の制約があるのか​​を高いレベルで知っています。たとえば、.NETおよびSQLサーバーにコミットしている場合、非常に2つのDB、2つの言語、2つのWebサーバーなどのサポートにかかるコストのために、PHPとMySQLを使用してMagentoに基づいたeコマースサイトを実装する説得力のあるケース。これは、他のすべての飛行中のプロジェクトに影響を与える可能性があります。この種の「建築負債」の発生を防ぐには、エンタープライズアーキテクトの監視が不可欠です。

組織の組織設計と、製品がポートフォリオ内にあるかどうかに依存します。より大きな役割志向の組織は、この種の活動をリードするシニアアーキテクトを任命する場合があります。

一般的に上級アーキテクトは、製品のバックログに影響を与えるだけでなく、製品ポートフォリオ内の複数の製品に影響を与える可能性があるため、設計の決定を促進およびガイドします。

小規模で俊敏な企業は、システム設計の専門家である開発者に頼って、開発チームをアーキテクチャ設計に合わせることができます。

最終的に、アーキテクチャの決定は、製品に携わる配信チームによって合意される必要があります。経験豊富なアーキテクトと技術リーダーは、デザインを口述するのではなく、デザインがどのように見えるかについての議論を促進することに焦点を合わせます。

ほとんどの回答はすでに、一人ではなくチームがこれらの決定を下すべきであると強調していると思います。

彼らが触れないのは、もう一つのアジャイルの原則です：

シンプルさ-完了していない作業量を最大化する技術-は不可欠です。

高レベルのアーキテクチャと設計の決定について考えることは、多くの場合、単純さを念頭に置いて行われず、おそらく多くの労力を無駄にし、拡張を困難にする不必要な複雑さを追加することになります。

「アーキテクト」よりも「ガーデニング」を考える—生きた、成長するデザインの文化を創造する

現在の反復中に、現在のニーズに合わせてアーキテクチャと設計を決定する必要があります。決してならないかもしれない未来を先見するのではなく、今必要なものだけに集中してください。おそらくYAGNIはよく考え抜かれたアーキテクチャであり、チームが少しずつそれを処理できるようにします。

その他の読み取り：

• https://less.works/less/technical-excellence/architecture-design.html