ݟੵΓmofmof inc.
View Slide
ソフトウェアの納期⾒積もりは、星占いレベルのものであると思う引⽤：メソッド屋のブログ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
harada4atsushi
yokawasa
shunsukeono_am
yoshiitaka
knsg16
pkshadeck
mosa_siru
leveragestech
shibuiwilliam
dahatake
segavvy
nishiuma
sinsoku
samlambert
quramy
colly
kevinliebholz
wjessup
shlominoach
danielanewman
mongodb
jcasabona
brianwarren
vanstee
chriscoyier