金曜にバグを発生させるコミットが多い

昨年7月のSEA関西プロセス分科会で教えてもらったソフトウェア工学の論文「When Do Changes Induce Fixes? (On Fridays.)」をもう一度読み直している。

プログラマの思索: ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する

論文は、下記で公開されている。

【PDF1】
When Do Changes Induce Fixes? (On Fridays.)

【SlideShare】

When do changes induce fixes?

View more presentations from Thomas Zimmermann.

【PDF2】
Don’t Program on Fridays! How to Locate Fix-Inducing Changes

上記の論文の主張は「ApacheやEcipse(又はMozilla)プロジェクトでは、金曜にバグを発生させるコミットが多く、金曜はバグ修正のリスクが高い。金曜はプログラムを書くな！」というもの。
SlideShareでは、「Fridays are Risky, Tuesdays are not ;-) 」というタイトルもある。

すごく面白い。

今の自分のプロジェクトで、SVNリポジトリやTestLinkでメトリクスを出力しているのだが、上記の論文の主張が当てはまるような気がしている。

少なくとも、SVNコミットのピークが金曜の場合、そのプロジェクトで開発しているシステムの品質は経験的に良くない。
TestLinkに溜め込んだテスト実績から曜日別のテスト結果を出力すると、品質に問題があったテスト計画では、金曜にテスト実施数や失敗テストケース数のピークが来ているようだ。

理由を考えると、色んな諸条件でSW開発の生産性が低いため、学生症候群のように、週後半に作業のピークが来るように経験的に感じる。

こういうソフトウェア工学の知識を持っているだけでも、SW開発のリスク管理は大きく異なる。
こういう経験値をSW開発のプロジェクト管理、リスク管理に応用できないか？

そして、チケット駆動開発へ上記のようにSW工学の基盤を理論的に付与できないか？