アジャイル（agile）とは「素早い」「機敏な」という意味です。
アジャイル開発とは、 「計画 ⇒ 設計 ⇒ 実現 ⇒ テスト」の小さなプロセスを繰り返す開発のしかたです。 この 1 回の繰り返しをイテレーション（反復）と呼びます。
ねらいは、仕様変更に強くすること、 そして製品の価値を最大限にすることです。
以前の開発手法に比べると、アジャイルはまだ発展途上の考え方です。 万能薬ではありませんが、変化が前提の領域では有効です。
| ウォーターフォール | アジャイル | |
|---|---|---|
| 前提 | 要求は先に決められる | 要求はやってみないと分からない・変わる |
| 進め方 | 全工程を 1 回通す | 小さな一周を何度も回す |
| 成果の出方 | 最後にまとめて出る | 毎回、動くものが出る |
| 変更への態度 | 変更はコスト。凍結して守る | 変更は歓迎。価値を上げる機会 |
| 向く場面 | 要求が固まっている。前例がある。大人数 | 要求が動く。新しい領域。小さめのチーム |
優劣ではなく、前提の違いです。 要求が本当に固まっているなら、ウォーターフォールのほうが管理しやすい。 要求が動くのに凍結しようとすると破綻します。 どちらを選ぶかは、その案件で要求がどれだけ安定しているかで決まります。 第3回のスパイラルモデルは、両者の中間にあたる考え方でした。
アジャイルは、次の 3 つを認めるところから始まります。
この 3 つを認めないまま計画を立てると、 計画は「守れない約束」になります。認めたうえで、 優先順位をつけて、価値の高いものから作るのがアジャイルの構えです。
| 特徴 | 中身 |
|---|---|
| 自己組織的 | 誰が何をやるかを、チーム自身が決める |
| 職能横断 | 設計・実装・テストを分断せず、チームで完結させる |
| 顧客が近い | 要求を出す人が、いつでも聞ける場所にいる |
| 小さい | 意思疎通の経路が増えすぎない大きさに保つ |
プロジェクトを始めるときに、チーム全員で答えを出しておく問いの一式です。 「何を作るか」だけでなく、「何を作らないか」「なぜやるのか」「何を諦めるか」を先に言葉にします。
代表的な問い：
最後の問いが重要です。 第6回で見たとおり、設計とはトレードオフを決める仕事でした。 プロジェクト全体についても同じことが言えます。 全部は手に入りません。何を諦めるかを先に決めておくと、 後で慌てて決めなくて済みます。
残っている作業量を縦軸、時間を横軸にとったグラフです。 線が右下がりに 0 へ向かっていれば順調、寝ていれば遅れています。
バーンダウンチャートの値打ち。 第2回で「ソフトウェアは目に見えないので進捗が測れない」と述べました。 このグラフは、残作業という 1 本の線で進捗を見えるようにする道具です。 実績の傾きからいつ終わるかが読めるので、 「間に合いません」と言うのが遅れにくくなります。
12 回を通して、システム開発の全工程を見てきました。 共通していたのは次の 3 点です。