毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第19弾です。
今回は アジャイルな見積もりと計画づくり を読みました。
アジャイル開発について詳しく解説をしている名著です。
アジャイルについて全く知識・経験がなかったですが考え方がとても合理的で面白かったです。
この記事を読めばアジャイルについての概要がつかめると思うので、興味ある方は是非読んでみてください。
今回は学ぶことが多かったので少し長めです。
- まえがき
- 第1部 問題とゴール
- 第2部 規模を見積もる
- 第3部 価値のための計画づくり
- 第4部 スケジュールを立てる
- 第5部 トラッキングと情報共有
- 第6部 なぜアジャイルな計画づくりがうまくいくのか
- おわりに
まえがき
-
アジャイル開発者の主張は次の通り。「私たちは今ここで分かっていることを元に計画を立てる。顧客にとって一番大切な目標を達成するために私たちは計画を変更する。プロジェクトが進んで新たな知識を得たら、それにプロジェクトと計画を適応させる。私たちから顧客への願いは、ビジネスの変化へ柔軟に適応することと当初の計画を死守するとことは矛盾した要求だと、きちんと理解してほしいということである」
-
プロダクトマネージャやプロジェクトマネージャに、専門的スキルを持つ人の仕事の進め方と仕事内容を決定する権限を与えてしまうのは、ビジネス的自殺といってもよい
-
アジャイルな見積もりと計画づくりの手法が従来型の手法よりも効果的な理由は、価値を提供することとビジネスとプロジェクトチームの間に信頼関係を築くことに注力しているためである。どんなことにも透明性を保ち、いかなる変更でもビジネス側に伝えることで、ビジネス側も素早く適応し、最善の判断を下すことができる
第1部 問題とゴール
1章 計画の目的
-
プロジェクトが進むにつれて見積もりは正確になる。「不確実性コーン」によれば、初期のプロジェクト定義の段階では見積もりには60%から160%に及ぶ誤差が生じる
-
よい計画とは、ステークホルダーが信頼できる計画である。信頼できるとは、その計画を基にして意思決定できるということである
-
アジャイルな計画づくりを定義すると以下のようになる
-
-
計画よりも計画づくりを重視する
-
変化を促進する
-
計画そのものは容易に変更できる
-
プロジェクト全体にわたって繰り返される
-
- アジャイルな計画は、「変更されても構わない」ではなく「積極的に変更したい」と考える。なぜなら、変更が起きるということはすなわち、なにか学習したり過ちに気づいたことを意味するからである
2章 なぜ計画づくりに失敗するのか
-
仕事の量は、完成のために与えられている時間をすべて満たすまで膨張する。これはパーキンソンの法則と呼ばれており、私たちは作業完了までの期間が決まっていると、許される限りの時間をすべて使ってしまう
-
マルチタスク化は生産性に甚大な悪影響を与え、遅れを助長する。個人が3つ以上の作業を並行して進めると、作業の切り替えにかかる時間がの増加が目立ち、価値を生み出す作業に使える時間が大幅に減少することが分かっている
-
不確実性に対処する最善の方法は、繰り返すことである。プロダクトがどうあるべきかという不確実性を低減させるには、短いイテレーションで作業して、計画を修正していくとよい
3章 アジャイル手法
-
アジャイルチームの基本的な仕事の進め方
-
-
1つのチームとして働く：すべてのプロジェクト参加者が、共通のゴールを持った1つのチームに参加している意識を持つ
-
-
-
ビジネス上の優先度を重視する
-
-
プロジェクトというものは新たな機能と知識を生み出し続ける活動であり、単に決められた手順を実行するだけではない
-
アジャイルチームは3つのレベルで計画づくりをする
-
-
リリースプランニング：リリース全体についての計画であり、3ヶ月から6ヶ月という期間がよく使われる。ゴールは、プロジェクトのスコープ、スケジュール、リソースについて回答を出すこと
-
-
-
今日のプランニング：日々のスタンドアップミーティングでメンバーがその日に何をするか決める1日単位の計画
-
-
リリースプランニングとイテレーションプランニングには、プロダクトオーナーの満足条件を理解することが必要
- ユーザーストーリーは、ソフトウェア要求を表現するための簡単な手法
-
-
よく使われるフォーマット：「＜ユーザーの種類＞として、＜機能や性能＞が欲しい。それは＜ビジネス価値＞のためだ」
-
-
-
例：「本の購入者として、ISBNで本を検索したい。それは探している本をすばやく見つけるためだ」
-
第2部 規模を見積もる
4章 ストーリーポイントによる規模の見積もり
-
ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさを表す単位である。ストーリーポイントを使った見積もりでは、ひとまとまりの仕事に対してポイントをつける。ポイントの数値そのものは重要ではなく、他の作業との相対値が重要である
-
ストーリーポイントによる見積もりの始め方には2種類ある。これから取り組むストーリーの中で最も小さいと思えるものを基準としてそれを1ポイントとする方法と、中くらいと思えるストーリーを決めて、それに見積もりで使う数値範囲の中央に近い値をつける方法である
-
アジャイルな見積もりでは「規模を見積もり、期間は導出する」
-
プロジェクトが進捗するということはユーザーストーリーをこなしていくことなので、数イテレーションも実施すればチームのベロシティがわかってくる。ポイントによる見積もりの素晴らしい点は、ベロシティを適用することで計画時の見積もりミスが自動的に補正されることである
5章 理想日による見積もり
-
ユーザーストーリーの開発にかかる時間は、現実日で見積もるよりも理想日で見積もる方が簡単である。現実日による見積もりでは、ストーリーの完了までに起こりうる、あらゆる割り込みを考慮しなくてはならない。理想日による見積もりなら、ストーリーに必要な時間だけを検討すればよい
6章 見積もりの技法
-
わずかな時間で考えた見積もりと、長時間悩んだ末に出した見積もりがほとんど同じになるのはよくある。ある程度以上の労力を費やしても、見積もりの正確さには寄与しないことが多い（収益逓減(ていげん)の法則）
-
見積もりはチーム全体で出した方がよい。アジャイルプロジェクトでは誰がどの作業をするのか事前に決めていないことが多く、全員が作業を担当する可能性がある全員が関与した方がいいため
-
人は10倍以内のものならうまく見積もれるという研究結果がある。見積もりのスケールには「1, 2, 3, 5, 8」というフィボナッチ数列をよく用いる（対象が大きくなると不確実性が増える様子にうまく対応しているため）
- 必要かどうかまだわからないフィーチャや、近い将来には開発予定のないフィーチャは、1~8よりも大きな単位で見積もるユーザーストーリーを作りたいことがある。このような大きなユーザーストーリーはエピック（epic）と呼ばれる
-
プランニングポーカーは、専門家の意見、対比、分割の全てを組み合わせ、楽しみながら迅速かつ信頼できる見積もりを出すことができる。プランニングポーカーの参加者はチームの開発者全員である
-
-
まず最初に、全員に一組のカードを配り、そこにはチームで使用できる見積もりポイントが1枚につき1つずつ書かれている
-
-
-
進行役となる人が、見積もり対象のユーザーストーリーやテーマを1つずつ読み上げ、見積もり担当者からの質問にはプロダクトオーナーが回答する
-
-
-
見積もり担当者は、自分がこうだと思う見積もりポイントのカードを選ぶ。選んだカードは全員が選択し終えるまで人には見せないようにし、全員の見積もりが決定したら一斉にカードをオープンする
-
-
-
人によって見積もりが大きく異なることは、見識の相違から学ぶチャンスである。高い見積もりを出した参加者と低い見積もりを出した参加者に、見積もりの根拠を説明してもらう。この時、見積もった人を非難しているように見えないよう留意する
-
-
-
議論を終えたら、見積もり担当者はそれぞれ再び見積もりポイントカードを選んで、一斉にオープンする
-
-
-
多くの場合、見積もりは第2ラウンドで収束するが、収束しなければここまでの手順を繰り返す。ゴールは、全員が合意することにある
-
-
プランニングポーカーがうまくいく理由
-
-
複数の専門家の見解をまとめた見積もりを実現するため
-
-
-
活発な対話を引き出すため。見積もりについて説明を求めると、情報の不足を補った良い見積もりとなるため
-
-
-
個人の見積もりを平均した方がよりよい結果を残す傾向があるという研究結果があるため
-
-
-
楽しいため
-
7章 再見積もり
-
再見積もりが必要となるのは、ストーリーの相対的な規模に変化があったとチームが判断した時（例えば、あるシナリオだけがより時間を要すことがわかった場合など）である。あるストーリーが想定よりも長く時間を要したというだけでは再見積もりはしない
- イテレーションの終了時点でストーリーが部分的に完成している場合、ストーリーを分割して再見積もりしたくなるが、そのようなことはしない。この場合、今回のイテレーションのベロシティは少し下がり、次回のイテレーションのベロシティは少し上がるが、ベロシティの目的は長期間でのチームの平均速度を図るためであり、特定のイテレーションのベロシティには特別な意味はないので問題ない
8章 ストーリーポイントと理想日
-
ストーリーポイントは純粋な大きさのみを測定する値だが、理想日はそうではない。開発者のスキルが変化すれば理想日の見積もりも変化してしまうが、ストーリーポイントではこうしたことは起きない
-
理想日は人によって異なってしまうが、ストーリーポイントは人によって異なることはない
- 「これはあれと近い」と相対的な大きさで見積もる方が、絶対的な大きさで見積もるよりもよい結果になることが研究でわかっている
第3部 価値のための計画づくり
9章 テーマの優先順位づけ
-
新しいフィーチャの優先順位づけに必要な4つの要素
-
-
フィーチャの金銭価値
-
フィーチャの開発（サポートも含む）にかかるコスト
-
フィーチャの開発を通じて学べる知識の量とその意義
-
フィーチャの開発によって低減できるリスク
-
-
4つの要素を総合して優先順位をつけるとき、第一に考えるのはフィーチャの価値とそのフィーチャを開発するのにかかるコストである。コストに対して最も高い価値を持つテーマが、最初に着手すべきテーマとなる。さらに、他の優先順位づけの要素を検討してテーマの優先順位を上下する
10章 金銭価値による優先順位づけ
-
財務的に分析することは優先順位づけに役立つ。利益と業務改善の効果を予想するのは2年先までが一般的である
-
キャッシュフローの評価には、正味現在価値、内部収益率、回収期間、割引回収期間の4つの指標を利用する
11章 「望ましさ」による優先順位づけ
-
-
線形、一元的なフィーチャ：あればあるほどよいもの。線形、一元的というのは、フィーチャの量に比例して顧客満足度が線形に高まることに由来する
-
-
-
魅力的な、わくわくするフィーチャ：大きな満足をもたらしたり、わくわくする気持ちになったりするもの。このフィーチャは無いからといって顧客満足度が悪くなることはない。ユーザーは体験してみるまで、そうしたフィーチャが必要だということに気づかない
-
-
当たり前のフィーチャを備えたら、線形のフィーチャをできるだけ多く完成させることを重視する。魅力的なフィーチャはこれらの機能を実装した後に、時間の許す範囲で対応する
-
ユーザーからアンケートを取ることで、フィーチャを簡単にカテゴリに分類することができる
12章 ユーザーストーリーの分割
-
1つの大きなストーリーを見積もるよりも、分割して見積もった方が正確な見積もりになる
-
ユーザーストーリーを分割するタイミング
-
-
ストーリーが大きすぎて1回のイテレーションに収まらない場合
-
- 代表的な分割方法
-
- 扱うデータによって分割する
-
- CRUD操作それぞれで分割する
-
- 横断的な機能（ロギングやエラーハンドリングなど）を別のストーリーへ分割する
-
- パフォーマンス要件を別のストーリーへ分割する
-
- サブストーリーの優先度で分割する
- 分割しづらいタスクに出くわしたとき、ついストーリーをタスクに分割したくなるが、タスクへの分割は避ける
- 分割したストーリーに、関連する変更を追加しない。分割した意味がなくなってしまう（よくある例：ついでに同じ箇所にある既存のバグを直す、というのは避ける）
-
チームのイテレーション期間が2週間であれば、2日から5日で完了できる大きさにストーリーを分割するのが適切な大きさである
第4部 スケジュールを立てる
13章 リリース計画づくりの基本
- リリース計画の役割は、いつどれだけの成果が出せるかを判断すること
- 想定されるベロシティを予定しているイテレーションの数とかけて、その結果を超えない範囲でユーザーストーリーを選択すればよい
-
一般的には、3ヶ月から6ヶ月の周期でリリースを繰り返すことが多い
-
リリース計画は定期的な見直しと更新が必須である。多くのプロジェクトがイテレーション終了時点でリリース計画を見直すようにルールを定めている
14章 イテレーション計画づくり
- イテレーションプランニングの目的は、荒削りなリリース計画から、より精度を高めたイテレーション計画を立てることである。リリース計画が3ヶ月から6ヶ月の期間を対象とするのに対し、イテレーション計画は1回のイテレーションだけを対象とする。リリース計画で扱う比較的大きなユーザーストーリーを、イテレーション計画ではタスクに分解する
- リリース計画では見積もりにストーリーポイントを使うが、イテレーション計画では計画の精度が高まっているのでタスクの見積もりに時間を使う
- イテレーションプランニングの手順
-
イテレーション計画には、ユーザーストーリーをプロダクトに統合して動作させるために必要な全てのタスクを含めるべきである
-
タスクのサイズは、開発者が平均して1営業日に1つ完了できるくらいの大きさが適切である
15章 イテレーションの長さを決める
-
-
リリースまでの期間：リリースまでに最低4、5回はイテレーション終了時のレビューでフィードバックを受けられるようにする
-
-
-
不確定要素の高さ：プロジェクトの不確実性が高いほど、軌道修正の機会を増やすためにイテレーションは短くすべき
-
-
-
フィードバックの得やすさ
-
-
-
優先順位が安定している期間
-
-
-
外部からのフィードバックの必要性
-
-
-
イテレーションのオーバーヘッド
-
-
-
切迫感を感じ始めるまでの時間
-
- この本の筆者が理想的だと考えるイテレーションの長さは2週間
16章 ベロシティの見積もり
-
ベロシティの見積もり方法としての選択肢で望ましい順に以下がある
-
-
ベロシティの見積もりを出す前にイテレーションを1回でも実施できるなら迷わずそうする。実績値にまさる見積もりはない
-
-
-
同じメンバーが携わった、今回のプロジェクトに関係のあるプロジェクトでの実績値を使う
-
-
-
イテレーションあたりの作業可能時間数を使ってベロシティを予想する
-
- いずれの方法を採用するにせよ、ベロシティの見積もりには幅を持たせる
-
どのやり方で見積もったにせよ、ベロシティの実績値を使えるようになったら、すぐそちらに切り替える
17章 不確実性に備えるバッファの計画
-
バッファの持たせ方でよく使われる方法は、フィーチャバッファとスケジュールバッファの2つである。
-
-
フィーチャバッファは、プロダクトに対する要求が優先順位づけされていて、その全てが必ず提供されるわけではないと合意できている場合に用意するバッファである。時間が足りなくなったときは、フィーチャバッファにあるフィーチャを削ることでスケジュールを守る
-
-
-
スケジュールバッファは、全体のスケジュールに対して適用するバッファである
-
18章 複数チーム編成プロジェクトの計画づくり
-
アジャイルプロジェクトは、大規模なプロジェクトに対しては、1つのチームを大きくするのではなく、複数の少人数チームを編成することが多い。チーム間で共有できる見積もり基準の確立、ユーザーストーリーの早い段階での詳細化などが必要となる
第5部 トラッキングと情報共有
19章 リリース計画のモニタリング
20章 イテレーション計画のモニタリング
- イテレーションのトレッキングに使う2つのツール
-
-
タスクボード：どのタスクが作業中で、どのタスクがサインアップ待ちなのかが一目でわかるツールである。タスクボードの列にはそれぞれラベルをつけておき、作業の進行に応じて対応するタスクカードをチームメンバーが順番に右側の列に動かしていく
-
21章 計画とコミュニケーション
-
見積もりと計画のコミュニケーションは、正直で頻繁な、双方向のものであるべきである。これはアジャイルな計画とは頻繁に更新されるものであり、フィードバックと新しい知識を繰り返し反映させることで洗練させていくためである
第6部 なぜアジャイルな計画づくりがうまくいくのか
-
-
1. チーム全体を巻き込む：見積もりはチーム全体で出すなどチーム全体の参加とコミットメントを引き出す
-
-
-
2. 複数レベルの計画を立てる：リリース計画、イテレーション計画、今日の計画それぞれに狙いがある
-
-
-
3. 大きさの見積もりと期間の見積もりを区別するために別々の見積もり単位を使う：作業の大きさにはストーリーポイント、期間にはベロシティを使うとよい
-
-
-
4. 不確実性はフィーチャか日付のいずれかで表現する：追加するフィーチャが決まっていて動かせないなら計画の不確実性は日付の幅で表現し、日付が固定されているなら提供予定のフィーチャに幅を持たせて不確実性を表現する
-
-
-
5. 頻繁に計画を見直す：新しいイテレーションを始めるタイミングは、現在のリリース計画を見直すいい機会である
-
-
-
6. 進捗をトラッキングして情報を共有する：プロジェクトの進捗をあらわす手段には、バーンダウンチャートなどの一目でわかるグラフを使うのがベスト
-
-
-
7. 学習することの大切さを受け入れる：プロジェクトは、プロダクトにフィーチャを追加するのと同じくらい新しい知識を生み出すものである。新しく得た知識があれば、必ずそれを計画にも反映する
-
-
-
8. フィーチャは適切な大きさで計画する：数イテレーション以内の近い将来に開発予定の機能は、比較的小さなユーザーストーリーに分割する。ユーザーストーリーのサイズは1、2日から10日位までの大きさが一般的である
-
-
-
9. フィーチャを優先順位づけする：フィーチャの価値とコストだけでなく、フィーチャから得られる知識と、フィーチャを開発することで軽減できるリスクも考慮に入れる
-
-
-
10. 現実に即した見積もりと計画を立てる：見積もりと計画は、測定した実測値を根拠とすべき
-
-
-
11. ゆとりを残す：メンバー全員の時間を100%使い切るような計画を立てない。高速道路の限界100%まで車を詰め込むと誰も身動きの取れない渋滞になってしまうのと同じ
-
-
-
12. 複数チームの連携には「移動する先読み範囲」を使う：チーム間で依存関係が生じるフィーチャについては、ある程度先を見越して、あらかじめ実装するイテレーションを決めておく
-
おわりに
ここまで読んでいただきありがとうございます。
アジャイルの合理的な考え方に共感し、是非一度やってみたいなーという気持ちになりました。
本書では具体例を多く取り入れながら一つ一つ詳しく解説してくれているので、アジャイルに興味を持った方は是非読んでみてください。
