開発手法よりも計画そのものを考える上で参考になる情報が欲しかったのと、社内で読書会を行っていたので、そのキャッチアップも兼ねて購入した。
目論見通り、アジャイル開発における見積もり・計画段階のTipsやマインドセットについて深堀りされていた。アジャイルサムライとページ数は同じくらいで、全体で占める見積もりの割合が圧倒的に多い。たとえや筆者の事例などが比較的多く、細かいステップを踏んで理解を進めていける。
一方で既に知っている知識も多いためか新鮮味が薄れていたのも事実で、後半は若干集中力を切らしてしまった。また、各セクションのタイトルと内容の関連が分かりづらいことが多く、読んでいて混乱するところもあった(これは自分の読解力の問題かもしれない)。Kindleでハイライトをつけられなかったのも残念。
プログラミングに関するセクションが無いため、実装工程から離れているPMみたいな人は手に取りやすいかもしれない。
第1部 問題とゴール
1章 計画の目的
- 見積もりと計画づくりの正確さは、不確実性コーンのような傾向で収束する。プロダクト定義初期の段階では60~160%の誤差を生じる可能性があり、要求仕様が定まった段階でも15%ほどの誤差が生じるとされている。
- 計画づくりはスケジュール決めではなく、何を作るか?を決める場
- プロジェクトをすすめると新しい知識が手に入る。その知識を計画に反映させるべき。また、それを反映させやすくする計画づくりが重要
- 計画が、期待と可能性を伝えるコミュニケーションの助けになる
- 良い計画とは、ステークホルダーが意思決定するための参考になるもの
2章 なぜ計画づくりに失敗するのか
- 顧客に価値があるのはフィーチャの完了であり、作業の完了ではない
- 作業感の連携が必要なので、作業見積もりの合計=フィーチャの見積もりにはならない
- マルチタスク化の悪い点はスイッチングコストだけでなく、一つが遅れ始めると複数のタスクの進捗に影響を与えること
- 優先順位を意識しないで開発すると、プロジェクト終了間近になってスコープ減らす必要が出たときに重要機能が残っている可能性を残してしまう。
- 見積もりはコミットメントではない
3章 アジャイル手法
- イテレーションごとにリリース可能な状態の成果をあげること
- イテレーション=リリースではない。複数のイテレーションをまとめてリリースすることもある
- イテレーション開始時に、前のイテレーションで得た知識を計画に反映する
- ユーザストーリーは要求を先にすべて書き出す必要はない。必要な情報を必要なときに会話して決めれば問題ない
- プロダクトナレッジとプロジェクトナレッジを得ることで計画が正確になっていく。最初の計画時にすべての知識があるわけはない。
- 知識を獲得するための時間も、計画に組み入れておくこと
- 計画する対象は、
リリースイテレーション今日。あまりに先の計画は正確性にかける。 - 計画の見直しの時間も計画に組み込むこと
- リリースプランニングは、プロダクトオーナーと開発チームが満足条件を探っていくことから始める。満足条件は、フィーチャーとテスト内容で表現すること
- 開発したフィーチャに対するフィードバックを踏まえ、満足条件を更新していく
第2部 規模を見積もる
4章 ストーリーポイントによる規模の見積り
- ストーリーポイントの見積もり技法は、最小のストーリーを1として基準にする方法と、中央値を決めてそれを基準にしていく方法の2種類がある。
- 1イテレーション内で完了したストーリーポイントの総量がベロシティ
- 見積もりは規模と期間で分けて考える
5章 理想日による見積り
- 理想日で見積もる場合の前提
- ストーリー実現に必要な作業のみ見積もる
- 必要なものはすべて作業開始前に用意されている
- 割り込みは発生しない
- 理想日であってもベロシティを導出できるので、その点はストーリーポイントと変わらない
- ストーリーに対して見積もりは1つにするべき
- 担当者ごとに見積もると、チーム一丸となって動くアジャイルチームの性質が失われてしまう。
- 同じ機能を別プラットフォームでリリースする場合などはOK
6章 見積りの技法
- 見積もりに費やした労力と見積もりの正確性は比例しない
- チームで見積もるメリット
- 見積もった人が作業できるとは限らない
- 詳しくない人が意見を持っていないとは限らない
- 相対見積もりがうまくいく規模は10倍までが目安
- 専門家の意見で見積もりを決めようとしてもうまく行かないことが多い
- アジャイル開発では作業ではなくストーリーに対して見積もりを行うが、そのストーリー実現のために必要なスキルは多岐にわたる。そのスキルすべてを持ち合わせている専門家は少ない
- プランニングポーカーは、専門家の意見、対比、分割を組み合わせて行える
7章 再見積り
- 結果的に予測したベロシティからずれたとしても、それだけであれば見積もりの値の変更は行わない。ベロシティが補正されていくため問題ない
- 新しい知識を獲得した結果、規模が変わったと判断できたら再見積もりが必要
- 完了とはストーリーの完了であり、作業の完了では無い
8章 ストーリーポイントと理想日
- 見積もりはなるべく職能横断で行う
- 理想日だと担当者のスキルが反映されやすいが、ストーリーポイントだと作業スピードを反映するイメージは湧きづらくなるため、結果的に相対見積もりがうまくいきやすい
- 理想日と現実の経過日を関連されて考えがち
第3部 価値のための計画づくり
9章 テーマの優先順位づけ
- ビジネス価値を図る上で見るポイント
- フィーチャの金銭価値
- フィーチャの開発コスト
- フィーチャから学べる知識とその意義
- 知識の獲得=不確実性の低下 であるので、計画の正確性向上につながる
- フィーチャによって低減できるリスク
- スケジュール、コスト、機能
10章 金銭価値による優先順位づけ
- 新しい収益、増加する収益の他に、維持できる収益が存在する
- もし実行しなかった場合に失ってしまう収益のこと
11章 「 望ましさ」による優先順位づけ
- 狩野モデルでテーマを評価する
- 当たり前
- 一元的(線形)
- 魅力的
- 相対的重み付け
- フィーチャがある場合の利点とない場合の悪影響それぞれを1~9でポイント化→価値の合計
- 見積もりをコスト割合に変換
- 価値/コスト で優先度が出せる
12章 ユーザーストーリーの分割
- いつストーリー分割するべきか?
- 1イテレーション内に収まらないと気づいた時
- 大きいストーリーの見積もりの正確性をあげたい時
- 分割方法
- データ境界
- 操作境界
- 横断的な関心事
- 機能要求と非機能要求
- 優先度
- ストーリーとして分解すること。タスクとして分解してはいけない
- 小さすぎも良くない
第4部 スケジュールを立てる
13章 リリース計画づくりの基本
- リリース計画で現時点の目標を決める
- 満足条件を決める
- 見積もる
- ストーリーのリリース日を決める
- イテレーション終了時にリリース計画を見直すとうまくいく
14章 イテレーション計画づくり
- イテレーション内で行うタスクは詳細に理解しておく必要があるため、時間単位で見積もってもブレは少ない
- イテレーションレビューでプロジェクトに関わりのある人からフィードバックをもらう
- イテレーションのゴールを決める
- 着手するストーリーを選んだら、それをタスクに分解する
- 各タスク1日で終わるくらいのサイズた良い
15章 イテレーションの長さを決める
- リリースまでの軌道修正が必要な頻度を基準として、タイムボックスを決める。2週間~2ヶ月程度が一般的
16章 ベロシティの見積り
- 過去の実績でベロシティを見積もる
- イテレーションの経験を積む前に計画を建てる必要がある場合は、一日の予定作業時間から消化できるタスクを選び、メンバー数を考慮してベロシティを導出できる
17章 不確実性に備えるバッファの計画
- バッファ=不確実性に対する備え
- フィーチャバッファは必須以外の見積もり時間をバッファとして扱う方法
- 必須フィーチャは70%を超えないようにする
- スケジュールバファは見積もり全体に対してバッファをつける
- ここのタスクにはバッファはつけない
- バッファを設定する場合は元の見積もりの20%以下にはしないこと。それ以下だとリスクに対応する備えになりづらい
- 見積もり対象のストーリーが10個以内の場合はバッファは不要
- フィーチャバッファとスケジュールバッファを組み合わせることで、異なる不確実性に対応できるようになり、リスクが減る
18章 複数チーム編成プロジェクトの計画づくり
- チームで見積もり基準は揃える
- イテレーション開始前にはユーザストーリーは詳細化できるのが理想
- 合流バッファが必要なのは大規模チームのみ。中小チームでは不要
