見積もり/agile-estimation

Transcript

1. ݟੵ΋Γ mofmof inc.
2. ソフトウェアの納期⾒積もりは、 星占いレベルのものであると思う 引⽤：メソッド屋のブログ http://simplearchitect.hatenablog.com/entry/2016/07/07/080250
3. • ਫ਼౓ • ݟੵ΋Γ޻਺ • ෆ࣮֬ੑ
4. 不確実性コーン
5. 時間をかければ ⾒積もり精度は上がる
6. ⾒積もり＝設計
7. ⾒積もり⼿法の歴史 • LOC • FP • COCOMO • CoBRA • KKD
8. ⾒積もり精度の推移 精度 コスト(時間) '1 ϓϥϯχϯά ϙʔΧʔ ,,%
9. ⾒積もりのタイミング ΩοΫΦϑ ϦϦʔε εϓϦϯτ ϓϩδΣΫτ
10.  اը࣌  ΩοΫΦϑ࣌  εϓϦϯτܭը࣌
11. プランニングポーカー
12. ͜ͷػೳɺ೔͘Β͍ͰͰ͖ΔΑͶʁ 営業
13. ͍΍͍΍೔͘Β͍͔͔ΔΑ 営業 ベテラン エンジニア
14. ೔͘Β͍ඞཁͩͱࢥ͍·͢ʂ 営業 ベテラン エンジニア 若⼿ エンジニア
15. ҰମԿΛ৴͡ Ε͹͍͍ʁ
16. • ૬ରݟੵ΋Γ • νʔϜݟੵ΋Γ • ετʔϦʔϙΠϯτ
17. ͜ͷڇͷମॏ͸ԿΩϩ ͜ͷڇͷମॏ͸ԿΩϩ
18. ͜ͷڇ͸Ωϩʂ
19. なぜ相対⾒積もりか • 相対的な基準があれば、簡単に⾒積もり の精度を上げることが出来る • ⼯数で絶対⾒積もりをすると、個⼈のス キルに依存した⾒積もりになってしまう • 実際には⾒積もる⼈と担当する⼈が違う ことも多いので、⾒積もりミスにつなが る
20. ストーリーポイント • 個⼈のスキルに依存させないため、相対的な ⾒積もり尺度を「ポイント」で表現する • ストーリーポイント = 時間(⼯数)ではない • 基準となるユーザーストーリーと⽐較して、 どの程度複雑か、曖昧であるか、などを評価 して⾒積もる
21. 基準ポイントの決め⽅ • 既に出ているストーリーの中から、全員 が理解できそうな⼀つのストーリーを決 めて、1ポイント or 3ポイントとする • 基準としてふさわしいものがなければ、 全員が認識を⼀致させる実装のイメージ を使⽤しても良い
22. フィボナッチ数列(もどき)を使う • 0,1,2,3,5,8,13,20を使うことが多い • 規模が⼤きくなるほど正確に⾒積もれな くなる性質と、フィボナッチ数列が相性 が良い • ⼤きい単位の数字は細かく考えても精度 が上がることはないので考えるのはムダ • ⼩さい単位に分割して⾒積もり可能にする
23. ͜ͷௗ͸Ωϩʂ ͜ͷ৅ͷମॏ͸ʁ
24. • େ͖͍ετʔϦʔ͸෼ׂ • ཧ૝ɿʙϙΠϯτ • ϙΠϯτʙ͸ந৅౓ߴΊ
25. 議論をする • チーム全体で⾒積もる • ⾒積もりの差異が出た場合、何か考慮漏れ、ある いは考慮しすぎである可能性がある • ズレ幅が最も⼤きい⼈同⼠で、その⾒積もりをし た理由を説明し、その情報を追加した上で再度⾒ 積もる • 議論の最中にカードを出し直してもOK • 議論が終わってから全員でもう⼀度⾒積もりしな おすでもOK
26. 実際にやってみよう
27. ςʔϚ தͷՆٳΈͷ॓୊
28. 10
    ઌੜ ߨࢣ ϝϯόʔ
    ੜె Έͳ͞Μ
29. お客様の中に経験者いますか？
30. 流れ 1. 基準の1ptとなるストーリーを決める 2. ストーリーを⼀つずつ読み、以下繰り返し 1. ストーリーの単位が⼤きすぎる場合は分割する 2. 必要であればPOに確認して、ストーリーを詳細 化する 3. 全員で専⽤カードを使って⾒積もりする 4. ⾒積もり差異について議論する 5. チームで⼀つの⾒積もりを合意して決める
31. ポーカーのやり⽅ • ストーリーの詳細を読んだら基準ポイン トに対してどの程度のボリュームか⾒積 もり、カードを裏返しで出す • 全員がカードを出したら⼀⻫に表にする
32. Appendix
33. ग़དྷΔͬͯ ݴͬͨΑͳʁ
34. τϨʔυΦϑͷؔ܎Λ ߹ҙ͓ͯ͜͠͏
35. 参考:プランニングポーカー https://speakerdeck.com/ryuzee/planning_poker_guide
36. 参考 https://www.slideshare.net/taguchimasahiro/ss-44419906