アジャイルな見積 規模による相対見積 アジャイル・スクラム勉強会 Satoshi Harada

見積タイミングの違い ● WFは最初に1回で見積もる ► プロジェクト開始前に、開発スピードやリスクを予想して 見積もる ✔ プロジェクトの途中で思ったよりも早く開発が進んでいる場合 は？ ✔ プロジェクトの途中で思ったよりも開発が進まない場合は？ ● アジャイルは分散させて複数回見積もる ► 1スプリント毎（1週間毎など）に見積もる ✔ それまでの経験や学習によって開発メンバーの開発スピードが 上がっていることを見積もりに反映できる ✔ 逆に、思ったよりもスピードが上がらない・不測の事態が発生 なども、見積もりに反映できる

見積で使用するツール ● PBL(Product Back Log)　−　優先順に並んだ機能の一覧 ► プロダクトやシステムで実現したい機能が優先順で並んでいる一 覧 ► 機能の内容はお客様の言葉で書かれている 例：＜ユーザのロール＞は＜機能の内容＞したい。なぜならば ＜ビジネス上の価値＞をしたいからだ。 ► 各機能に対して、開発チームが“規模”を見積もる ● SBL(Sprint Back Log)　−　スプリントのタスク一覧 ► 1スプリント（1週間など特定の期間）で実施するタスクの一覧 ► 日々のステータスを管理するため、カンバンボードを使用するこ とが多い ► 各タスクに対して、開発チームが“理想時間”を設定する ✔ 理想時間とは、スムーズに割り込み作業などがなければどれくらい の時間でタスクが終わりそうかということを示した日数

PBLとSBLの運用例 PBL SBL タスクA-1 機能A 機能B 機能C お客様の代表 (プロダクトオーナー) 開発チーム More… タスクA-2 タスクB-1 タスクB-2 ● PBLの項目はプロダクトやサー ビスの機能はどうあるべきか・ 優先度はどうするかという話な ので、PBLは基本的にお客様の 代表（プロダクトオーナー）が 管理する ● SBLの項目は機能を実現するた めの具体的なタスク（画面を実 装する・DBを構築する・デー タを挿入すると言ったレベル） を示すので、SBLは開発チーム が管理する ● SBLのタスクは、PBLの中から 優先順の高い機能をピックアッ プしてタスク分解して用意する ● SBLのタスクに対するレビュー は開発チーム内で行う ● PBLの機能に対するレビューは お客様の代表（プロダクトオー ナー）に対して行い、成果物と して受け入れてもらう必要があ る 優先度

PBLはなぜ“規模”で見積もるのか ● 古から使われてきた見積手法 ► ステップ数 ✔ プログラムの行数から規模を見積もる。単純だが不正確。 ► ファンクションポイント法 ✔ 機能の複雑性をもとに見積もる。正確だが複雑で時間がかかる。 ► 過去の実績日数から見積もる ✔ 熟練者が過去の経験をもとに見積もる。過去の実績と内容が一致していれば見積 もり精度も高いが、経験と違うところがあれば見積がズレる。 ✔ そもそも経験者がいないと正確に見積もれない。 ● 規模を見積日数といった具体的な指標で見積もると問題が多い ► 今現在の見積日数と、1ヶ月後の見積日数は一致しない可能性がある ✔ 一ヶ月後は習熟が進んだことで見積日数が減るかもしれない ► 人ごとに作業に対する見積日数が異なる場合がある ✔ 熟練者と初級者で同じ作業なのに見積日数は異なる ► お客様に見積日数＝現実日数であると誤解される恐れがある ✔ 見積が予測ではなく約束になってしまう そのため、人ごとに尺度が異なる・誤解されやすい“日数”ではなく、 ポイントなどの抽象的な“規模”で見積もる

規模を“相対見積”で見積もる理由 ● 例えば、このビルの高さを見積 もってほしいと言われた場合、ど うするか？ ✔ 過去に見たことがあるビルの高さか ら、当てずっぽうで言ってみる？ ✔ 16階建てだから、1階あたりの高 さがわかればわかるかも？ ✔ 隣のビルの高さがわかったら、ざっく り2倍くらいかも？ ● 機能の見積もこれと同じで、基準 となる規模見積に対して比べるこ とで相対的に見積もる ► 基準値を5ポイントとする例 ► 同じくらいの規模：5ポイント ► ちょっと大きい：8ポイント ► ちょっと小さい：3ポイント ► 2倍くらい：10ポイント ？ 機能A 機能B 機能C 5pt 8pt 3pt

規模から期間への変換はどうする？ ● 以下のような手順を行うことで、ポイントなどの規模から期間へ変 換できる 1. 1スプリント（1週間など特定の期間）で何ポイントのPBL項目を消化 できるか測定する ► 例えば、1スプリントで10ポイントを消化できたとする 2. PBLのすべての項目の合計ポイント数を、1スプリントで消化できた ポイント数で割る ► 例えば、PBLの全ての項目の合計ポイント数が100ポイントだとしたら、1 スプリントで10ポイントのPBL項目を消化できるので、10スプリント （10週間）でPBLの全ての機能が実現できる見込みとなる ● このようにPBLの総規模（総ポイント数）から「限られた期間でど こまで機能を実現できそうか」を予測できる ► この情報を使って、プロジェクトの着地点（期間内でどの機能まで実 現できそうか）をお客様の代表（プロダクトオーナー）と会話するこ とができる ► 開発チームの本当の開発スピードを使って測定した結果なので、説得 力がある ✔ お客様や自社の上層部からの「もっと早くできるはずでは？」というプ レッシャーに現実的に回答できる

SBLのタスクには理想時間を設定する ● PBLの機能をSBLでタスクレ ベルに分解する ✔ このタイミングで、担当す る人ごとに理想時間を設定 する ✔ ただし、理想時間は機能の 規模見積には使用しない点 に注意 ● SBLで設定したタスクの理想 時間は1スプリント内の進捗 管理でのみ使用する ✔ 未着手・着手・レビュー中 ・完了で振り分けて、状況 を見える化する ✔ 1スプリントの最後に、お 客様に対して機能をレ ビューできそうか把握する 機能A タスクA-1 タスクA-1 初級者 熟練者 5pt 3日 5日 対象の機能の見積ポイントや、タスクの作業規模は 同じだが、習熟度によって理想時間が異なる。 しかし、チーム全体で「1スプリントあたり10ポイ ント消化できる」実績がわかっていれば、PBLで行 う機能の規模見積（ポイント見積）ではチーム全体 として見積もるので個々の習熟度の違いは無視でき る。 PBLの見積は、個人のパフォーマンスではなく、 チームのパフォーマンスで見積もるのがポイント

言葉の定義を整理 今回の勉強会で登場した新しい言葉について定義を整理します。 PBLやプロダクトオーナーなど、これまであまり馴染みのない言葉も多いので、慣れ るまで適宜日本語の言葉に置き換えてもよい。（言葉の正確性よりも目的を達成でき ることが大事） ● PBL(Product Back Log)　−　優先順に並んだ機能の一覧 ✔ プロダクトやシステムの機能を優先順で並べた一覧 ✔ 規模で見積もる ● SBL(Sprint Back Log)　−　xサイクル目のタスク一覧 ✔ スプリント内で実施するタスクの一覧 ✔ PBL項目から作業分解してタスクを洗い出す ✔ 各タスクに理想時間を設定する ● プロダクトオーナー　−　お客様の代表 ✔ お客様の代表者 ✔ 機能の定義や優先順の決定に責任を持つ ● 開発チーム ✔ 開発者の集まり ✔ 機能の相対見積もりやタスクの見積もりに責任を持つ ● スプリント　−　開発サイクル ✔ 1週間など、区切られた期間

雑談Time 日数ではなく規模で見積もること について、どのような印象を持ち ましたか？ 直近のスプリントの実績ポイント を用いることで、機能が完成する タイミングを未来予測できること について理解できましたか？