【読書メモ】なぜアジャイルな計画づくりがうまくいくのか ?
目的
上手くいく要因を理解するため
アジャイルな計画づくりの目的
プロダクト開発全体への問いに対する最適な回答を見つけ出すこと
アジャイルな見積もりと計画づくりはプロジェクトの最適解を見つけられるからこそ成功する
全てはプロダクト開発全体への問いに答えるため
アジャイルな見積もりと計画づくりのための12のガイドライン
1. チーム全体を巻き込む
2. 複数レベルの計画を立てる
3. 規模の見積もりと期間の見積もりに別々の単位を使う
4. 不確実性はフィーチャーか日付の幅のいずれかで表現する
5. 頻繁に計画を見直す
6. 進捗をトラッキングして情報を共有する
7. 学習の大切さを受け入れる
8. フィーチャーは適切な大きさで計画する
9. フィーチャーを優先順位づけする
10. 現実に即した見積もりと計画を立てる
11. ゆとりを残す
12. 複数チームの連携にはフィーチャーが移動する事を先読みして計画する
1. チーム全体を巻き込む
要求の優先順位づけを最終的に判断するのはプロダクトオーナー
- チーム全体で行うべきもの
- 見積もり
- 見積もったユーザーストーリーやタスク
- 1人か2人
チームで共有できる責任が増えれば増えるほど、チームで共有できる成功は大きくなる
2. 複数レベルの計画を立てる
大きく3つ
- リリース計画
- イテレーション計画
- 1日の計画
期間も制度も独自の狙いがある
3. 規模の見積もりと期間の見積もりに別々の単位を使う
- 規模
- ストーリーポイント
- 期間
- ベロシティ
4. 不確実性はフィーチャーか日付の幅のいずれかで表現する
- フィーチャーとは
-ユーザーにとって役に立つ機能
- リリースプランニング
- 必ず不確実性を反映させる
- 不確実性
- 日付の幅で表現する
- 「~ の間に完了します。」「○イテレーションから△イテレーションの間に完了します。」など。
- フィーチャーは交渉できるが期日は固定されている場合
- 提供予定のフィーチャーに幅をもたせて不確実性を表現する
- 「○月○日に完了させるがその時点で確実に約束できるのはこれとこれ。余裕があったらこれもできるがそれ以上は無理」
- 不確実性が高い場合
- 不確実性に合った計画単位で話す。(リリース、イテレーション、1日)
5. 頻繁に計画を見直す
- 新しいイテレーションを始めるタイミング
- リリース計画を見直すタイミング
- 更新対象
- 既に古くなっている情報
- 間違っている見込みが高い仮定
計画の見直しはプロジェクトが最大限の価値を提供できるように進んでいるかどうかを評価するチャンス
6. 進捗をトラッキングして情報を共有する
- チームの進捗は一目で理解できるようにする
- 常に公開しておく
- バーンダウンチャートなどがベスト
- 個人ではなく、チームを計測する
7. 学習の大切さを受け入れる
- プロジェクトとは、プロダクトにフィーチャーを追加するのと同じくらい新しい知識も生み出す。
- それを必ず計画に反映する
- 新しいフィーチャーは顧客がなにを求めているのかを学ぶ事で追加できる
- 技術理解、チーム作業における新しい発見から進捗速度や開発の進め方の調整ができる
8. フィーチャーは適切な大きさで計画する
- 数イテレーション以内の直近開発予定のもの
- 小さなユーザーストーリーに分割する
- ユーザーストーリーとは
- 顧客の意図や要求の断片
- 一般的なユーザーストーリーのサイズ
- 1、2 ~ 10日くらい
- プロジェクトの期間とストーリーの大きさ、量のバランス
- ストーリーの大きさを計画の対象期間に合わせる
- 計画の対象期間が長い場合
- ストーリーをエピックとしてくくる(大きな塊)
- エピックとは
- 関連するユーザーストーリーの集合
- 期間が先のストーリーを小さく分割する必要はない
9. フィーチャーを優先順位づけする
- フィーチャーの優先順位
- プロジェクト全体の価値を高められるかが判断基準
- 他の判断基準
- フィーチャーから得られる知識
- フィーチャーを開発する事で軽減できるリスク
- フィーチャーを実装することで重大なリスクを先行して解消できる
- フィーチャーに取り組むことでプロダクトやプロジェクトのナレッジを深められる事が明白など
10. 現実に即した見積もりと計画を立てる
- 根拠とない実績がほとんどない状態でのベロシティの見積もり
- ベロシティ見積もりのテクニックを押さえる
- できる限り測定した実績値を根拠とする
11. ゆとりを残す
- チームメンバー全員の時間を100%使い切るような計画を立てない
- 車の密度が100%の高速道路は渋滞で進めない
- 限界まで時間を使うと進みは遅くなる
12. 複数チームの連携にフィーチャーが移動する事を先読みして計画する
- チーム間で依存関係が生じるフィーチャーについては、ある程度先を見越して実装するイテレーションを決めておく
- 依存関係を計画に組み入れる
雑感
「ゆとりを残す」が印象的
バッファをもたせることは大事だけれど、何も考えずにこれに合わせると、結局はパーキンソンの法則で時間いっぱいになる
逆に決めた時間いっぱいになるのなら、自分の中でのスケジュール期限は少し短めに設定して、それに合わせて本気で進める事が大事そう
セーフティな期限で短く粒度を決めて、締め切り効果で常に取り組むのが良さそうです。
この記事が気に入ったらサポートをしてみませんか？