Rintaさんの質問に答える

http://d.hatena.ne.jp/Rinta/20070814#p1
長いので引用はしないよ。質問は4点あるようで

次の質問への答が参考になるはず。失敗とはなにか？も参照のこと。

ウォーターフォールと同じものをAgile開発に期待するのなら、その通り。少人数でまわせば時間がかかるようになるだけ。

ここでいう「同じもの」というのは

などなど。こうしてできる一式と同じものを少人数で作れといわれたら、そりゃ時間がかかるのは当たり前。

Agileは要件をフィーチャで記述し、そこに優先度をつける。真っ先に必要なのはどれか？　次はどれか？　という具合。そして、「納期とされる日までに必要なのはどこまでか」「どこまでできれば納品可能か」を見積もる。その上で、フィーチャごとに開発していく。

これがウォーターフォールだと、要件を分析した後に設計で機能（ファンクション）に落とすよね。フィーチャとファンクションは直交した概念だ。ファンクションの組み合わせでフィーチャが動く。絵にするとこんな感じ。

当然だけど、機能のどれかが未完成か不具合だらけだと、関連するフィーチャ全部が動かなくなる。下図の場合だと、Function BができてないおかげでFeature W, X, Y, Z全部が動かないことになる。

Agileはフィーチャを優先度順に開発していく。各フィーチャごとに確実に動くコードが成果としてあがってきて、その時点で受入テストが可能になる。また、優先度の低いフィーチャは未完成でも本番稼動に望めるかもしれない。

ということで、Agileは「不要なものは開発しない」ことで、生産物を減らす。だから少人数でも回せるようになる。[*1]

質問１への回答もこれに関連する。ファンクションごとに作っていくウォーターフォールでは、完成度がプロジェクト後半に急激に立ち上がる。（下図の上）　これに対してAgileはほぼ線形に完成に近づいていく。（下図の下）　ウォーターフォールのほうがプロジェクトリスク管理は難しく見えるんだけど...　

おまけ：　http://www.agilejournal.com/articles/case-study/case-study%3a-war-stories-%11-fighter-jets-and-agile-development-at-lockheed-martin.html
ロッキード社がF35戦闘機開発にAgileを採用した、というお話。200人が関わっているということなので、大型プロジェクトでもAgileは使えるようだ。

もちろん、ウォーターフォールでもテストベンチは使える。ただし、上にも書いたけど使いもしない機能や冗長重複だらけのコードにテストベンチをあてがうのは苦痛以外のなにものでもないはずだ。それを苦痛を思わないのならテスト漏れがあると思ってよい。[*2]

自分の所ではテストベンチ整備がしんどくなったら、数歩引いてリファクタリングをかけるようにしている。設計と実装の見直しで、重複冗長の解消や、テストしやすい実装への変更を行う。これでテスト漏れの可能性はかなり小さくなる。

苦労は感じてない。特にRails使うようになってからはドキュメントの必要性を本当に感じなくなった。

フレームワークが強力なので、保守要件を聞けばどこをいじればよいのか直ちに見当がつく。これは後からプロジェクトに参加した人がいても同じ。もちろん、Railsに詳しい必要はあるけど...
とりあえずいじくってテストをかければ、影響が波及する部分を特定できる

むしろ、コード＋テストベンチ＋設計書の３つの同期をとって保守するほうが大変だと思うんだけど？　

アジャイルの得意なところ・不得意なところ、ウォーターフォールの得意なところ・不得意なところがそれぞれあって、相補的な関係にあるってのが、現実なんじゃないかな。

自分も何年か前はそう思ってハイブリッドなものを目指したけど、諦めた。[*3] Agileの本質は

であって、これらはいずれもウォーターフォールとは相容れない。

*1:実際にでかいのは、プロジェクト初期の顧客との交渉。ウォーターフォールだと予算と開発対象の妥当性で貴重な時間を数ヶ月単位で失うが、Agileはその間にコアなフィーチャを開発できちゃうこともある。

*2:テスト漏れがあるからこそバグ収束曲線を使うわけだけど

*3:ウォーターフォール開発に、「毎朝の立席ミーティング」を採用したら生産性があがりました！　みたいな話を聞いたことがあるけれど、それは立席ミーティングがすごいんじゃなくって、今までのやり方が腐りきっていただけだろうね。