わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その2）

ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが本質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。 プロジェクトの構造化はこうやる ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。 「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが本当。 「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程（＝フェーズ）ごとにチームを割り、それぞ

[masakiplus]

開発の手順

[send]

うーん…？これってPMBOKとかCMMI寄りな話なじゃないかな。古典的WFと違うような？

[sourcek]

続き読みたい

[ablabo]

プロジェクトは構造化して「見える化」する

[kennak]

未確定事項もリストアップしておく

[kawajun]

あとでしっかり読む。

[yorihito_tanaka]

どのように分けて順序を立てるか

[SiteA]

仕様のあいまい性の排除については次回か