反復型開発とアジャイルは違う
反復型開発 イコール アジャイル開発ではないよね、という話
顧客価値の最大化を狙うとすると、思い込みで開発するよりも、より顧客について学習した状態で何を作るかを判断した方がいい。
そうなると、「何を作ればいいか」を継続的に探す必要が出てくる。
とはいえ仕様書で何を作ればいいかがわかるかというと、それも無理ゲーな話（できると思っているアタマユルイ人はいる）
となると、動くソフトウェアで触って確かめないといけない。
となると、動くソフトウェアを継続的に作る必要がある。継続的にドメインを学習するために。
＃継続的にソフトウェアを作る上で、小さいタイムボックス＆バッチで作るか、フローで作るかは選択の余地があり
そのため、アジャイル開発ではあるが、反復型開発ではない、というパターンは上記が実現できないので、おそらくない。
結果として、アジャイル開発であるなら、反復的に開発することが必要になる。
一方で、反復的に開発するというのは、コストがかかる。
ビルドの手間、リグレッションテスト、デプロイの手間、手戻りの際の管理の煩雑さ、漸進的な設計、、、
これらのものが意外とコンピュータリソースやクラウドやツールで何とかなってきたので、反復型開発が「ペイしやすく」なってきたので、反復型開発がしやすくなって気はする。
反復型開発のメリットは、アジャイル開発が実現できるだけではない。
スコープでコントロールするスタイルでトカゲの尻尾切りでプロジェクトをローンチできる。
いらない機能を作り込む代わりにコストと納期が伸びるのと、いらない機能を作らない代わりにコストと納期を約束できます、というのでは後者が望まれる場面も多い。
この場合は「要件定義」とかいうフェーズを済ませてしまう人も多い。
ヒアリングした結果のうち、優先度が高いものから反復的に作っていきましょう。
最悪の場合、作った結果を見てもらうこともない。
見てもらわないとなると、何のために反復型開発をしているのか、となるが、PJ をコントロールしやすくするため、となる。
金と納期は決まったから、最初に聞いた内容からできることだけ作ろうぜ。と。
それのどこが顧客の方を向いているのか、全く理解できない。ただのコントロール力不足じゃないですかね。
で、どうなるかというと、３割くらいは、検収・ユーザーテストで要件不足に気がつき炎上する。
こういうケースをアジャイル開発と呼んでいるケースが多く、「やっぱりアジャイルってさ〜」っていう人が割といる。いいかげんアジャイルアジャイル言われて久しいし。
いやアジャイルじゃなくてただの劣化スパイラルじゃないのそれ、と。RUP ですらないだろと。
反復型開発がアジャイル開発だ、と思っている人には、アジャイル開発がダメに見える。
アジャイル開発をしている人には、それってアジャイル開発じゃないよね、と見える。
側から見ると、アジャイルをやっている人は成功している物だけをアジャイル開発と呼んでいる、ように見えてしまう。
反復型開発はアジャイル開発の一側面であって全てではない、というのを理解していない人が多いので、名前も悪いよな、とか思いながらコーヒー飲んでいます。
漸進的探索とか目的に近い名前をつけておいた方が良いんだろうな、という気持ち。
