実装フェーズではどのくらいの設計が行われますか？
期日前大規模設計/ウォーターフォールグループで作業している人のために：設計段階でどれだけ批判的思考と設計がスキップされ、実装段階に残されますか？設計段階の最後に、機能仕様と技術仕様がどの程度完全かつ詳細に提供されていますか？
設計フェーズの最後に提供する必要のある詳細レベルでの解釈の余地がたくさんあるように思えます。設計フェーズが急いでいると、マネージャーはビルドフェーズがそうではないことに腹を立てます。組立ラインでウィジェットを作成しているように進行することはありません。一方、ビルドフェーズを組立ラインのように動作させるのに十分な完成度のある設計フェーズには、実際には実装フェーズが含まれます。「ビルド」に残るのは、エディターに入力することだけです。もちろん、それはあなたの設計段階が巨大であることも意味します。
これはウォーターフォールモデルの欠点だと思いますしかし、建設的なアドバイスを提供できる人がそこにいる場合：どこに線を引くのですか？設計段階と構築段階への期待はどのようなものであり、どのような種類の設計上の欠点や間違いが構築段階で許容されるべきか、許容されるべきではありませんか？
私はラピッドプロトタイピング、ラピッドインクリメント、ラピッドイテレーションの大ファンです。 「インテリジェントデザイン」ではなく進化。あなたは人々の問題を解決するためのソフトウェアを書いています、そして人々は彼らの心とニーズを時間とともに、たとえ短期間でさえも変える傾向があります。
コーディングの前に、要件、鳥瞰図、および「サインオフ」を可能な限り二乗して取得するのは良いことですが、独断的であるという意味はほとんどなく、すべてが流動的です。コードを編集、修正、破棄する準備をしてください。面白いことに、とにかく完了ポイントに到達することはありません...ほとんどのコードは、人々が気にかけている間に変更されるようです。そして、誰も気にしないと、コードは削除されます。
確かに、これは航空機制御システム、原子炉制御などのソフトウェアの初めての作業には当てはまりませんが、私の推測ではそうではありません。
設計段階では常に何かが見落とされています。人々は不完全であり、実装に移るというプレッシャーなしに多くの設計フェーズ時間を許可する完璧な管理があっても、見逃したことがあります。
同様に、設計では、収穫逓減のポイントに入ります。たとえば、ユーザーインターフェイスを設計し、それを仕様に書き込むと、仕様にレイアウト、フォーマット、およびフォームのすべてのロジックが含まれるようになります。その場合、それは実装とほとんど同じですが、おそらくコードの接着剤の厄介な部分だけが異なります。
デザインをプッシュしすぎることの価値を問う必要があります。デザインがコードの記述に変わったとき、それが意図を伝える最も明確な方法であるため、十分かどうかを尋ねるときです。
すると、実装は、忘れられたものや見逃されたもの、および簡単に見えたかもしれないがそうではないことが判明した他の実装の詳細を明らかにし始めます。 （おそらく、ライブラリやOSから得られると思っていたサービスは、期待どおりではないことが判明しました...回避策として、掘り下げたり、新しいコードをたくさん書いたりする必要があります。またはパッチ。）
ウォーターフォールは素敵なシンプルなモデルで、経営陣に説明するのに最適です。それはまた、現実に起こる反復的で混合された高レベル/低レベルの思考からかなり遠く離れています。
これについてもう少し興味深い解説は、エド・ヨードンによる古い本「アメリカのプログラマーの衰退と衰退」にあります。
これが完璧な答えではないことは知っていますが、プログラミングと設計の方法論も完璧ではありません。それらへの最善のアプローチは、物事を成し遂げるための有用なシステムとしてそれらを扱うことです。ルールはあなたを助け、邪魔になったときに破られるためにあります。ルールの違反は、誰かが1日目からコードを切り取りたいと思ったという理由だけでなく、インテリジェントに行う必要があります。