【書籍】アジャイルな見積もりと計画づくり
書籍情報
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
概要
スクラムにおけるストーリー・ベロシティの見積もり方、優先順位の付け方、ストーリーを計画に組み込む手法についての説明
前提知識
必須
なし
推奨
スクラムの実経験
SCRUM BOOT CAMP THE BOOK 、カイゼン・ジャーニーなどのスクラムの流れを把握できる本
アジャイルを初めて勉強するためには向かなさそう。先に別の本を読んでおきたい。
再読するなら
第22章:なぜアジャイルな計画づくりがうまくいくのか
アジャイル計画試したけど何かの壁に当たったとき。
計画づくりのためのガイドラインが載ってて9ページ。
内容メモ
第7部・ケーススタディから逆算する
結局の所、~の手法がわからないから読み返したいはずなので、
ケーススタディの流れに沿って再読するのが良さそう。
ユーザーストーリーの洗い出し
P273:「プレイヤーとしてxxしたい」をベースにユーザーストーリーを探し出す。
例:「プレイヤーとして新しいゲームを開始したい」
ユーザーストーリーの見積もり
P279:ユーザーストーリーに対し、ストーリーポイント(≠作業時間、≒作業規模)、もしくは理想日(≒作業日数)を割り当てる
見積もり方
第6章:見積もり技法
見積もりのスケール
フィボナッチ数列(1,2,3,5,8…)を利用する。
スケール値をバケツと見なし、若干多く入れることもできるが、多すぎるとあふれる、程度の感覚でスケールする
対比・分割
ストーリーごとの見積もり結果が同じ程度の単位までに収まるようにする。
1~8であれば、作業間の規模を読み取れるが、1:100では100の規模を読み違える。
第12章:ユーザーストーリーの分割
ストーリーが大きすぎて1つのイテレーションに収まらない場合は分割を考慮する。
ただし、タスク単位への分割は行わない。
・データ境界に沿って分割する
・操作の境界で分割する
・横断的な関心事を分離する
・パフォーマンス成約を分離する
・優先度に沿って分割する
プランニングポーカー
各人にスケール値のカードを配り、ストーリーに対する見積もりを同時に出す
・同時に出すので、他人の意見に引きずられない
・値に差が出たときにそう感じた理由を説明してもらう。ほぼチーム全員が話すことになるため、団結感が出やすい
・説明により、全員が同意して平均化された値になる。
再見積もりの必要性
第7章:再見積もり
ユーザーストーリーの優先順位
P285:ユーザーストーリーの優先度をリサーチして決める
優先順位の要素
第9章:テーマの優先順位付け
・フィーチャの金銭価値
・フィーチャの開発にかかるコスト
・フィーチャの開発を通じて学べる知識の量とその意義
・フィーチャの開発によって低減できるリスク
P106:図9.2の「リスクと価値の四象分類」がある。フィーチャごとにこの図に載せて決定するのもあり。
第10章:金銭価値による優先順位付け
収益、開発コストなど、金銭的要素を考慮する場合の説明
第11章:「望ましさ」による優先順位付け
ユーザーへのリサーチも視野に入れた開発優先度考慮手法
第15章:イテレーションの長さを決める
リリースまでの長さを考慮して決める。
大体1~2週間がオススメ。
イテレーションの計画を作成
P288:第1イテレーションの計画づくり
この段階までで、ユーザーストーリーはあくまで「プレイヤーとして新しいゲームを開始したい」の単位から変更していない。
ユーザーストーリーの優先順位が付けられ、優先度の上位から改めてユーザーストーリーをタスクに分割する。
第14章:イテレーション計画づくり
ユーザーストーリーをタスク(+作業時間)に昇華する。
この時点では担当者は決めない。
ストーリー割当の基準
ベロシティ駆動
1イテレーションごとの目標ベロシティを決定し、それに収まる量のユーザーストーリーをそのイテレーションの目標に定める。
定めた分のユーザーストーリーをタスクに見積もる。
コミットメント駆動
ユーザーストーリーを一つ選びタスクを見積もる。
それのコミットがイテレーション内で確約できるなら対応し、次のユーザーストーリーを見積もる。
確約できないなら、それまでの確約分がそのイテレーションの目標になる。
タスク分割の補足
大きくても1営業日=1タスク程度の粒度で有るべき。
タスクが見積もれないとき
P170:調査をする・修正するの2タスクに分ける。
第16章:ベロシティの見積もり
下手に予想するよりは実際にやってみるほうが良し。
個人レベルの作業可能時間も見積もり、1イテレーションあたりの作業可能時間も見積もることで、進捗の把握がしやすくなる(バーンダウンチャート)。
第17章:不確実性に備えるバッファの計画
1タスクごとにバッファをつけるとパーキンソンの法則により、いっぱいまで時間を使ってしまいがちになる。
プロジェクトバッファを別枠で確保する。
プロジェクトバッファの計算例
・平均対応時間+√((最悪対応時間)-(平均対応時間))^2
・すべてのタスクを平均対応時間で見積もった上で、平均対応時間*1.5
第18章:複数チーム編成プロジェクトの計画づくり
・早い段階でユーザーストーリーの詳細化
・先を見越した計画づくり
チームAのデータがなければチームBの作業が進まないケースなど。
その場合、チームAの作業がイテレーション0.5分だったとしても、チームBは次イテレーションからの作業開始とする。
(チームAの作業が完全完了できなかったとき、イテレーション中での待ち時間を避ける、合流バッファの考え方
リリースプランニング
P296:プロダクトリサーチの結果などを用いて、リリース時点での製品状態を確定する。
タスクボード
P239:タスクボードを用意し、ストーリーごとにタスク・作業中・確認待ち(+その他)を貼り出すことで、視覚的にわかりやすくなる。
イテレーション終了時点で行うこと
P251の報告書の内容を確認していく。
バーンダウンチャート
リリースまでの残り作業の理想グラフに対して、実際の残り作業量グラフを書き込む。
理想に対する作業の進み具合・停滞具合が視覚化されるので、大きく問題が起きていたときに気づきやすい。
棒グラフ版
作業進捗+作業が溢れてることを確認できる。
でも見慣れない。
メモ
バグの扱い
P168
そのイテレーションで発生したバグであれば、そのイテレーション内で直すべきである。
前イテレーションのバグ・着手できなかったバグは次以降のイテレーションのバグタスクとして積まれる。
バグの修正≒新規タスク
コメントを残す