アジャイル環境での建築設計はどのように行われますか？
私は アジャイルアーキテクトの原則 を読みました。そこで、彼らは次の原則を定義しました：
原則＃1システムをコーディングするチームがシステムを設計します。
原則＃2機能する可能性のある最も単純なアーキテクチャを構築します。
原則＃3疑わしい場合は、コーディングしてください。
原則＃4彼らはそれを構築し、テストします。
原則＃5システムが大きいほど、滑走路は長くなります。
原則＃6システムアーキテクチャは役割のコラボレーションです。
原則＃7イノベーションを独占することはできません。
この論文によると、ほとんどのアーキテクチャ設計はコーディング段階で行われ、それ以前のシステム設計のみが行われます。それは結構です。
では、システム設計はどのように行われるのでしょうか？ UMLを使用していますか？または、インターフェイスと主要なブロックを定義するドキュメントですか？多分何か？
免責事項：私はamアジャイル環境の建築家ですが、Helmuth von Moltke the Elderは、 「敵との接触を生き延びた戦闘計画はない」。言い換えれば、実用性とは、ガイドラインの正確な書簡が常に守られるとは限らないことを意味します。
上記で挙げたポイントのほとんどは、チームができる限りフォローします。ただし、原則1（システムをコード化するチームがシステムを設計する）は、チームが異なる大陸およびタイムゾーンに分割された数十人（または数百人）の開発者で構成されている場合、実際に従うことは困難です。これは、開発者のスキルや態度とは何の関係もありません。顧客からの要件を収集し、既存の複雑なシステムを理解するために存在するすべての開発者のロジスティックな問題です。
では、システム設計はどのように行われるのでしょうか？ UMLを使用していますか？または、インターフェイスと主要なブロックを定義するドキュメントですか？多分何か？
多くの場合、アーキテクトは主要コンポーネントを特定し、それらの間のインターフェース（セキュリティ、速度、信頼性などの非機能要件を含む）を定義し、コンポーネントの内部設計を個々のチームに委任します。これは、システムに関するすべてのことを誰もが知っている必要なく、チームに独自のコンポーネントを設計させることの良い妥協点です。
すべての組織には、建築設計に関する独自の一連の標準があり、これは組織内のプロジェクトごとに異なる場合があります。この設計は、チームがコーディングを開始する前、またはできるだけ早く行われ、通常は次の内容が含まれます（完全なリストではありません）。
- 拡張された要件とスコープ定義。これには、より高いレベルのビジネス要件を具体化するユースケースまたはユーザーストーリーが含まれます。個人的には、非機能要件に RFC 2119 を使用するのが好きです。設計はこれらに基づいており、これらにさかのぼります。設計の一般的な定義には適合しないかもしれませんが、これらはしばしば同じくらい重要です。
- 高レベルのネットワークまたはコンポーネントの図とテキストのページで構成される概要。これは、上級管理職から開発者やQAまで、非常に幅広い読者を対象としています。対象読者が幅広いため、UMLや定義された表記法を使用することはめったにありません。
- 個々のコンポーネントの詳細。多くの場合、上記のようにそれらの間のインターフェースまたはAPIに焦点を当てています。インターフェイスは、前提条件と事後条件の詳細を含むターゲット言語のメソッドシグネチャとして指定できます。コンポーネントには、クラウドまたはデータセンター内のVMのレイアウトとそれらのネットワーク配置を示すなどのネットワーク図がある場合があります。リレーショナルデータベースには通常、エンティティ関係図があります。
- 既知の場合、アーキテクチャ上のリスクとその軽減策のリスト。要件と同様に、これらは設計の決定とトレードオフを示しています。
つまり、アジャイルプロセスのシステムの設計は、従来のウォーターフォールプロセスのシステムの設計とまったく同じです。ただし、アジャイル環境では、事前に行われる設計は少なく、コンポーネントチームに多く委任されます。重要なのは、最初にどの程度の深さになるかを決定することです。どの決定を延期し、決定を行う必要があるかを特定します。複数の開発チームに影響を与える決定、特にスケーラビリティとセキュリティを早期に行う必要があります。すでに国際化されている製品に言語を追加するような決定は、非常に遅くまで延期することができます。
最初のデザインが作成された後、アーキテクトは各チームと協力して彼らのデザインをレビューします。作業単位（スクラムスプリントなど）に追加の設計または設計変更が必要な場合、アーキテクトは、作業単位の開始時にそれを使用できるようにすることを目指しています。アーキテクトはまた、影響を受けるチームまたは関係者に変更を通知する責任があります。
免責事項：私はアジャイルコーチ/アーキテクトではありません。これは、私が取り組んできたアジャイルプロジェクトで見たものであり、うまく機能していると思います。
アジャイルがアーキテクチャの方法を明確に定義しているとは思いません。アジャイルは開発の方法論と実践に重点を置いています。一方、UMLは、アジャイルを超えるアーキテクチャを伝達するための言語にすぎません（プロジェクトやチームに適している場合に使用します）。
実際に適用されるアーキテクチャの原則の1つは、可能な限り最後の責任ある瞬間に決定を下すことです。つまり、特にこの段階で情報が最も少ないため、プロジェクトの最初にすべての決定を下していない場合は問題ありません。時間が経つにつれ、アーキテクチャを「進化」させる決定を下す可能性があります。はい、これは一部の手直しのように見えるかもしれませんが、これはまた、環境、要件、不可能ではないことなどについて新しいことを学んだという事実によるものです。
あなたが避けたい主なことは、アーキテクチャの腐敗です-コードは実際にはany特定のアーキテクチャに準拠しておらず、混乱したものです。アーキテクチャーの進化と比較した主な違いは、後者の場合、定期的に慎重な決定を行い、明確な理由でそれらを文書化してから、コードがそれに従っていることを確認することです。
テスト駆動開発を行う場合、モジュールを分離してテストするテストコードを作成します（=他のモジュールから可能な限り独立します）
テストコードの作成を容易にするために、簡単に模倣できる他のモジュールへのインターフェースを導入します。
この方法は、副作用として、モジュール間の結合が可能な限り小さいアーキテクチャを自動的に取得します。
私の意見では、tddは建築作業でもあります。