Slide 1

Slide 1 text

©MIXI 開発規模とバグ数の話 株式会社MIXI ソーシャルベッティング事業本部 村⽥雄⼈

Slide 2

Slide 2 text

2 ©MIXI ● 経 歴: ○ 2011/04〜2015/08 ■ 営業職や⼈事職 ○ 2015/09~2022/03 ■ 第三者検証会社にてQA ○ 2022/04〜 ■ 株式会社MIXIにてQA ● 趣 味:筋トレ ● 今年の⽬標:英語の勉強‧JSTQB ALTA取得(できれば) ⾃⼰紹介

Slide 3

Slide 3 text

3 ©MIXI PJ紹介 ● 体 制:スクラム開発(に近い) ● PJ⼈数:約60名 ● 1スプリント:2週間 ● story pt(以下:pt):各職掌の代表者によるプランニングポーカーにて算出 (※各代表者が提⽰した数字の平均値をptとする) ● QAチームにて、各スプリントで検出したバグ数を計測している

Slide 4

Slide 4 text

4 ©MIXI 開発規模とバグ数の話 あるsprintの検出バグ数を計測していた時のこと

Slide 5

Slide 5 text

5 ©MIXI いつものsprintよりバグが少ない気がする 開発規模とバグ数の話

Slide 6

Slide 6 text

6 ©MIXI 消化pt数が近い過去のsprintと⽐較してみると 検出バグ数 消化pt 実装story数 最⼤story pt sprint43 sprint46 sprint47 sprint49 27 20 73 8 59 56 56 57 11 12 11 16 32 35 22 8 開発規模とバグ数の話

Slide 7

Slide 7 text

7 ©MIXI 理由を深掘りしてみると 検出バグ数 消化pt 実装story数 最⼤story pt sprint43 sprint46 sprint47 sprint49 27 20 73 8 59 56 56 57 11 12 11 16 32 35 22 8 小規模storyを 数多く 1storyの規模が 大きい 開発規模とバグ数の話

Slide 8

Slide 8 text

8 ©MIXI storyの⼤きさとバグ数に関係性があるかもしれない 開発規模とバグ数の話

Slide 9

Slide 9 text

9 ©MIXI という訳で、story別に検出バグ数を取れるように仕組みを変更 開発規模とバグ数の話

Slide 10

Slide 10 text

10 ©MIXI story 別にバグ数を計測し、ptレンジ別にその平均を⾒てみると 対象期間:sprint55(2023/06/26開始)〜sprint65(2023/11/27開始) 検出バグ数平均(件) 実装story数 story pt 1~10 11~20 21~35 1.06 32.4 32.5 94 5 2 開発規模とバグ数の話

Slide 11

Slide 11 text

11 ©MIXI 検出バグ数平均(件) 実装story数 story pt 1~10 11~20 21~35 1.06 32.4 32.5 94 5 2 10pt以下のstoryでは バグが1件/story程度に story 別にバグ数を計測し、ptレンジ別にその平均を⾒てみると 対象期間:sprint55(2023/06/26開始)〜sprint65(2023/11/27開始) 開発規模とバグ数の話

Slide 12

Slide 12 text

12 ©MIXI 10 pt以下だと、バグ数が減る!(のかも) 開発規模とバグ数の話

Slide 13

Slide 13 text

13 ©MIXI おわりに ● 10pt以下のストーリーほどバグが少ない傾向にある ○ ただし「テストの量」や「⾒落とし」等の側⾯からも分析は必要 ● タスクを「どう⼩さくするか」が重要 ○ testabilityを意識しないと、結局⼤きな単位でのテストになる可能性が ● 定量化されることでエビデンスができ、PJへの提案がしやすくなる ○ まだ提案できていないですが...

Slide 14

Slide 14 text

©MIXI