現在の開発の流れ

ざくっとですが

• 要件定義＝何を作るのか
• 設計＝どうつくるのか
• テストを書く＝何が正しいのか
• 実際の開発＝ものづくり
• テスト＝正しくつくられているか

を回していく形ですね
もちろん粒度を小さくしてこれらのループを再帰的に回していくのは言うまでもありません

いろんな見解があると思いますが、それを

• 大きいスパンで回す(ウォーターフォール型)
• 小さいスパンで回す(アジャイル型)
  みたいに考えれば、どっちが正しいとかはないと思います

大きな予算を取ってってなるとウォーターフォール型開発でないと依頼主が納得しないでしょうし、継続的に予算を確保できるならアジャイル型開発で小さく産んで大きく育てるなんてことも可能でしょう

ただ何でもかんでもアジャイル型でってすると、依頼主の上層部から「で、システムはいつ完成するんだ」的な収束しない事態に陥る可能性もあるでしょう

開発が「完成する」という発想で、何をしたらいいか順番に・・と考えると、単純にウォーターフォールの開発になります。

dojikkoさんのステップを2年で1回まわせばウォーターフォールで、2週間で50回まわせばアジャイルでそれは間違いないですけど、2年と2週間では実際の作業は全然違います。

2週間で1回がまわるようにするには、UMLは・・なんて呑気なこと言ってないで、1日目のヒアリングである程度動くぐらいでないと、たぶん14日後=10営業日で本番にのせるのは無理です。プログラマーはその場にいて最初からコードがわかる必要があります。各種の場合分けに対応し、例外を織り込んで、テストして確認をとってリリースしたら10日はすぐ終わります。
「手順？いいからコードを書け！」みたいな感覚が伝わるかと思います。

UMLが不要とは言いませんが顧客が必要としたら「後で」作るものとなります。作業報告だったり、スケジュールのガントチャートだったり開発に必要なくても、作らなくてはいけないものは出てきます。

50回の20回目を想像していただきたいのですが、だいたい40回あたりで何が起こるかはわかるようになるのです。
顧客側もリズムをつかむので、要求の大きさと予測される開発速度がわかるようになります。無理をいってもできないというのが理解されます。プログラマーができないとその場で言えば、できないものはできないので、やり方を考えようという話になります。また予算が一定になるので、長く続けるなら契約は同じ内容同じ金額で更新するだけなので、大規模な開発でも安心して続けられる状態になります。