プロトタイプ型開発、スパイラル型開発、アジャイル型開発などの主要な非ウォーターフォール型開発の概要についてざっくりまとめてみました。
プロトタイプ型開発
「プロトタイプ型開発」は簡単な試作品（プロトタイプ）を開発し、ユーザーによるプロトタイプの評価が行われてから本格的な設計を開始する開発モデルです。「プロトタイプの開発」と「ユーザーによるプロトタイプの評価」は、ウォーターフォールモデルにおける 「要件定義」工程と「基本設計」工程の間に組み込まれます 。
プロトタイプ型開発はユーザーの要件と開発者側の認識のずれや技術的な課題を早期に解決できるため、 開発工程終盤での大きな手戻りを防ぐ ことができます。
プロトタイプ型開発はその特徴によって以下の二つに大別することができます。
| 種類 | 特徴 | 目的 |
|---|---|---|
| ラピッド・プロトタイピング | 開発したプロトタイプを 破棄 する | 時間と費用を最小に抑えること |
| 進化的プロトタイピング | 開発したプロトタイプを 流用 する | 継続的に改良していくこと |
ラピッド・プロトタイピング（使い捨て型プロトタイピング）
「ラピッドプロトタイピング」は「 時間と費用を最小に抑えること 」を最大の目標とし、要求仕様が確定した段階で 開発したプロトタイプは破棄する プロトタイプ型開発の一種です。開発したプロトタイプはシステム開発には流用しません。最近注目されているUIプロトタイピング・ツールとして、「Adobe XD」や「Prott」などがあります。
Adobe XD
- Adobe XD Preview 3 リリース！アートボードのスクロールやテキストの部分スタイリングなど | Adobe Creative Station
- 2017年最新！おすすめのプロトタイピングツール5選 | web design trends
進化的プロトタイピング（ブレッドボード・プロトタイピング）
進化的プロトタイピングは 開発したプロトタイプを流用 し、改良を重ねながらシステムを完成させるプロトタイプ型開発です。要求仕様を完全に把握する必要はなく、仕様が明確となっている部分から開発に着手します。
スパイラル型開発
スパイラル型開発は、ウォーターフォール型開発における要求定義、設計、コーディング、テストの各工程を繰り返す開発モデルです。
インクリメンタル・モデル（漸進型）
インクリメンタル・モデルは システムを独立性の高いモジュール（機能）に分割 し、モジュール毎に設計、コーディング、テストを行い、追加していきながらシステムを完成させる開発モデルです。
イテレーティブ・モデル（反復型）
システムを機能の優先度や重要度によって分割し、システム全体の開発を繰り返して徐々に完成度を上げていく開発モデルです。
インクリメンタル・モデルとイテレーティブ・モデルの違いは「Incremental is not iterative」に掲載されている以下の図がとても分かりやすいです。
- 非ウォーターフォール・モデル | Think IT（シンクイット）
- いまなぜ開発プロセスを注目するのか：前編 従来の開発プロセスと現場が抱える課題 - ITmedia エンタープライズ
- ソフトウェア開発の匠（4）：アジャイル開発と反復開発の落とし穴 (1/3) - ＠IT
- 開発プロセスについて - Qiita
- 開発モデルの話 - tasuwo blog
- CSAJ/コラム「ITリフレッシュメント」反復型開発プロセス
- イテレーティヴとインクリメンタルの違い | Ryuzee.com
- モナリザを使った インクリメンタル(漸進的) と イテレーティブ(反復的) の説明 - kawaguti's diary
- The waterfall trap for "agile" projects
- アジャイル時代のプロジェクトマネジメント入門（2）：現代のプロマネが知っておきたいアジャイル開発の基礎知識まとめ (1/2) - ＠IT
アジャイル型開発
「アジャイル」と一言で言ってもその種類は多種多様です。本稿では主要なアジャイル型開発である、「スクラム」、「XP」、「リーン」、「Kanban」について簡単に説明します。
スクラム
スクラムはアジャイル開発における プロジェクトマネジメントのフレームワーク です。スクラムでは「プロダクトバックログ」、「スプリントバックログ」と呼ばれる一覧表によってユーザーの要件をタスクに分解し、一週間から四週間に渡る「スプリント」と呼ばれる期間で開発を進めていきます。
エクストリーム・プログラミング（XP）
XPは テスト駆動型開発、YAGNI（"You ain't gonna need it."）、リファクタリング、ペアプログラミングなどのプラクティスが定義されている プログラマ中心 の開発モデルです。ドキュメントの整備よりもソースコードを重んじると共に、個々の開発者の責任を重視しています。
リーンソフトウェア開発
リーンソフトウェア開発はプロジェクトマネジメント面に焦点を当て、プロセスから 無駄を取り除く ことを目的とした開発モデルです。リーンソフトウェア開発の重要な考え方の一つに「 MVP（Minimum Viable Product） 」があります。MVPとは「仮説を検証するための最低限の機能を持った製品」を意味し、まずは機能を限りなく絞り込んで開発にかかる時間や費用を最小化し、真にニーズがあるかどうかを検証しよう、という考え方です。リーンソフトウェア開発ではMVPの考え方を含めた 7つの原則 とそれを実現するための 22のツール が定義されています。
- トヨタに学ぶ！リーンソフトウェア開発の7つの原則 | tracpath:Works
- 情報マネジメント用語辞典：リーンソフトウェア開発（りーんそふとうぇあかいはつ） - ＠IT 情報マネジメント
- リーン開発をはじめよう - Qiita
- 「リーン」と「アジャイル」の関係とは？：書籍でたどる「リーン」の本質 (1/4) - ＠IT
- プログラマのためのリーン・スタートアップ入門（2）：リーン・スタートアップが示す「5つの原則」 - ＠IT
Kanban
「Kanban」は、各ステージにおけるタスクの量を制限し、必要なタスクだけ前ステージから取ってくる、 トヨタの「かんばん」方式を適用した開発モデル です。開発モデルとしてのかんばんを「 Kanban 」、 各ステージにおけるタスクの状態を付箋紙などのカードで可視化したツールを「 kanban 」と表します。
Crisp's Blog » One day in Kanban land
Kanbanでは「 WIP制限 」と「 プル 」という二つの重要な概念があります。
| 項目 | 説明 |
|---|---|
| WIP（Work in Progress、仕掛り作業）制限 | 「TODO」、「開発」、「デプロイ」などの各ステージに対するタスクの限界量を設定し、 各ステージにはWIPの数以上のカードを貼ることができない というルール |
| プル | 各ステージの担当者がWIP制限に収まる範囲内で前ステージからタスクを取ってくること |
これらの概念がどのように開発プロセスとして組み込まれているかを理解するには、上記画像の引用元である「Crisp's Blog » One day in Kanban land」、またはその日本語訳である「5分で理解するリーンな「かんばん」 | 『リーン開発の現場』越境せよ！」が大変役立ちますので是非参照してみてください。
Kanbanでは後工程にタスクが滞留すると、WIP制限によって前工程では 例えメンバーが全てのタスクを完了していても新たなタスクを開始することはできません 。手が空いているメンバーは自分の作業を進める代わりに、滞留しているタスクを支援します。このようにして各ステージの ボトルネックが「見える化」 されることで、メンバー個人の過負荷を防ぎ、お互いに協力し合うチームを形成することができます。
- かんばん (ソフトウェア開発) - Wikipedia
- 5分で理解するリーンな「かんばん」 | 『リーン開発の現場』越境せよ！
- Crisp's Blog » One day in Kanban land
- トヨタのかんばんとソフトウェア開発のかんばんの違い | 『リーン開発の現場』越境せよ！
この 作品 は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。