アジャイル手法を使用する際に優れたデザインを取得する方法は？
私は約3年間アジャイル手法（SCRUM）を使用しており、特に多くのレベル（実装された機能への早期アクセス権を持つ顧客から、機能をテストできるテスターからの短期フィードバックで）それらが実装されるとすぐに、レビューなどを通じて新しいコードに関する非常に早いフィードバックを提供できる他の開発者から。 一方、私は2つの未解決の問題を抱えています。最初の問題については、この質問で説明します。 問題：良いデザインを得るのが難しい コードが乱雑になり次第、リファクタリングを試みます。できる限り単体テストを作成します（これは一般的なバグ、特にリファクタリングの際に役立ちます）。一方で、毎日のコミットで少しずつ複雑な機能を開発し、構造化されていないコードを継続的に再考すると、本当に良いデザインを作成できません。 最近作成した唯一の適切に設計されたモジュールは、別のアプローチをとることで得られました：数日間問題を分析しました（実際に問題に取り掛かる前に数か月間、問題が頭に浮かびました） ）、関係するすべてのクラスとそれらの関係の詳細な設計をさらに数日間スケッチし、その後約3週間作業を中断せずにオフィスに閉じ込めてコード全体を書き留めました。結果は、私がしばらくの間作り出した最高のものであり、バグを見つけたり修正したりするのはかなり簡単で、それ以降は関連する変更を必要としない非常に明確な設計でした。 そのため、これまでは、全体像が魔法のようにプロセスに現れることを期待して、少しずつコードを書き始めるよりも、事前にやりたいことの全体像を把握する方がはるかに効果的でした。私の最善の努力により、小刻みの開発アプローチは常に私をより悪い設計へと導いてきました。 質問：同様の経験がありますか？SCRUMを間違った方法で適用しているのですか、それとも少しずつ開発しても、うまく設計されたソフトウェアを作成したい場合、何に注意する必要がありますか？または、実際のコーディングを開始する前に、デザインユーザーストーリーをスケジュールする必要がありますか？少なくとも平均よりも複雑な機能については、これは良い習慣と考えられていますか？ 編集-注 良いデザインは絶対的なものではなく、それ自体に価値はありませんが、コンテキストに依存するという事実と、手近な問題に十分なデザインを目指すべきであるという事実を知っています。 たとえば、（1）できるだけ早く準備する必要がある、（2）一度だけ使用する、（3）しないという単純なコンポーネントを実装する必要がある場合、良いデザインを（あまり）気にしませんシステムの他の部分（YAGNI）によって使用されます。 コンポーネント（1）が数回使用され、製品のいくつかの異なるリリースで使用される場合、（2）長期にわたって保守および拡張する必要がある場合、（3）それに応じて他の多くのコンポーネントを使用する場合、良いデザインが重要です。