Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Satoshi Harada

June 09, 2022
Tweet

More Decks by Satoshi Harada

Other Decks in Programming

Transcript

  1. 見積タイミングの違い • WFは最初に1回で見積もる ► プロジェクト開始前に、開発スピードやリスクを予想して 見積もる ✔ プロジェクトの途中で思ったよりも早く開発が進んでいる場合 は? ✔

    プロジェクトの途中で思ったよりも開発が進まない場合は? • アジャイルは分散させて複数回見積もる ► 1スプリント毎(1週間毎など)に見積もる ✔ それまでの経験や学習によって開発メンバーの開発スピードが 上がっていることを見積もりに反映できる ✔ 逆に、思ったよりもスピードが上がらない・不測の事態が発生 なども、見積もりに反映できる
  2. 見積で使用するツール • PBL(Product Back Log) − 優先順に並んだ機能の一覧 ► プロダクトやシステムで実現したい機能が優先順で並んでいる一 覧 ► 機能の内容はお客様の言葉で書かれている

    例:<ユーザのロール>は<機能の内容>したい。なぜならば <ビジネス上の価値>をしたいからだ。 ► 各機能に対して、開発チームが“規模”を見積もる • SBL(Sprint Back Log) − スプリントのタスク一覧 ► 1スプリント(1週間など特定の期間)で実施するタスクの一覧 ► 日々のステータスを管理するため、カンバンボードを使用するこ とが多い ► 各タスクに対して、開発チームが“理想時間”を設定する ✔ 理想時間とは、スムーズに割り込み作業などがなければどれくらい の時間でタスクが終わりそうかということを示した日数
  3. 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の機能に対するレビューは お客様の代表(プロダクトオー ナー)に対して行い、成果物と して受け入れてもらう必要があ る 優先度
  4. PBLはなぜ“規模”で見積もるのか • 古から使われてきた見積手法 ► ステップ数 ✔ プログラムの行数から規模を見積もる。単純だが不正確。 ► ファンクションポイント法 ✔

    機能の複雑性をもとに見積もる。正確だが複雑で時間がかかる。 ► 過去の実績日数から見積もる ✔ 熟練者が過去の経験をもとに見積もる。過去の実績と内容が一致していれば見積 もり精度も高いが、経験と違うところがあれば見積がズレる。 ✔ そもそも経験者がいないと正確に見積もれない。 • 規模を見積日数といった具体的な指標で見積もると問題が多い ► 今現在の見積日数と、1ヶ月後の見積日数は一致しない可能性がある ✔ 一ヶ月後は習熟が進んだことで見積日数が減るかもしれない ► 人ごとに作業に対する見積日数が異なる場合がある ✔ 熟練者と初級者で同じ作業なのに見積日数は異なる ► お客様に見積日数=現実日数であると誤解される恐れがある ✔ 見積が予測ではなく約束になってしまう そのため、人ごとに尺度が異なる・誤解されやすい“日数”ではなく、 ポイントなどの抽象的な“規模”で見積もる
  5. 規模を“相対見積”で見積もる理由 • 例えば、このビルの高さを見積 もってほしいと言われた場合、ど うするか? ✔ 過去に見たことがあるビルの高さか ら、当てずっぽうで言ってみる? ✔ 16階建てだから、1階あたりの高

    さがわかればわかるかも? ✔ 隣のビルの高さがわかったら、ざっく り2倍くらいかも? • 機能の見積もこれと同じで、基準 となる規模見積に対して比べるこ とで相対的に見積もる ► 基準値を5ポイントとする例 ► 同じくらいの規模:5ポイント ► ちょっと大きい:8ポイント ► ちょっと小さい:3ポイント ► 2倍くらい:10ポイント ? 機能A 機能B 機能C 5pt 8pt 3pt
  6. 規模から期間への変換はどうする? • 以下のような手順を行うことで、ポイントなどの規模から期間へ変 換できる 1. 1スプリント(1週間など特定の期間)で何ポイントのPBL項目を消化 できるか測定する ► 例えば、1スプリントで10ポイントを消化できたとする 2.

    PBLのすべての項目の合計ポイント数を、1スプリントで消化できた ポイント数で割る ► 例えば、PBLの全ての項目の合計ポイント数が100ポイントだとしたら、1 スプリントで10ポイントのPBL項目を消化できるので、10スプリント (10週間)でPBLの全ての機能が実現できる見込みとなる • このようにPBLの総規模(総ポイント数)から「限られた期間でど こまで機能を実現できそうか」を予測できる ► この情報を使って、プロジェクトの着地点(期間内でどの機能まで実 現できそうか)をお客様の代表(プロダクトオーナー)と会話するこ とができる ► 開発チームの本当の開発スピードを使って測定した結果なので、説得 力がある ✔ お客様や自社の上層部からの「もっと早くできるはずでは?」というプ レッシャーに現実的に回答できる
  7. SBLのタスクには理想時間を設定する • PBLの機能をSBLでタスクレ ベルに分解する ✔ このタイミングで、担当す る人ごとに理想時間を設定 する ✔ ただし、理想時間は機能の

    規模見積には使用しない点 に注意 • SBLで設定したタスクの理想 時間は1スプリント内の進捗 管理でのみ使用する ✔ 未着手・着手・レビュー中 ・完了で振り分けて、状況 を見える化する ✔ 1スプリントの最後に、お 客様に対して機能をレ ビューできそうか把握する 機能A タスクA-1 タスクA-1 初級者 熟練者 5pt 3日 5日 対象の機能の見積ポイントや、タスクの作業規模は 同じだが、習熟度によって理想時間が異なる。 しかし、チーム全体で「1スプリントあたり10ポイ ント消化できる」実績がわかっていれば、PBLで行 う機能の規模見積(ポイント見積)ではチーム全体 として見積もるので個々の習熟度の違いは無視でき る。 PBLの見積は、個人のパフォーマンスではなく、 チームのパフォーマンスで見積もるのがポイント
  8. 言葉の定義を整理 今回の勉強会で登場した新しい言葉について定義を整理します。 PBLやプロダクトオーナーなど、これまであまり馴染みのない言葉も多いので、慣れ るまで適宜日本語の言葉に置き換えてもよい。(言葉の正確性よりも目的を達成でき ることが大事) • PBL(Product Back Log) − 優先順に並んだ機能の一覧 ✔

    プロダクトやシステムの機能を優先順で並べた一覧 ✔ 規模で見積もる • SBL(Sprint Back Log) − xサイクル目のタスク一覧 ✔ スプリント内で実施するタスクの一覧 ✔ PBL項目から作業分解してタスクを洗い出す ✔ 各タスクに理想時間を設定する • プロダクトオーナー − お客様の代表 ✔ お客様の代表者 ✔ 機能の定義や優先順の決定に責任を持つ • 開発チーム ✔ 開発者の集まり ✔ 機能の相対見積もりやタスクの見積もりに責任を持つ • スプリント − 開発サイクル ✔ 1週間など、区切られた期間