architecture - アジャイルプロジェクトでアーキテクチャをどのように制御しますか？

Question

柔軟なソフトウェアアーキテクチャを可能にする「適切な」設計上の決定を使用してプロジェクトが構築されることをどのように保証しますか？

アーキテクチャを一方のチームに完全に任せることと、すべてのアーキテクチャをもう一方の少数の個人に制御させることのバランスをどのように取っていますか？

「建築グループ」や「建築レーベル」などはありますか？

Answer 1

アジャイル アプローチの前提条件は、使用方法を既に知っているアーキテクチャです。

アーキテクチャが明確に定義されていて、完全に理解されていなければ、実際にアジャイル アプローチを採用することはできません。

アーキテクチャがどのように機能するか、およびさまざまな部分がどのように組み合わされるかを示すいくつかの技術的なスパイクが必要です。これらは予備スプリントとして実行できますが、ユーザーへのリリースに直接つながるわけではありません。それらは特殊なケースであり、使用できるアーキテクチャに到達するために必要です。

この「アーキテクチャを理解する」作業が終わったら、ユーザー向けのリリースに直接つながるスプリントの実行を開始できます。

Answer 2

私はそれをどのように行うかを説明することができましたが、これは私ができるよりも良いことを言っています。

Answer 3

また、ファウラーのドキュメントIs Design Deadを読むことをお勧めします。彼の議論を理解している限り、すべてのアジャイル プラクティスを全体として考えると、大きな変更を加える自由が得られ、アーキテクチャを進化させることができます。

リファクタリングは継続的な対話で最も効果的に機能し、テストは TDD と継続的な統合で強化されます。進化する「アーキテクチャ」は、「間違い」を修正するために必要な大きな変更を加えることができない場合にのみ制限されます。

さらに、プロジェクトの利害関係者としてアーキテクトがいると思います。彼らはユーザー ストーリーに貢献し、それがアーキテクトに返されます。

これは、アーキテクトがペアの一部として作業するペア プログラミングを利用する良い方法でもあります。この文脈では、アーキテクトは献身的な人ではなく、開発チームのメンバーがペアプログラミング中にかぶる帽子です。

XP はアーキテクト (およびアーキテクチャ) の役割を縮小するものではなく、すべてのチーム メンバーに責任を負わせ、プロジェクトの存続期間にわたってコストを分散させるだけだと思います。

[編集]

他のコメントによると、事前の計画を恐れないでください。イテレーション ゼロは、計画の一部を試してグラフ化するのに適した時期です。特定のタイム スケールでの配信について厳密になる必要はありません。

Answer 4

私の経験では、これを行う最良の方法は、経験豊富な開発者/アーキテクトが、アーキテクチャのビジョンを日々推進するプロジェクトに取り組んでいることです。

アーキテクチャを制御し、すべての新しい作業がそれに適合するようにするために、プロジェクトの開発リーダーに任せることをお勧めします。

Answer 5

私は事前に計画を立てることでこれを処理します。一般的に、これを支援するために同様のアプリケーションを使用した経験があります。そうでない場合は、アイデアを得るために宇宙を探索します。基本的なアーキテクチャがレイアウトされたら、優先順位の高いストーリーに基づいて、それを念頭に置いて開発を開始します。次に、アーキテクチャの欠点やエラーに対処するために、リファクタリングを行います。

Answer 6

事前に大きな設計を行わなくても、通常、各プロジェクトに適用される基本的な設計があります。通常、これはアプリケーションの設計で考慮すべき基本的なレイヤーを定義します。その他のほとんどの設計上の決定は、各開発者によって行われます。

私たちの開発プロセスは、頻繁なピアレビューを伴う短期間の開発バーストに基づいています。各開発者のアーキテクチャ決定の品質は、ピア レビュー時に検証されます。これには、コードが製品アーキテクチャに従っていることの検証も含まれます。

プロジェクトの種類と利用可能なツールに応じて、レイヤーケーキの整合性を自動的に検証するためにmackerなどのツールも使用します。