このページは何？
筆者の所属するPJで行っている「バグ分析」の取り組みから見えてきた
開発規模とバグ数に関する、興味深い傾向をお話するページです。
本題に入る前に
まず、所属するPJやQAチームはこんな感じです。
・スクラム（っぽい開発体制）を採用
・2週間で1スプリント
・各職掌の代表者でプランニングポーカーを行い、1ストーリーの大きさをストーリーptとして算出
・1スプリント内のストーリーptの合計を消化ptとして計測
・QAにて検出バグ数を計測
いざ本題
半年ほど前、スプリント49終了後に検出バグ数を計測したところ、
普段よりかなり少ない数で着地していたことがわかりました。
QAチーム内でその理由について考察する中で、ほぼ同じ消化ptだった
過去スプリントと比較したところ、以下のようになっていました。
バグの少なかったスプリント49は実装ストーリー数が多く、最大ストーリーptが少ない。
つまり「小さいタスクを数多く消化していた」ことがわかりました。
逆に、バグが多かった49以外のスプリントは実装ストーリー数が少なく、最大ストーリーptが多い。つまり「1つのタスクが大きかった」とも言えます。
ここまでが約半年前の話です。
あれから半年後...
上述の傾向を受けて、今はストーリーごとのバグ数を算出する仕組みを作り、
ストーリーptとバグ数の相関関係を掘り下げています。
ある程度データもたまってきたので、実際にその数字を分析してみました。
11pt以上、21pt以上のストーリーはサンプル数が少ないため、まだ振れ幅がありそうです。
しかしながら、10pt以下のストーリー全94件の平均バグ数が約1件と、
小さいストーリーほどバグが出づらい傾向にあることがわかり、
筆者のPJでは、10pt以下に抑えて開発するのがベストプラクティスの様です。
ただし、あくまでこれは「バグを出さないための」それであり
MVPやtestabilityを踏まえると、適切な粒度はまた変わってくるのかもしれません。
それはまた別の機会に考察してみたいと思います。
まとめ
品質とは、ともすれば定性的になりがちですが、
体感していたものが定量化されることで、PJに提案する際の
エビデンスとして活用できるデータになったのではないかと思います。
バグの発生要因はストーリーptのみに限らないので、
規模を小さくすればバグが起きないとは一概には言い切れません。
ですが、このデータが1つの参考事例として様々なプロジェクトで活用いただければ幸いです。
～～～2024/01/19追記～～～～～
1/16のjasst nano #32にてLTをしました
https://speakerdeck.com/mixi_engineers/development-scale-and-number-of-bugs