ウォーターフォールとアジャイルのフェアな比較

ウォーターフォールとアジャイルの
フェアな比較
kawasima

アジャイルマニフェスト
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
http://www.agilemanifesto.org/iso/ja/

分かりやすい喩え
ウォーターフォールアジャイル
ホールケーキとして作る必要に応じてカットケーキを作る

アジャイル開発の
実際の進め方
(rascal-scheme)
https://github.com/kawasima/rascal-scheme

体制
プロダクトマネージャ
●
要求を実装可能なストーリーに変換する。
●
チームがスムーズに実装できるレベルまで、ストーリーを理解させる。
チーム
●
スプリント(2〜4週間)で実装するストーリーをコミットし完遂する。
●
スプリント期間は、外部からの開発進捗の妨げを排除する。
(スクラムマスターの仕事)
●
タスクの見積りはチームで行い、各タスクの完了責任はチームで持つ。
(クライアント)
●
要求をとりまとめ、開発サイドに伝達する。
※ストーリーとは、実装可能な仕様の塊。通常、機能一覧の1行に該当する。

権限の７つのレベル
マネージャとして意思決定するTell
意思決定について説得するSell
意思決定する前にチームに相談するConsult
チームと一緒に意思決定するAgree
チームが意思決定する前にアドバイスするAdvice
チームが意思決定した後にフィードバックを求めるInquire
チームの意思決定に何も影響を与えないDelegate

権限レベルを決める
ストーリーの内容
Tell Sell Consult Agree Advice Inquire Delegate
ストーリーの中の
内部仕様 PM Team
Client PM
スプリントに含める
ストーリー
PM Team PM Client
…
ストーリー全体計画 Client PM

全体スプリント計画
Sprint1(8/16〜8/29)
Sprint2(8/30〜9/12)
Sprint N(mm/dd〜mm/dd)
●
顧客の検索ができるようにする
●
顧客のデータを登録できるようにする
●
…
プロダクトバックログ
スプリントバックログ
システムに要求される機能を分解し、ストーリーとしてプロダクトバックログに積む。
ストーリーの優先順位をつけ、だいたいの見積りをし、スプリントバックログに割り振る。

スプリント計画MTG
プロダクトマネージャチーム
Sprint N(mm/dd〜mm/dd)
●
スプリントでの総開発量の決定
●
ストーリーの見積り
●
ストーリーのタスク分解
●
ストーリーの内容説明
●
ストーリーの詳細なスコープ決定

スプリントレビュー
チーム
●
スプリントの成果をデモ
プロダクトマネージャ
(クライアント)
●
指摘をバックログに反映する

QCDに沿ってアジャイル開発の
メリデメを考える

コスト
●
結果として無駄なものを作らなくて済む可能性があ
り、当初の概算よりコストを抑えることができるかも
しれない
Pros
Cons
●
タイムボックス分割の分のオーバーヘッドがかかる。
●
大量生産可能なものに適用してもオーバーヘッドが上
乗せされるだけである。

品質
●
タイムボックスごとにテストがされるので、必然的に
品質は高くなる傾向にある。
Pros
Cons
●
デグレを防ぐために、回帰テストが必要になる。
(コストへのインパクト)

納期
●
フィジビリティを確認しながら、開発を進められるの
で、実現が難しい機能がクリティカルパスになって、
設計・プログラミング工程で遅延が発生するという
事態を防ぐことができる。
Pros
Cons
●
基本的にはコスト・品質を固定して、納期とスコープト
レードオフをコントロールしていくプロセスなので、ス
コープの調整が前提になっていないと、納期は守れな
い。

マネジメントの違い
ウォーターフォールアジャイ
ル
Quality
Cost
Delivery
Scope
固定
コントローラブル
固定コントローラブル
固定コントローラブル
(大量に積んだバッファでやりくり)
(納期とスコープのトレードオフを
やりくりする)
固定
固定

体制
ウォーターフォールアジャイル
時間
人数
時間
人数

体制
●
最初から同じメンバーなので、立ち上げのコストが
少ない。
●
同じプロジェクトに継続してたずさわるので、学習
効果が期待できる
Pros
Cons
●
特になし

Q. スキルの高い人でチーム組まないとできないの?
A. そういうことはない。
しかし、タイムボックス分割のオーバーヘッドを最小化する
ためにはプロダクトマネージャには高いスキルが要求される。

Q. ドキュメント書かないので、保守フェーズで苦労するって聞いた。
A. ドキュメント書く、書かないの話はアジャイルとは関係ない。
設計書などは、コードを書いた後で作ることができるので、
手戻りがなくドキュメンテーションの効率がよくなる効果はある。

Q. ミッションクリティカルなシステムなので品質が心配だが…
A. スタートアップ起業文化で成長してきたのメソッドなので、
品質に対する意識が低そうな印象があるのは事実だが、
品質保証プロセスに何の違いもない。
デグレのリスク増など、留意
すべき点を間違えなければ、
ミッションクリティカルで使え
ないということはない。

●
同じものを同じメンバーで作るのであれば、ウォー
ターフォール、アジャイルに大きな違いはない。
最終的に出来上がるものが違うから、プロセスを選び分ける
●
プロジェクトの特性による向き不向きがある。
– 向いているものは…
●
ビジネスの成功に必要な機能を誰も明言できないもの
●
技術的に実現可能性が見えていないもの
●
納期の制約がないもの

ウォーターフォールとアジャイルのフェアな比較

More Related Content

What's hot (20)

Similar to ウォーターフォールとアジャイルのフェアな比較 (20)

More from Yoshitaka Kawashima (20)

ウォーターフォールとアジャイルのフェアな比較