アジャイルメソッドを使用するときに優れたデザインを取得するにはどうすればよいですか？
私は約3年間アジャイル方法論（SCRUM）を使用してきましたが、特に多くのレベルでの短期的なフィードバック（実装された機能に早期にアクセスできるお客様から、機能をテストできるテスターから）それらが実装されるとすぐに、レビューなどを通じて新しいコードに関する非常に早いフィードバックを提供できる他の開発者から。
一方、私には2つの未解決の問題があります。最初の問題は、この質問で説明しようと思います。
問題：良いデザインを得るのが難しい
コードが乱雑になったらすぐにリファクタリングを実行しようとします。できる限りユニットテストを記述します（これはヘルプを提供バグを防ぐために、特にリファクタリングの場合に）。一方、いくつかの複雑な機能を小さな増分で開発し、毎日コミットし、コードが構造化されなくなったときにコードを継続的に再考しても、本当に良いデザインを作成することはできません。
最近作成できた唯一の適切に設計されたモジュールは、別のアプローチで取得しました。問題を数日間分析しました（実際に問題を真剣に取り掛かる前に、数か月間頭を悩ませていました。 ）、関連するすべてのクラスとそれらの関係のかなり詳細なデザインをあと2日間スケッチし、オフィスに閉じ込め、約3週間中断することなく作業してコード全体を書き留めました。結果は、私がしばらくの間作り出した中で最高のものでした。特定し、修正するのがかなり簡単なバグがほとんどなく、それ以来、関連する変更を必要としない非常に明確な設計でした。
そのため、今までのところ、全体像が魔法のようにプロセスに現れることを期待してコードを少しずつ書き始めるよりも、事前にやりたいことの全体像を把握する方がはるかに効果的であることがわかりました。私の最善の努力により、小さな増分の開発アプローチは常に私をより悪い設計に導いてきました。
質問：同様の経験をした人はいますか？ SCRUMを間違った方法で適用しているのでしょうか、それとも、少しずつ開発を続けても、うまく設計されたソフトウェアで終わりたいのであれば、何に注意すべきですか？または実際のコーディングを開始する前にdesignユーザーストーリーをスケジュールする必要がありますか？これは、少なくとも平均よりも複雑な機能については、良い習慣と考えられていますか？
編集-注
良いデザインは絶対的なものではなく、それ自体には値がありませんが、コンテキストに依存するという事実を知っています目前の問題に対して十分良いであるデザインを目指す必要があります。
たとえば、（1）できるだけ早く準備する必要がある、（2）一度だけ使用する、（3）はない、という単純なコンポーネントを実装する必要がある場合、良い設計については（あまり）気にしません。システムの他の部分（YAGNI）で使用されます。
コンポーネント（1）が複数回使用され、製品の複数の異なるリリースで使用される場合、（2）時間の経過とともに維持および拡張する必要がある場合、（3）それに依存する他のコンポーネントが多数ある場合、私は良い設計を気にします。
一方、いくつかの複雑な機能を小さな増分で開発し、毎日コミットし、コードが構造化されなくなったときにコードを継続的に再考しても、本当に良いデザインを作成することはできません。
その後、それをしないでください。
すべてがニースのアジャイルボックスに収まるわけではありません。多くの場合、製品にはいくつかの複雑なものがあり、それらを個人に提供することはできず、スプリント内でまともな方法で完了することはできません。 それらをそのボックスに強制的に入れるのは問題を引き起こすだけです。しかし、これらは数が少なく、はるかに少ないはずです。コンポーネントの多くがこのようなものであることがわかった場合、製品の所有者は（チームと）状況を改善する必要があります。私はあなたがしたのと同じように元気です：話を取り、それを設計し、それが数週間かかることを期待してできるだけ早くそれを打ち出します。
より一般的なケースでは、アジャイルで優れたデザインを実現するために私が見たことが3つあります。
実際にデザインを行う-私が見た多くの場所がスプリントを開始し、コードのカウボーイを開始します。このようにすると、デザインが悪くなります。アジャイルは計画-コード-テスト-リリースの開発プロセスを変更せず、より細かい部分に短縮するだけです。スプリントの開始時に、必要に応じて座り、実際にソリューションを設計します。
アーキテクト/リーダーがいる-プロジェクトが十分に大きくなると、複数のスクラムチームがアプリケーションのさまざまな部分で作業することになります。すべてのチームが設計の観点から何をしているのかを知ることが主な仕事である誰か（またはアプリケーションのサイズによっては複数の人）がいると非常に便利です。彼らは質問に答え、より調和のとれた包括的な設計に向けてチームを導くことができます。各スクラムチームに、他のチームが行っていることのほとんどを知っているリードがいても、私は見て、非常に効果的でした。
実用主義者になる-私はこれを上記でカバーしました。アジャイルはツールであり、他のツールと同じです。すべての問題に当てはまるわけではありません。一部のコンポーネントに適用しても意味がない場合は、そのコンポーネントに適用しないでください。あなたの目標は良いソフトウェアを出荷することです。それを忘れないでください。
少しずつ実装して、適切に構造化された保守可能なコードを作成することは非常に可能です。理論的には、それは非常に単純です。変更のたびにコードが適切に構成されていることを確認すると、常に適切に構成されます。リファクタリングが必要なときにコードを追加し続けるため、コードの構造が不十分になっています。
設計にどれだけの時間を費やしても、最終的に要件は予期しない方法で変化し、元の設計に適合しないコードを記述する必要があります。次に、増分変更を行う必要があります。優れた単体テストのセットがあり、リファクタリングに熟練している場合は、新しい要件を満たすときにコードを適切に構造化しておくことができます。
「よく設計された」は主観的です
「よく設計された」はあなたにとって何を意味しますか？プロダクトオーナーへ？お客様に？
「うまく設計された」は製品所有者の目標ですか？顧客の目標は？またはあなただけですか？
あなたが「よく設計されていない」とまだ検討していることは、製品の所有者との出会いです期待と顧客を幸せにする？それはかなり「よくデザインされた」です。
十分良いとYAGNI
ほとんどのアジャイル方法論では、「適切に設計された」とは言えません。これは、製品所有者がストーリーを完全なものとして受け入れ、顧客が要件を満たしていると顧客が信じているためです「よく設計された」。
期待される開発者は専門家であり、プラグマティックベストプラクティス、適切なデザイン、イディオムを使用して機能とストーリーを実装します。
開発者の問題である、正しいことを行う時間を考慮に入れていない場合、プロダクトオーナーがこれらを実行できるより短い時間で物事を要求している場合、これを行うことは彼らの特権であり、それらについて教育する責任はあなたにあります。 技術的負債ストーリーの形での結果。
スクラム
書き留めることができるアジャイル方法論は、アジャイル方法論ではありません。」-ジャロッドロバーソン
SCRUMは、ソフトウェア製品のライフサイクル全体を管理するためのツールのフレームワークになるはずです。これは厳密なセットではなく、開始し、うまくいけば改善するのにちょうど良い場所です。
私が働いたほとんどの店には、Sprint ZEROと呼ばれるものがあり、チームの上級メンバーが製品の全体的なアーキテクチャまたはテーマをスケッチするためのSprintsがあります。
通常、20を超えるストーリーは、実際には3〜5ポイントのストーリーになるまで分解されます。これらのストーリーの1つは、「チームとしてこの機能をどのように設計するかについて話し合うために会う必要があるため、割り当てられた時間を考慮して、技術的な負債をできるだけ少なくします。 「
一般的に
一般に、「うまく設計された」システムは、十分十分であり、YAGNIに従います。
アジャイル、特にアジャイルの実装としてのSCRUMは、製品所有者/スポンサーに対して可能な限り透過的に製品を生成する方法の詳細です。
テクニカルデザイン/アーキテクチャーに関しては何でもありません。それは、顧客のニーズと期待に応えるソフトウェアを提供するアプローチの方法に関するより多くの哲学です。 「よく設計された」パーツと呼ばれていない場合、それは哲学の基本的な部分ではないため、それ自体は失敗ではありません。 。
私たちはスクラムで数ヶ月働いており、あなたの問題に関する私の経験を共有したいと思います。
数か月前、私は実装する大きな部分を与えられました。すべての仕様を準備していたので、それに応じて新しい機能を実装する必要がありました。タスクは約5〜6週間かかることでした（私が見積もったとおり）。最初の1週間は、デザインのみに取り組みました。タスクは少し複雑でした。仕様から結論付けたように、15の異なる状態を持つメインオブジェクトがあり、UIは状態ごとに異なる動作をすることでした。
ワークフロー全体を設計し、その後DBの構造とクラスを設計しました。
私の場合、他のアプローチは見ていません。私がすぐにコーディングに飛び込んだ場合、最後に大きな厄介な混乱が発生し、メンテナンスがほとんど不可能になり、さらに変更を加えることが非常に困難になります。しかし、変更は次の2週間で行われたため、コードを作り直す必要がありました。これは、最初は考え抜かれた設計で、今は簡単でした。これにより、時間、お金、神経を節約できました。
この経験の後で、私は最初に許容できるデザインを作成する価値があると確信しています。奇跡があれば最後にそれが得られることを願っています。
後視は20-20です。プロジェクトの開始時にすべてを把握し、数週間でコードを作成するための情報を自由に使える場合は、それを行うことをお勧めします。
あなたは、得たすべての洞察、試みられた、失敗した/変更されなければならなかったアプローチ、および要件に十分なクレジットを提供するクライアント/ユーザーの能力の向上に十分なクレジットを与えていません。
ウォーターフォールプロジェクトの成功の歴史を持つ人が、なぜアジャイルな方法論に切り替えるのでしょうか？
プロジェクトを開始する前に、最終的な目標、実装する予定の機能、いつ実装するかについての全体像を常に把握しておく必要があります。ストーリーをアトミックタスクとして処理することは問題を引き起こしています。将来の要件をできる限り念頭に置く必要があります。