見積もり/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