トレーサー弾丸を使用するためのいくつかの良い基準は何ですか？

最近、Pragmatic Programmerを初めて読んでいて、Tracer Bulletsの概念に出くわしました。私は過去にこのモデルに従ってコーディングしたことがあり、脳内で作業していた方法を「アジャイル」として提出しただけだと気付きました。

彼らは過去にそれを使用した場所の1つの例のみを示します。状況がトレーサー弾丸の良い候補であると特定された方法は、

多くの不明な点があり、多くの異なる環境があり、GUIがどのように動作するかを確信している人はいませんでした。

この種のプロジェクトは、膨大な数のプロジェクトの開始方法のように見えます。特に、例として、ヘッジファンドの一般的な基幹業務アプリケーションで技術者以外の人々と作業している場合はそうです。

私はそれが何と呼ばれているのか、私にそれを説明することを本当に知らずに、それが単に正しいと感じたのでそれを使用しました。全員を部屋に入れようとして、すべて（または少なくともいくつか）を前もって仕様化してもらうと、それは完全な惨事になることはわかっていましたが、これも一種の感じです...

このモデルが最適な方法となる時期について、より具体的な基準を誰かが思い付くことができますか？

機能のごく一部のみを使用して正しい方向に進んでいるかどうかを把握できるプロジェクトが必要です。通常、これは基本的なGUI設計などの場合に可能ですが、結果が不明な場合は困難です。たとえば、データマイニングアプリを設計していて、ツールの形状がデータで発生するパターンの種類に依存する場合などです。

また、何度も繰り返す余裕のある状況である必要があります。これは時間と開発にコストがかかります（もちろん、アジャイル開発プロセスにサブスクライブしている場合は有益かもしれません）が、ユーザーへの露出という点でコストはさらに難しくなります。あまりにも多くのデザインを表示すると、ユーザーはすぐに疲れ果ててしまい、フィードバックの質がかなり低下します。そのため、大きなユーザープールが必要か、（マイクロ）リリースを慎重に選択する必要があります。

トレーサーブレットアプローチの有用性を決定する基本的な要因は、アプリケーションのアーキテクチャと設計における不確実性の数と範囲だけだと私は思います。

このテクニックの主な（唯一ではないにしても）目標はそのような不確実性を取り除くことであるため、アーキテクチャがない場合やアーキテクチャやデザインに関係がない場合、そのメリットはあまり得られません。アーキテクチャ上の制約のないグリーンフィールドプロジェクトは、トレーサーブレットから始めるのがほとんど唯一の賢明な方法である場合の典型的な例ですが、それを実装するいくつかの新しい機能を備えた成熟したプロジェクトでは、おそらく時間の無駄になります（要件に関して不確実性がある可能性があります。それらをクリアすることは、より一般的なアジャイルまたは反復開発の領域です）。

「Ship It！」という本でトレーサー弾の開発の概念に出くわしました。、実用的なプログラマーによって編集されました。

あなたの質問では、本「The Pragmatic Programmer：From Journeyman to Master」を参照していると思います。私はそれをまだ読んでおらず、TBDがどのように提示されているのかわかりません。で船これ！、TBD専用の1つの章（20ページ）があります。特に、彼らは具体的な例を挙げて彼らの経験について話します：バイオテクノロジー企業のためのデータマイニングアプリケーション。基本的には、（TBDを使用して設計された）優れた抽象化レイヤーを使用することで、各レイヤーを並列化することで、パフォーマンスのボトルネックを1つずつ取り除くことができると説明しています。

私の見解では、未定は2つのことです。

• システムオブジェクトを分離してソフトウェアアーキテクチャを作成し、開発者が共同でこれらのシステムオブジェクト間のインターフェイスを定義できるようにします。
• 使用モックオブジェクトをアーキテクチャは、持続可能であることを確認してください（初期のアーキテクチャをテスト）します

最初のポイントは、ソフトウェアを設計するための非常に良い方法だと思います。2つめのポイントは、重要な点です。実際には機能しない初期アーキテクチャが原因で、プロジェクトの完全な書き直しが妨げられる可能性があります。