書籍情報

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
Amazon

概要

スクラムにおけるストーリー・ベロシティの見積もり方、優先順位の付け方、ストーリーを計画に組み込む手法についての説明

前提知識

必須

なし

推奨

スクラムの実経験
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
そのイテレーションで発生したバグであれば、そのイテレーション内で直すべきである。
前イテレーションのバグ・着手できなかったバグは次以降のイテレーションのバグタスクとして積まれる。
バグの修正≒新規タスク