Martin Fowler による技術的負債、Steve McConnellによる
YAGNI (You Ain't Gonna Need It)ウィキペディアより
ウィキペディアによるBDUF (Big Design Up Front)
更新：質問を明確にするために、このように述べて、私の意味を維持することもできると思います：
「あなたは、アジャイルの実践者として、各イテレーション内で、「クイック アンド ダーティ」(YAGNI に準拠しようとして意図せずに技術的負債を負う危険を冒すこと) とオーバーエンジニアリング (BDUF) の間の適切なバランスをどのように見つけますか?
アジャイル（反復、反復レビュー）の「計画、実行、適応、計画、実行、適応」の考え方に固執する場合、デフォルトではそれらのことを回避するようです。BDUFは、アジャイルの見積もりと計画の考え方に正反対であるため、本当にアジャイルである場合、自動的にBDUFになることはありません。
リリースとイテレーションの計画会議の目的は、そのイテレーションのプロジェクトに最も価値のある機能を追加していることを確認することです。それを心に留めておけば、YAGNIを無料で避けることができます。
アジャイル計画に関するMikeCohnの本を強くお勧めします。
更新： 反復内でYAGNIとBDUFを回避することについて明確にした後...
BDUF ...作業を開始する前に機能が明確に定義されていないと感じた場合は、必要な作業のデザインタイプの部分を説明するために、小さな「機能」またはストーリーを作成します。そのため、小さなストーリーのストーリーポイントの見積もりは実際の機能の5ではなく1になります。こうすると、デザインは小さなストーリーにタイムボックス化され、機能自体に進むようになります。
YAGNIに違反しないようにするために、イテレーション内の機能に顧客が何を期待しているかを明確にするように努めます。顧客が期待するものに対応する作業のみを行ってください。追加する必要があると思われる場合は、その機能の新しい機能を作成し、実行する作業のバックログに追加します。次に、そのメリットを確認するように顧客を説得します。顧客が特定の時点で実行されている機能を要求するのと同じように。
数週間前の HanselMinutes での完了の定義に基づいて、技術的負債に関する興味深い議論がありました - What is Done。ショーの基本は、知覚速度を上げるために「完了」を再定義すると、技術的負債が蓄積されるというものでした。この当然の結果として、「完了」の適切な定義がない場合、設計方法論に関係なく、リリース前に完了する必要があるアイテムのリストを取得する可能性が高くなります。
「YAGNI」は「速くて汚い」という意味だとおっしゃっているようですね。わかりません。
アジャイル プログラマーとして、テスト駆動型開発、コード レビュー、継続的インテグレーションを実践しています。
私の経験では、技術的負債の主な形態は次のとおりです。
それがあなたの質問に答えたかどうかはわかりませんが、書くのは楽しかったです。
Troy DeMonbreun は次のようにコメントしています。
いいえ、それは私の言いたいことではありませんでした... 「クイック アンド ダーティー」 = (YAGNI に固執しようとして、意図せずに技術的負債の危険を冒す"). これは、YAGNI がクイック アンド ダーティであるという意味ではありません. 「クイック アンド ダーティ」という言葉は、私が Martin Fowler の技術的負債の説明で引用したもの
YAGNIを回避することは、 KISSの別の言い方です。YAGNI は技術的負債を増やします。YAGNI を回避することと、技術的負債を低く抑えることの間には、緊張関係はありません。
あなたの質問の要点をまだ見逃している可能性があると思います。
「伝統的な」XP の答えは、自動化された単体テストと組み合わせたリファクタリングです。
しかし、これは哲学的に非常に興味深い問題です。技術的負債を回避する必要はないと思いますが、管理可能なレベルに維持してください。Steve McConnell の記事は、このバランスについては適切です。例えが機能する理由は、コストとリスクを受け入れる限り、会社に金銭的負債を積み上げることは正常であり、容認できるからです。また、技術的負債も問題ありません。
その答え自体もYAGNIの原理にあるのかもしれません。技術的負債を完済する必要はありません。そうするまでは、それがリファクタリングを行うときです。技術的負債のあるシステムの領域でかなりの作業を行っている場合は、再設計を行うことで短期的にどれだけの違いが生じるかを検討してください。それが価値あるものにするのに十分な場合は、それを完済してください。債務リストを維持するという McConnell の提案は、いつこれを検討すべきかを知るのに役立ちます。
これに対する絶対的な答えがあるとは思いません。多くの場合と同様に、それはあなたの経験、直感、およびそれぞれの特定の状況での分析に基づく判断です。
Robert Martin のTest Driven Development (TDD) アプローチは、これらの懸念事項の解決に役立ちます。
なんで？
テストが書かれる時期 (前後) に関係なく、テストを書くことは実用的な決定を下すのに役立ちます。たとえば、A の方がテストしやすいため、設計 A または B を選択しました。
動作する最も単純なことを実行するだけです。Ayendeがアジャイルであるための鍵は「頻繁に出荷すること」であると言ったとき、私は同意します。このような定期的なリリース サイクルは、BDUF の時間がないことを意味し、開発者が YAGNI に違反することを思いとどまらせることにもなります。
私が働いている場所では、負債を回避する方法は、サイクルをすばやく回すことだと思います。つまり、エンドユーザーに機能を示して、テストにプッシュする必要があるという承認を得るか、何が間違っていたかを拒否するかのいずれかを取得します。更新された要件を提供します。これをイテレーション内で繰り返し行うことで、ユーザーが何を求めているかについて、あれこれ試すことで多くの変化を見つけることができます。
重要な点は、ユーザーが望んでいることを正確に実行しようとすることです。より多くのことを行うと、YAGNI に違反し、BDUF がもたらされますが、要件を何度も改良するという考えは、私の考えではアジャイルの中心にあります。
アジャイルであることで、特定のプロジェクトの TD を抑えることができるでしょうか?
顧客が望むもの、つまり顧客のフィードバックを実装しているという事実は、TD を最小限に抑えています。
そのため、アジャイル開発がいかに優れているか、「ベスト プラクティス」とは何かなどについて述べた優れた「学術論文」を書く方が常に簡単です。
そのため、新しいソフトウェア エンジニアリング手法を作り上げる「適任のエンジニア」がたくさんいます。
プロセスは重要です。ベスト プラクティスを維持することはクールですが、何よりも常識が設計プロセスを推進します。ソフトウェアは人によって開発されるため、YAGNI は次のようにすべきです。
私は必要ないかもしれませんが、私の具体的なビジネス/会社/部門でこれが起こるか、必要になるので、必要になるかもしれませんが、現金を稼ぎ、仕事を維持するための迅速で汚いハックがありません。 、または私はそれを必要とするかもしれませんし、後でリファクタリングすることは、最初から今それを行うよりも10倍以上の費用がかかるお尻の痛みになります.今は時間があります.
したがって、あなたの常識を使用するか、それを信頼するか、あなたのために働いている人々の常識を信頼してください. すべての学術論文を証明された事実として受け止めないでください。経験は最高の教師であり、あなたの会社は時間と独自の経験でやり方や物事を改善する必要があります。
編集:ちなみに、TDD は YAGNI の反対であり、テストが必要かどうかを知る前にテストを作成します。まじで学者の言うことを聞くのをやめろ!! ソフトウェアを作成する魔法のような方法はありません。