Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
見積もり/agile-estimation
Search
Atsushi Harada
November 07, 2019
Technology
0
72k
見積もり/agile-estimation
Atsushi Harada
November 07, 2019
Tweet
Share
More Decks by Atsushi Harada
See All by Atsushi Harada
モジャイリーンな事業開発/mojilean-business-development
harada4atsushi
0
390
スクラムとモジャイル/scrum-and-mojile
harada4atsushi
0
7.9k
リーン・スタートアップとMVP/lean-startup-mvp
harada4atsushi
0
26k
リーンキャンバスの作り方/how-to-make-lean-canvas
harada4atsushi
0
9.1k
振り返り/agile-looking-back
harada4atsushi
0
21k
インセプションデッキの作り方/how-to-make-inception-deck
harada4atsushi
0
9.8k
もふもふなエンジニアの心得/mofmofinc-engineer-knowledge
harada4atsushi
0
7.6k
mofmof inc. 会社紹介 for 採用/mofmofinc-informatioin-for-recruiting
harada4atsushi
3
55k
Other Decks in Technology
See All in Technology
Access-what? why and how, A11Y for All - Nordic.js 2025
gdomiciano
1
110
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
3
270
Findy Team+のSOC2取得までの道のり
rvirus0817
0
330
10年の共創が示す、これからの開発者と企業の関係 ~ Crossroad
soracom
PRO
1
170
GA technologiesでのAI-Readyの取り組み@DataOps Night
yuto16
0
270
多野優介
tanoyusuke
1
420
BirdCLEF+2025 Noir 5位解法紹介
myso
0
190
Goにおける 生成AIによるコード生成の ベンチマーク評価入門
daisuketakeda
2
100
「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ:検査・適応で未来を開発 / AI-driven product owner. scrummat2025
yosuke_nagai
4
580
AWSにおけるTrend Vision Oneの効果について
shimak
0
120
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
77k
職種別ミートアップで社内から盛り上げる アウトプット文化の醸成と関係強化/ #DevRelKaigi
nishiuma
2
130
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
49
14k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
How GitHub (no longer) Works
holman
315
140k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Building Adaptive Systems
keathley
43
2.8k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Transcript
ݟੵΓ mofmof inc.
ソフトウェアの納期⾒積もりは、 星占いレベルのものであると思う 引⽤:メソッド屋のブログ http://simplearchitect.hatenablog.com/entry/2016/07/07/080250
• ਫ਼ • ݟੵΓ • ෆ࣮֬ੑ
不確実性コーン
時間をかければ ⾒積もり精度は上がる
⾒積もり=設計
⾒積もり⼿法の歴史 • LOC • FP • COCOMO • CoBRA •
KKD
⾒積もり精度の推移 精度 コスト(時間) '1 ϓϥϯχϯά ϙʔΧʔ ,,%
⾒積もりのタイミング ΩοΫΦϑ ϦϦʔε εϓϦϯτ ϓϩδΣΫτ
اը࣌ ΩοΫΦϑ࣌ εϓϦϯτܭը࣌
プランニングポーカー
͜ͷػೳɺ͘Β͍ͰͰ͖ΔΑͶʁ 営業
͍͍͘Β͍͔͔ΔΑ 営業 ベテラン エンジニア
͘Β͍ඞཁͩͱࢥ͍·͢ʂ 営業 ベテラン エンジニア 若⼿ エンジニア
ҰମԿΛ৴͡ Ε͍͍ʁ
• ૬ରݟੵΓ • νʔϜݟੵΓ • ετʔϦʔϙΠϯτ
͜ͷڇͷମॏԿΩϩ ͜ͷڇͷମॏԿΩϩ
͜ͷڇΩϩʂ
なぜ相対⾒積もりか • 相対的な基準があれば、簡単に⾒積もり の精度を上げることが出来る • ⼯数で絶対⾒積もりをすると、個⼈のス キルに依存した⾒積もりになってしまう • 実際には⾒積もる⼈と担当する⼈が違う ことも多いので、⾒積もりミスにつなが
る
ストーリーポイント • 個⼈のスキルに依存させないため、相対的な ⾒積もり尺度を「ポイント」で表現する • ストーリーポイント = 時間(⼯数)ではない • 基準となるユーザーストーリーと⽐較して、
どの程度複雑か、曖昧であるか、などを評価 して⾒積もる
基準ポイントの決め⽅ • 既に出ているストーリーの中から、全員 が理解できそうな⼀つのストーリーを決 めて、1ポイント or 3ポイントとする • 基準としてふさわしいものがなければ、 全員が認識を⼀致させる実装のイメージ
を使⽤しても良い
フィボナッチ数列(もどき)を使う • 0,1,2,3,5,8,13,20を使うことが多い • 規模が⼤きくなるほど正確に⾒積もれな くなる性質と、フィボナッチ数列が相性 が良い • ⼤きい単位の数字は細かく考えても精度 が上がることはないので考えるのはムダ
• ⼩さい単位に分割して⾒積もり可能にする
͜ͷௗΩϩʂ ͜ͷͷମॏʁ
• େ͖͍ετʔϦʔׂ • ཧɿʙϙΠϯτ • ϙΠϯτʙநߴΊ
議論をする • チーム全体で⾒積もる • ⾒積もりの差異が出た場合、何か考慮漏れ、ある いは考慮しすぎである可能性がある • ズレ幅が最も⼤きい⼈同⼠で、その⾒積もりをし た理由を説明し、その情報を追加した上で再度⾒ 積もる
• 議論の最中にカードを出し直してもOK • 議論が終わってから全員でもう⼀度⾒積もりしな おすでもOK
実際にやってみよう
ςʔϚ தͷՆٳΈͷ॓
10ઌੜ ߨࢣ ϝϯόʔੜె Έͳ͞Μ
お客様の中に経験者いますか?
流れ 1. 基準の1ptとなるストーリーを決める 2. ストーリーを⼀つずつ読み、以下繰り返し 1. ストーリーの単位が⼤きすぎる場合は分割する 2. 必要であればPOに確認して、ストーリーを詳細 化する
3. 全員で専⽤カードを使って⾒積もりする 4. ⾒積もり差異について議論する 5. チームで⼀つの⾒積もりを合意して決める
ポーカーのやり⽅ • ストーリーの詳細を読んだら基準ポイン トに対してどの程度のボリュームか⾒積 もり、カードを裏返しで出す • 全員がカードを出したら⼀⻫に表にする
Appendix
ग़དྷΔͬͯ ݴͬͨΑͳʁ
τϨʔυΦϑͷؔΛ ߹ҙ͓ͯ͜͠͏
参考:プランニングポーカー https://speakerdeck.com/ryuzee/planning_poker_guide
参考 https://www.slideshare.net/taguchimasahiro/ss-44419906