(我确信这种分析方法没有太大的意义,因为缺乏对底层原因的了解. 而且Developer在选择common Cause的时候完全可能没有合适的而任选一个.经常看到的一个例子是缺乏UT. 这个就不一定是真正的原因,事实往往是做了UT却没有发现出Bug.这种分析方法是典型的不深入实际的浮夸作风, 依赖统计的数据而没有看到统计数据事实上可能存在问题. 这样的工作肯定效率不高. )

下面是我的一些思考。
分析的基础应该是Bug，而不是commonCause。直接从CommonCause开始分析，至少可能遗漏一下重要有价值的发现。
有些Bug是有可能避免的。而有些bug可以说没有什么好的对策。我们应该集中分析有可能避免的Bug。
至于如何分析具体Bug是否能避免，首先应该是造成该Bug的Developer自己分析，让大家知道Bug是如何形成的，然后由大家集体决定。（这样做的风险是大家能否接受。）
其次根据Bug引入的时间，和最终测试出的时间，总结有没有可以改进的大方。
能够由developer改进而消除的Bug。是最有希望避免再次发生的。
比如，有些bug是打字错误造成界面上显示的内容有瑕疵，一个可行的改进是每次都从需求文档拷贝。
注意必须要有措施能保证该经验能被所有Developer知道。
另一个例子是，我有一次，是的，我有一次再修正bug是没有清除彻底。在总结的时候我掌握了全局查找、替换的技巧。有效地避免了类似的错误再次发生。

并非所有错误都能由devloper来消除，有一些只能由Tester来消除。比如，一般来说，Tester总是比Developer对界面敏感，更能发现界面bug。
我觉得随着单元测试的进步，现在对Developer的测试水平的要求也提高了。这也许不尽合理。developer对实现花了很多精力，他不可能在测试上达到同样的水准。