断片化されたデザインを引き起こすアジャイル方法論

Question

断片化されたデザインを引き起こす毎月のスプリント/反復によるアジャイル方法論をどうやって防ぐのですか？例えば、マンハッタン・ストリートとボストン・ストリートのデザインのデザインの事例を取る。 Manhattan Streetsの青写真は全体として設計されているため、操作が簡単で運転も簡単です。ボストンの通りは一品食のアプローチとその悪夢の中を歩いて設計されました。

Answer 1

アジャイル開発は、オーバーアーチ型設計を捨てる命令ではありません。主要な構成要素の責任とはどのようなものなのか、どのように相互作用するのかなど、「大きな図」を計画することは非常に意味があります。自分のチームでは、広範な公開APIに前向きに合意することが合理的な妥協策であると考えていますが、できるだけ詳細な実装の決定を延期しています。これにより、個々の開発者は、実装が進化するにつれてデザインを自由に変更できると同時に、変更がはるかに安い設計レベルで異なるアプローチをハッシュする利点を得ることができます。モジュール性も重要です - コンポーネントを機能的に特定し、可能な限り互いに分離してください。これにより、実装の変更が必要になった場合のオーバーヘッドが最小限に抑えられ、作成する個々のコンポーネントが有用なままになる可能性が高くなります。

Answer 2

ストリートは、ソフトウェアに使用すると似ています。道路は、の重要度であるの手間をかけずに簡単に移動、経路変更、または変更することはできません。よく書かれたソフトウェアは、必要に応じて簡単に再編成して変更できる直交コンポーネントの構成です。

アジャイル開発が機能するのは、開発者とソフトウェア自体の両方が機敏であるからです。開発者は変更に迅速に対応し、ソフトウェアの書き方は変更にも反応するように書かれています。

Answer 3

リファクタリング、リファクタリング、リファクタリング。

Answer 4

ストリートを決定する設計フェーズを持つことができます。どの建物が建設されるかは、各段階で決定されます。

私は、スクラムプロジェクトでデザイン/アーキテクチャがあまりにも少ない傾向があると思います。一定のリファクタリングを行うことはできますが、何かが設計されていない場合、それは多くの仕事になります。デザインにエラーがある場合は、同じ問題に陥る可能性があります。

Answer 5

SOLID principlesを使用すると、コードが疎結合されており、疎結合性が高くなります（&）。

デザインは覚えています。

IMHOの建物とのソフトウェアコンポーネントの類似性、通りは単に非論理的です。これは、ソフトウェア開発やソフトウェア設計とは遠隔的に類似していません。

Answer 6

アジャイルユーザーは、アジャイルの原則を当面の状況に合わせて調整することを提案するリスクは常にありますが、これが引き続き失敗するとアジャイルを完全に採用していないため、

断片化されたデザインは、アーキテクチャー上の価値がないため、アジャイルの継続的なリスクです。必要なのは、Continuous DeliveryなどのAgileの有利な側面を使用するが、Agileのスケーラビリティのような問題を解決する方法論です。可能なアプローチはこれだけですThe Game of Thrones Methodologyです。

Answer 7

「アジャイル方法論」（ここではSCRUMを意味すると仮定します）は、設計のアーキテクチャーとはほとんど関係がありません。アーキテクチャーはあなたが作成したソフトウェアまたはシステムのプロパティです（UMLの世界では、おそらくそれを「人工物」と呼ぶでしょう）。

「アジャイル」は、どのような種類のソフトウェアを書くかについては何も教えてくれません。あらゆる種類のソフトウェアや、ソフトウェアとはまったく関係のないプロジェクトでも使用できます。

あなたのアジャイルプロジェクトに悪いソフトウェアアーキテクチャがあると感じたら、実際の原因が何であるかを調べる必要があります。あなたがアジャイルであるという理由だけで、誰もが計画なしで自分が望むことをやっているわけではなく、まったくドキュメンテーションが必要ないということを意味しません。作業を開始する前に、すべてのクラスをビットレベルまで指定することはありませんが、最初のスプリントの前であっても、高度なアーキテクチャを書き留めたいと思っています。あなたのチームの規模と選挙区に応じて、最初のスプリントを使用してを作成してあなたのアーキテクチャを作成すると想像することができます。