この質問は、アジャイルとウォーターフォールのライフサイクルの問題の核心だと思います。
アジャイルを行う場合、基本的な前提は、詳細な仕様よりも、開発者との密接な相互作用を組み合わせたコードの方が優れており、高速であることです。チームは、詳細な設計仕様などの正式なコミュニケーションメカニズムなど、他のものよりも新機能と高品質のリリースを優先します。ただし、ここには取引があります。チームメンバー間には、ニュアンスや詳細な設計意図について必要なときに質問できるコミュニケーションチャネルが必要です。
ウォーターフォールを行う場合は、詳細設計の下でコードを入力してからテストする作業が重要であるという想定の下で作業しています。そして、この作業がどのように進行するか、そして作業がどのように行われるかについて関係者に早期の洞察を与える必要があります。それは、顧客に設計を精査して、意味のある機能の範囲を確認している可能性があります。また、安全レビュー、セキュリティレビュー、コードと統合する必要があるチームメンバーによるレビューなど、他の分野の専門家と精査することもあります。これらのレビューは、間違ったものを開発する際に大量の時間を調査する手間を省くため、長期的にはこれらのレビューによって時間を節約できると想定されています。
最近、詳細な設計とコードコメントツール(JavaDocなど)の間に本当に素晴らしい融合が見られました。ほとんどの詳細な設計はコードのフットプリントとそれが何をするかについての短い説明なので、これは多かれ少なかれ、コードのコメントとして期待するものと同じです。したがって、コードのコメントを詳細な設計仕様に変換するツールを用意することは素晴らしいことです。手動で行うよりも、最新の状態に保つためのはるかに優れた方法です。
プロジェクトの詳細設計の不正確な評価は、コスト増加の主な要因であると思います。最悪の部分は、あなたがそうするならあなたはのろわれ、そうでなければあなたはのろわれます:
- チームのサイズ、作業の複雑さ、および通過する必要があるゲートの要件(セキュリティレビュー、安全レビューなど)に対して設計が詳細すぎる場合、貴重な時間とお金を無駄に費やしています。決して使用しないアーティファクト。
- 設計の詳細が不十分な場合、チームメンバーが統合の問題につながる誤った仮定を行うため、費用が無駄になり、最終的なセキュリティまたは安全性の監査により、早期に安価に修正された可能性のある問題が発見された場合、多大なやり直しのリスクがあります。実装前の設計の明確な側面。
私はそれが白黒のケースだとは思わない-他の人が厳密な詳細な作業を必要とする一方で、いくつかのコンポーネントは高いレベルで設計された場合「十分」である場合がしばしばあります。また、チームやプロジェクトの環境が変化すると、プロジェクトの進展に伴って新しい設計のニーズが決まる場合があります。