はじめに
「アジャイルな見積もりと計画づくり」という Mike Cohn氏を読んで、自分の中で「見積もりとは」のひとつの定義を確立することが出来た。「見積もりをしてください」と頼まれたときにどのようなものを作成し、ステークホルダーに提示・説明を行うのか、その良い指標になったので、本の要点を忘れっぽい自分の為にまとめた。
見積もりとは
- 見積もった時間内に作業が完了する確率のこと
- 見積もり = 完了の約束と捉えてしまうのは誤り
- 完了の約束は、別のフェーズでする！
- 見積もりは確率であり完了の約束は確率ではない
なぜ見積もりをするのか
-
見積もりと計画があって初めて意思決定が下せる
- 良い計画とはプロダクトとプロジェクトについての意思決定を行う根拠として信頼できるものである
- 良い計画とは信頼出来る計画だ
- 信頼出来る計画とはその計画を持って意思決定を下せる
- 定期的に計画をアップデートできていれば、はじめの見積もりが不正確であっても役に立つ
- プロジェクトのはじめから終わりまで何度も繰り返されるもの
- 計画づくりは、何を作るべきかという重要な問いに答える活動のことだ
何を見積もり対象にするか
- 顧客からすれば作業の完了に意味はない
- あるのはフィーチャ = 「機能」である
-
計画づくりではタスク(作業)ではなくフィーチャ(機能)を単位にするといい
- 「〇〇の実装がxx時間」の羅列ではなく、「△△ができる機能がxxくらい。優先度は＊＊」的な
アジャイルなアプローチ
- ひとつのチームとして作業する
- プロダクトオーナーは何する人?
- チームがプロジェクトのビジョンを目指せるようにする人
- 価値の高い機能の優先順位付けをする
- 最終的な意思決定を行う
- プロダクトマネージャー
- プロジェクトリーダーは何する人?
- リーダーシップを発揮する
- プロダクトオーナーは何する人?
- ビジネス上の優先度を重視する
- プロダクトオーナーの決めた優先順位に沿って開発する
- 短い繰り返し周期 = イテレーションで作業する
-
イテレーションごとに成果を上げる
- イテレーションが終わるまでにチームはイテレーション開始時点では明確に定義できていない要求を少なくとも１つはコーディングしてテストを行いリリース可能なソフトウェアとして統合すること
-
振り返り
- イテレーションが切り替わるタイミングで優先度を見直すのが良い
- 場当たり的に変えるのは良くない
- プロジェクトの投資から最大限のリターンを得るために並べ替える
良いプロダクトオーナーとは
- ⭐優先順位付けの最終責任を引き受ける
- ⭐チームの助言に耳を傾ける
計画づくりのイベント
プロダクト/ポートフォリオプランニング
- プロダクトの今後の発展や組織のビジョンに沿って取捨選択を行う
- 主にプロダクトオーナー/ビジネス層が行う
- このあたりは上層部がすでにやってることが多いかな
- もし開発に降りてきた時点でもフワッとしてたら、こちらから掘り起こすような質問をしていくことも大事
リリース計画
- 「なに」を「どれだけの期間」で開発するかを決める最初の計画
- 通常は3〜6ヶ月くらい?
- 機能以外にも、スケジュール、予算、品質などの達成目標などのプロダクトオーナーの満足条件を探っていく
- プロダクトオーナーの満足条件を理解すること無しに下位のプランニングをすることは出来ないので注意
- 最初の数イテレーション分にユーザーストーリーを割り振りその先は一旦まとめてそのままで良い
- チームで検討した「なに」を、と組織のゴールと比較を行い期待に答えることが出来るか検討できるので有用
- ユーザーストーリーやタスクに担当者や順番を決めない
- リリースに含まれそうなユーザーストーリーだけ見積もる
- その先の未来のユーザーストーリーについては見積もらない
- ポイントで見積もる
イテレーション計画
- 一般的に2〜４週間くらいの作業周期を設け、機能を実現するための作業(タスク)への落とし込みをする
- 参加者
- プロダクトオーナー
- プログラマ
- テスト担当者
- インフラ担当者
- 誰であれ実際に動作するプロダクトに関わる人なら全員
- 成果物
- そのイテレーションで完成できる機能の「完了の約束」 = コミットメントを行う
- ユーザーストーリーに紐付いたタスクのリスト
- コツ
- タスクリストはなるべく付箋でやるのがいい
- あるいは共同編集出来るツール
- 誰かがキーボードを独占するよりチームの意思が反映されにくくなる事がある
- タスクの担当者は決めずにイテレーション開始後に開発者が自発的に決める
- チームが一丸となって取り組んでいる、自分の空いた時間はチームのために使うし、他のメンバーもきっとそうしてくれると思える状態が望ましい
- 初めのうちや慣れない作業があるなら別タスクにする
- 見積もり
- 機能を実現するために必要なタスクを今度は「理想時間」で見積もる
- 割り込みなくひたすら作業したらどのくらいかかるか、というやつ
- 荒削りのリリース計画から、より精度を高めた計画を立てること
- 機能を実現するために必要なタスクを今度は「理想時間」で見積もる
- ユーザーストーリーの優先順位の見直しも忘れずに
ユーザーストーリー、ストーリーポイントって？
- 聞き慣れなくて初めは戸惑った
ユーザーストーリー = ユーザー体験
- 誰々が、なになに出来るよねってことが伝わる項目たち
- フィーチャ = 機能と表現されることもある
- 要するに、作業をベースに見積もりをするのではなく、ユーザーが得られる価値つまり機能、体験を主軸に優先順位付けして、計画していこうねっていうメッセージを伝えたいために作られた言葉っぽい
- 馴染みが無いので日本人な僕は「機能」と理解している
ストーリーポイント
- ユーザーストーリーや機能の「大きさ」を表す単位
- 1,2,3,5,8,13... フィボナッチが良いとかそういうやつ
- 3日分の作業だから5ポイントとかするのは上手くいかない
- 重要なのは他の作業との相対値
- 最も小さいと思えるユーザーストーリーを1とする
- ゼロポイントについて
- あまりにも小さな機能を1としてしまうと、別のユーザーストーリーのポイントが大きくなりすぎたり各ユーザーストーリーが細かすぎたりしてしまう。 人は10倍以内のものならうまく見積もれる(p74)らしい、また、ベロシティが変動しやすくなってしまうので、速攻終わるタスクはまとめてゼロポイントとするほうがいいケースがあるようだ
- なにはともあれまずはユーザーストーリーの規模の見積もりをしてからプロジェクトの期間を見積もる
見積もりにどのくらい労力をかけるべきか
長時間かけた見積もりが必ずしも正確なわけではなく、僅かな時間で決めたものとあまり変わらないことはよくある。収益逓減(ていげん)の法則。事前に決めた厳密な計画通りに進めるのが成功との思い込みにより、計画に時間をかけ過ぎてしまう事が多い。
チームで見積もることの価値
- 誰がどの作業をするかが事前に分からない事が多い
- 全員が担当する可能性がある以上は全員で見積もりすべき
- 一番くわしい人以外の意見(客観的な意見)が有用なこともある
ユーザーストーリーの単位
- フワッとしているものや、必要か分からないもの、大きすぎるものはユーザーストーリーではなく、まとめて「エピック」「テーマ」とするなど
- またまた聞き慣れないが、まとめる為の大きめの単位ってだけ
- 着手が数イテレーション先になるものはエピックやテーマのまま大きな数値(20,40,100とか)を使ってもいい
見積もりの視点
- 専門家の意見を聞く
- ユーザーに提供する機能をベースに見積もりするため、全てのスキルや知識を持って全体を見積もれる人物はそういない。専門家に聞いてしまおう
- ユーザーストーリー同士を対比する
- あの時見積もったAよりかは大きいが、Bよりかは小さい等の三角測量のような技法
- 小さく分割する
- 小さくし過ぎは見落としの危険 (to 12章)
複数人で見積もる
- 目標① 楽しみながら迅速に信頼できる見積もりをする
- 目標② 低コストで価値のある見積もりをする
- プラニングポーカー
- 参加者は開発者全員とプロダクトオーナー
- プロダクトオーナーは見積もり担当者からのあらゆる質問に回答すること
- 質疑応答完了後、各自一斉に見積もりを提示
- 2分の時計を使って、セッションを行う(自分の見積もりの説明を行う)
- 妥当なポイント採用し決める（精緻でなくても良い）
- 見積もり項目が多すぎる場合チームを分割
- 2,3人ごとにする
- はじめに10タスクほどは全員で見積もり、ベースラインの認識合わせをすると良い
- 価値
- 複数の専門家の見解をまとめた見積もりができる
- 活発な対話を引き出す
いつ見積もりをするべきか
- プロジェクト開始前、最初
- たくさんのユーザーストーリーを見積もる
- 1-2時間を3回などは覚悟する
- イテレーション中に新しいストーリが見つかった時
- 当日中か、イテレーションの終わりまでに近くの人を捕まえて複数人で見積もりを行う
いつ"再"見積もりをするべきか
- 進捗が想定通りではないという理由だけでのユーザーストーリーポイント再見積もりはしない
- ストーリの相対的な規模に変化があったとき(p86)
- 予想よりも時間がかかったからと言って他との相対バランスが崩れていなければそのままにしておく
- ポイントを大きく振り直したからと言って、他のタスクも増えるなら全体の量としては特に変わらないから
- 大事なのは一貫性
ユーザーストーリーが部分的に完了した時
- すぐ次のイテレーションで続きを対応出来る場合
- そのまま加算もせず見直しもしない。次のイテレーションに加算
- 長期間での平均速度なのでそれでも特に問題ない
- しばらく後に再開する場合
- 完了させた分を加算する（5のうちの3ptは完成した、等はチームの感覚でOK)
- 再見積もり分は残りの2ptである必要はない
- 部分的な完成は、やはりなるべく避けたほうが良い
- ユーザーストーリーは必ず完成させること！
- ユーザーストーリーを小さくしておく
- 再見積もりが必要かを思い悩まない
- 間違っている感覚があったなら、関係してそうなできるだけ少数のユーザーストーリーを再見積もりしてみて、今後の見積もりの学習として活用する
ポイント vs 理想日
理想日だと、技術者のレベルが上がったときに以前なら5日と見積もっていたものが1日になるかもしれない。ベロシティは変わらず5かもしれないが、実際には5倍の規模の作業をしている。作業量が増えてもベロシティが変わらない。規模（ポイント）で見積もりを行っていればこの数値は変動しにくい。ポイントは見積もりが楽。理想日は担当者によって変わる。理想日は関係者に説明しやすいのと導入しやすさがある。だが問題が多いかな。
優先順位付けの基準
- フィーチャの金銭的価値
- 収益や費用の節約がどの程度か
- フィーチャがユーザーにどれほど望まれているか
- フィーチャの開発にかかるコスト
- 後回しにしたほうが低コストならそうする
- フィーチャの開発を通じて学べる知識量と意義
- 目標の不確実性を減らせるか
- 何を作るかが明確になっていくのか
- 方法の不確実性を減らせるか
- どう作るかが明確になっていくか
- 目標の不確実性を減らせるか
- フィーチャの開発によって低減できるリスク
ユーザーストーリーの大きさ
分割タイミング
- 1回のイテレーションで収まらない大きさだった場合
- 差し込めるが完了するかわからない場合
分割箇所
- 扱うデータが違う部分
- 操作が違う部分
- CRUDで分ける
- 共通処理を分ける
- セキュリティ、ログ、エラーハンドリング
- 機能要求、非機能要求で分ける
大きさ
- だいたい2〜5日位(1週間イテレーションならもう少し少なめ）
- これは感覚値でOK
ベロシティ
- チームの進む速度を表す数値
- イテレーション内で完了したポイント数の合計 = ベロシティ
- 単位は特に無い
ベロシティの計測
- 必ずすべて完了したユーザーストーリーのみ計上すること
- ユーザーストーリーがイテレーション内に終わらなそうな場合
- すぐにプロダクトオーナーに相談
- ユーザーストーリーの大きさ、見積もりなどを振り返り次に活かす
- 個人のベロシティは"絶対に計測しない"
ベロシティを元にした速度見積もり
- 実績が出来てきたら今後の見通しを立てるために、
- 幅で表現する(15〜24だ、平均19だ、等)
- 過去の実績値を使う場合は以下が同じであること。そうでないとあまり参考にならない
- 技術、業務分野、チーム、プロダクトオーナー、ツール、作業環境、見積もった人
- 初期の見積もりミスを補正する役割を持つ
- 見積もりより低いベロシティであれば、完了までのイテレーション数を見直す必要がある
説得のコツ
- 特定の完了日を設定しないので、抵抗があることも
- 最初の数イテレーションを実施することで妥当な見積もりの根拠が得られることを強調する
- システムの不明な部分を明らかにし、採用する技術を十分に把握し、要求への理解を深めた上で、チームがどのくらいの速さで前進できるのかを知るために行う
バッファ
- 削れる機能に幅をもたせたフィーチャーバッファ
- スケジュールバッファ
タスクボード
- とにかく可視化
- やっぱり王道の付箋が良さそう
- リモート等がある場合は、GitHub projects のカンバンが良いかも
その他
- 小説を渡されていつ読み終わるかを聞かれるのと同じ
- 見た目で600ページと見積もる
- 1ページ読むのに1分かかった
- 600分かかることになる
- アジャイル開発のレイヤーは３つ
- リリース
- イテレーション
- イテレーション計画でコミットする
- 今日
- デイリーでコミットする
- タスクではなく機能に注目して洗い出す
- 全体像を見渡しやすくなる
-
マルチタスクにし過ぎない
- 2つが最も効率よく3つからどんどん効率が下がる
- 優先度の高い「機能」から開発する
参考
- 概念を捉えるためにまずは最小限で形から入ってみるのもありかなと思ったので、スライドを書いた