Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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