アジャイルな見積りと計画づくり

ソフトウェア開発の難題である見積りと計画づくりを「アジャイル」にすることで、開発の現実に即した、誤差の少ない計画づくりができるようになる。

その技法を、分かりやすく説いた1冊です。

「イントロダクション」より

本書のタイトルを「アジャイルプロジェクトの見積りと計画づくり」とすることもできた。だが実際には「アジャイルな見積りと計画づくり」というタイトルになっている。2つの違いは些細に見えるかもしれないが、そうではない。採用した現在のタイトルは、見積りや計画づくりといったプロセスを、アジャイルに進めなければならないと謳っているのだ。見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。

本書は主に計画づくりを扱っている。計画づくりとは「なにをいつまでに作ればいいのか?」という質問に答える作業だと私は考えている。しかし、この質問に答えるためには、まず見積りに関する質問(これの大きさは?)と、スケジュールに関する質問(「いつできるのか?」「このときまでになにができるのか?」)に答えねばならない。

メモ

計画づくりとは「なにをいつまでに作ればいいのか？」という質問に答える作業

計画づくりとは「価値の探求」

ソフトウェア開発の全体にわたる問に対する適切な答えを探る試み

「なにをつくるべきか？」

よい計画づくりとは、以下のような特徴を持ったプロセス

リスクを軽減する

不確実性を減らす

多くのプロジェクトが直面する最大のリスクは、間違ったプロダクトを開発してしまうこと

意思決定を支援する

開発期間とコストのトレードオフを判断

信頼を確立する

情報を伝達する

よい計画とは

プロダクトとプロジェクトについての意思決定をおこなう根拠として信頼できるもの

プロジェクトの初期段階で全体の計画を詳細にわたって定義するのは不可能

アジャイルな計画づくりとは、プロジェクトの全期間に均等に分散させておこなうもの

プロジェクトが進むにつれてより正確に見積もれるようになる

リリースプランニングが計画の土台となり、これに基づいて複数のイテレーションプランニングがおこなわれる　　

アジャイルな計画づくりの定義

計画よりも計画づくりを重視する

変化を促進する

計画そのものは容易に変更できる

プロジェクトの全体にわたって繰り返される

アジャイルな計画づくりで大事なのはでき上がった計画よりも、計画を立てるという活動そのもの

変化を促進する

計画を容易に変更できる

アジャイルな計画づくりはプロジェクトのはじめから終わりまで何度も繰り返される

なぜ計画づくりに失敗するのか

何をつくるべきか？

どのくらいの期間で、どれだけのリソースを使って、どのようなフィーチャを備えたプロダクトを作るべきか？

フィーチャではなく作業を計画している

作業は早く終わらない

仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する

スケジュールの遅れは先へと伝わる

作業は独立していない

ある作業が予定よりも長くかかったら、類似の作業も同様に予定より長くかかるということ

2回目以降効率化できるというのは思い込み

マルチタスク化

3つ以上の作業を並行して進めると効率が下がる

1つより2つの方が効率はよい

フィーチャの優先順位が無視されることがある

見積りとコミットメントを混同

見積りはコミットメントではない

アジャイル手法

プロセスやツールよりも、人と人との交流を

アジャイルプロセスは人間一人一人の持つ強み（と弱み）を認め、それを活用する

誰でも同じ仕事ができるようにしようとするプロセスとは対照的である

包括的なドキュメントよりも、動作するソフトウェアを

契約上の交渉よりも、顧客との協調を

計画に従うことよりも、変化に適応することを

アジャイルチームは、あらかじめ決められた計画に従うことよりも、起きた変化に適応することに価値を置く

プロジェクトへのアジャイルチームのアプローチ

1つのチームとして働く

全員が一丸となって取り組む

プロダクトオーナー

顧客 ≒ ユーザー

開発者

プロジェクトマネージャ

短いイテレーションで作業する

2週間〜4週間であることが多い

イテレーションごとに成果をあげる

少なくとも1つのフィーチャをリリース可能な状態にしなければいけない

リリース間隔は一定でなくてよい

ビジネス上の優先度を重視する

検査と適応

計画はその時点での推測に過ぎない

新しい知識を得たら計画を調整する

最終成果がどのようなものになるか事前に知ることができない

計画づくりは、長期的な目標に到達するための適切なゴール設定とその見直しのプロセス