『なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い』ノート

2012/09/25に開催された『なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い』のノートです。
もっといい話をたくさん聞いていたような気がするのですが、あまり残っていないような　…メモ力をもっと高めていきたいです。


◆ウォーターフォールのコンセンサスを作りましょう

◇歴史的背景と現状
起源は1970年代に発表されたWinston Royceの論文。
ただ、これはバッチ生産のためのパラダイムのものであり、所謂ウォーターフォールではない。

Winston Royce - Managing the Development of Large Software Systems
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

◇ウォーターフォール開発プロセスの歴史
1. Winston Royce 「Managing the Development of Large Software Systems」
　→大規模ソフトウェア開発に関する論文。ウォーターフォールという言葉は使っていない。概念もだいぶ違う。ただ、ウォーターフォールはこの論文を元に開発されている。
2. 米国防総省「DOD-STD2167」
　→手戻りなしの規格がこれ。それまでは標準になるような開発プロセスがなかったので、流行った。
3. 米国防総省「MIL-STD-498」
 →ウォーターフォールがうまくいかなかったので、改めて繰り返し開発の良さを認めた。
4. CMU/SEI「Considerations for Using Agile in DoD Acquisition」
　→アジャイルを使うときの手引き

◇ロイスの論文について
・ウォーターフォールは小規模で自らが使うソフトなら充分かつ合理的
・ウォーターフォールは大規模だとうまくいかない
　→直接的には最終成果物に関わらない追加的工程が必要。
　→なければ失敗する。
　→→オーバーヘッドがあれば妥当に失敗する
　→→なければ失敗が発散する。
・壮大なプロセスを踏まないと発散する
・1回きりではうまくいかない
・反復する
・一つ前の工程に戻ることは想定内
　→それは設計が洗練される行為なので望ましい。
　→反復が局所化されない場合（2つ以上手戻りする場合）はリスクになる
　→→最後のテスト工程で出てくるのは一番まずい。
・テスト工程で明らかになると、手戻りが大きいのでなんとかしないといけない

◇リスクを限定するための5個のステップ
1. Preliminary
　→プログラムデザイン（アーキテクチャ設計）をする
2. 仕様の見える化
　→コミュニケーションの媒体（各種引継ぎのため）。品質の見える化
　→あと、結構な量のドキュメント
　→要求定義書。構想定義書。インタフェース設計書。決定仕様。テスト計画、実施結果、使い方。
3, Do It Twice
　→開発工程を2度
　→プロトタイピング
4. plan, control and monitor testing
　→工数を使うしリリース直前なので、非常にリスクがあり、注力しないといけない
　→テスト計画。進捗把握、品質コントロール
5. 顧客を巻き込む
　→アーキテクチャ設計レビュー
　→実装の設計レビュー
　→受け取り検査

◇ロイスがいいたかったこと
・大規模ソフトウェア開発には特有の課題がある
　→小さいソフトウェアの大きい版ではない
・管理強化・工程の細分化が必要
・管理のためのオーバーヘッドを認識しないといけない
・過小評価するととんでもない失敗をする

◇誤解と偏見
・手戻りあり
・失敗のリスクを限定するためのもの
・リスクに対するコストや時間の追加の必要性
・官僚的なプロセスではない

◇ウォーターフォールはなぜ支持が根強いか
・建設・インフラ開発のアナロジー
・生産工程のアナロジー
・当時は開発プロセスがなかったのでウォーターフォールでもうまくいき、成功体験になった
・水の流れはどこかに落ち着く言うメタファがあり、これが意外と強力


◆ウォーターフォールとアジャイル

◇ウォーターフォールとアジャイルの対比1
・ウォーターフォール
　→作業の分割統治（タスクを積み重ねる）
　→工程表
・アジャイル
　→成果の分割統治
　→達成すること(done)を積み重ねる
　→バックログ

◇ウォーターフォールとアジャイルの対比2
・ウォーターフォール
　→マイルストーン
　→プロジェクトコントロール
　→事前に要求の範囲とレベルを明確にし、成果物を確認
・アジャイル
　→タイムボックス
　→環境・条件の調整
　→つど状況に応じて要求の優先順位を明確にして達成を確認

◇ウォーターフォールの難点
・初期の要求がなかなか確定しない場合
・後の工程になって要求が変更になる場合
・事前よ予見しきれない技術課題
・リスク管理とその運用の難しさ
・コミュニケーションの質の悪化
・官僚的な追加作業

◇アジャイルの難点
・品質保証基準の確立
　→ウォーターフォールは履歴情報を使うことで統計的手法を利用できる
　→→工程と品質基準を結びつけることができる（結びついている）ということ
　→アジャイルはそれができない

◇ウォーターフォール開発を適用する場合
・経験豊富で予見性が高い
・再現性の高い作業の集約になっていて計画できる
・大量の単純作業で労働集約的

◇アジャイル開発を適用する場合
・小規模、少人数
・不確定要素が多く予見性が低い
・リスクが高い
・継続的に保守・拡張する場合
・探索的な試行錯誤が必要な場合


◆まとめ
・「よくわからないけど、とにかくうまくいけばいい」というのは当てものでしかないので学習効果が期待できない
・自分にとっての解決するべき問題やその前提条件を具体的に認知できれば対策は見えてくるはず


◆質疑応答
Q.
「wfのメリットが使える現場ってもうないのでは？」

A.
「あるのは事実。だけど、目指すべきではない。」


◆参加者の意見
・ゲーム業界の場合は、コンカレント型かもしれない
　→コードはアジャイルだけど
　→デザインは違う
　→→いったん決まると、大量のアーティストがキャラクタを作ったりする
・デザイナは音楽聴きながら作業したりする
・プログラム側はほとんどそういうことをしていない
　→それはプログラミングにはコミュニケーションが必要だから


◆補足

・告知・募集ページ
当日のプレゼンテーションのスライド、講演動画のURLが公開されております。
→http://agileucdja.doorkeeper.jp/events/1736

・当日のプレゼンテーションスライド

なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い from Yoichi Tamamaki

玉牧 陽一様, アジャイルUCD研究会様、ありがとうございました。