アジャイルな見積もりと計画づくり
職場の同僚からのお勧め本。
今回はいつもと違う感じでストーリー調に書いていきます。
状況把握
初めに、私はある新企画プロジェクトに参加することになったエンジニアです。リーダーの立場です。 開発メンバーは新卒です。他に企画系が2名います。
新企画プロジェクトの現状はだいたい作りたいものが決まっている状態です。 メンバー、リリース時期もだいたい決まっています。 ただし、仕様が決まっていない状態です。
ガントチャート / 試しにスケジュール作ってみる
そこで試しに「やること」を洗い出しました。 何も決まっていないのに、ステークホルダーから、いつ頃までにリリースできるか？といきなり聞かれたためです。 困りました。仕様も決まっていないのにリリース日が先なんです。
とりあえす「やるだろう」な項目を洗い出して、ガントチャートに起こしました。 また、困りました。
今回は、新卒のメンバーがいるため工数がとても出しにくいです。 作業スピードがどのくらいなのか、わかりません。まだ仕事にも慣れていない状態です。
出会い
これ読んで見たら？・・・紹介されました。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
アジャイルなプロジェクト計画と見積もり
プロダクトバックログと見積もり(story points)とvelocity
これを元にこれから始まるプロジェクトのバックログを作成＆見積もりをやって見ました。 プロダクトバックログは、プロダクトに必要な項目がまとまっている表のことです。
（この本では見積もりは、複数人でやることを推薦しておりますが、今回は一人でやりました。バックログの各項目はユーザーストーリという形でまとめたりするそうです。今回は機能（フィーチャー）という形式でまとめました。この時点であまり詳細化しない方が良いそうです。大きい単位はエピック、テーマなどと呼ぶそうです。）
バックログは着手すべき優先度の高い順序に並べます。（現状は、仕様が未定なのでとりあえず推測です）
見積もりは、基準の機能（だいたい何するか分かる機能）をピックアップして、ストーリーポイント＝5としました。 あとは、相対と直感でどんどん見積もっていきます。見積もりは作業時間ではなく「規模」で見積もっていきます。 作業時間だと熟練度で差が出てしまうためです。
ストーリーポイントは1,2,3,5,8,13,21,... とフィボナッチ数で見積もっていきます。 5が基準です。
イテレーションを1週間と仮定した場合にストーリポイント＝8が一人でクリアできそうなイメージです。
（書籍では、一人でこなせるストーリポイントは算出不可能な方が良いと語っております。ただし、今回はエンジニアが2名で1機能が一人ずつ一任して達成していくイメージで考えていたため、8 x 人数 --> velocity と考えられそうです。ベストプラクティスではなさそうですが・・。）
ところでvelocityは、実際に数イテレーションこなしてから平均化のようにしていくと良いようです。 将来的にどれくらいストーリポイントをこなせるか分かるためです。まだ一度もイテレーションを実施できていないので現状は推測です。
不確実性コーン
ところで、見積もりは不確実であるということを前提に行います。 不確実性コーンというものがあります。
要はプロジェクトの初期ほど不正確で後半になる程正確になることを表しています。 現状はプロジェクトの初期のため（まだ始まってもいない！）かなり不正確です。
リリース計画
これで下記が分かりました
- プロダクトバックログ
- 合計のストーリポイント数.... (sp)
- velocity .. 推測 ... (velocity)
- リリース日
- イテレーションの期間 ... (iteration)
- 仮で1週間
この情報から下記の計算式により、リリース時期が見えてきます。
sp / velocity * iteration -- > 必要なイテレーション数
この情報に、 * 年末年始、GW、メンバーの長期休暇、祝日の日数 * 不正確な見積もりのため、不確実性コーンを参考に最短、最長の予測をいれます。
これらを加味すればいつ頃にリリースできそうか見通しが立ちそうです。
もうガントチャートは不要です。
リリース計画ができました。
机上の空論にしてはなかなか良さそうです。
着手する「やること」、その順序も分かりました。ちょっと安心しました。 あとは、実際のvelocityが不明なのでイテレーションをやってみないと分かりません。 予定よりもできない可能性は十分あります。
今回は仮想のプロダクトバックログを相手にリリース計画を作りました。 予行演習ですね。
近々、プロダクトバックログをみんなでまとめる打ち合わせがあるので、そこでプロダクトバックログができそうです。
所感
リリース計画は、イテレーションが始まった後も絶えず更新し続けます。 初めに作って終わりではないそうです。
イテレーションのレビュー内容を元に新たなバックログが追加されるかもしれません。 このようにして積極的に変化を受け入れていくのだと思います。
各イテレーションでは最優先の項目が順に消化させていきます。 MUSTの項目さえ終わっていればリリースできる状態にはなりそうです。
そのためには、ある程度カテゴリ付けして置いた方がよかったかもしれません。 書籍には下記の4つが紹介されてました
- must have ... 必須
- should have ... 重要
- could have ... 有効
- won't have ... 不要
イテレーション
まだ始まっていないので....
また後でモチベーションがあったら書くかも
キーワード
- 不確実性コーン
- ストーリーポイント(story points) / 理想日 / 理想時間
- リリース計画
-
- イテレーション計画
- velocity 駆動
- コミットメント駆動 ... お勧め
- イテレーション計画
タイムボックス
- ユーザーストーリー
- フィーチャー
- エピック、テーマ
- プロダクトナレッジ、プロジェクトナレッジ
- ベロシティ(velocity)
- バッファ
- フィーチャバッファ
- スケジュールバッファ
- バーンダウンチャート
- 2weeks以上の場合のイテレーションではあると有用。
- ストーリーポイントの見積もりは10倍以内
- ゆとりを持った計画 ... 75%くらいにしておくと良い。
- 会議とか、割り込みとかを考慮
