刘振飞：
微软项目经理
开源缺陷管理工具bugfree创始人
------------------------------------------------------------------------
[名人观点]:
其实前两篇文章已经陆续谈过微软的 Bug管理指导原则了，这里系统的总结一下：
1. 管理层要求所有的 Bug 都要通过 Raid（Product Studio）来跟踪处理。这个看起来很简
单的Bug管理工具是每个员工和其他同事有效协作的重要保证
2. 每个产品都细分模块（Area，SubArea） ，每个模块都有明确的需求定义者（PM） 、开发
工程师（Dev）和测试工程师（Tester）这三个角色。一个问题出现了，一定会落实到
某个人的头上去跟踪处理，绝不能出现 无主的 Bug
3. PM 负责书写的 Spec 是这个功能特征（Feature）的合同 ，以此 Spec 来指导开发和
测试。当Dev和Tester就某个Bug发生争执的时候，PM负责给出一个明确的说明
4. 测试不仅仅是Tester的事情，尽管那是他们的专职工作。研发团队中的所有人每发现产
品的问题时候，都有义务把这个问题告知负责这个模块的测试人员去记录跟踪这个
Bug，或者干脆自己新建一个 Bug 来跟踪
5. 你可以创建一个 Bug 指派给自己，以跟踪某件事的处理。比如开发人员把源代码中的
某处问题用 Bug 记录下来，以后抽出时间来进行处理
6. 团队中的所有人都可以创建、指派和更改 Bug 的状态3
7. 当你创建一个 Bug 的时候，描述一定要足够详细，让下面处理 Bug 的人和其他关心这
个 Bug 的同事能够通过 Bug 描述准确的重现这个问题，而不是猜测某些步骤或者跑过
来当面问你
8. 通常一个Bug的处理过程是这样的：
1). Tester 发现一个问题，到 Raid 中创建一个 Bug，描述这个 Bug 的详细信息，比如
重现步骤（Repro Step） 、错误结果（Result） 、期望的改动（Expect） 、运行版本等；
然后把这个 Bug 指派给负责该模块的 Dev Lead
2). Dev Lead 判断后把这个 Bug 指派给某个特定的Dev
3). Dev处理掉这个Bug并返还给原 Tester，或者请求PM给出一个澄清说明
9. 管理层通过 Raid来跟踪整体进度，以及每个员工、团队在其中的贡献
10. 有专人定期给相关同事发出 Bug 的状态报告
11. 每个人都可以方便的自助查询 Bug 的分布处理情况。Bug 管理系统对所有的团队成员
都是毫无保留的敞开大门 （除了你不能删除 Bug， 另外所有的操作都被忠实的纪录下来）
12. 随着时间的推移，管理层要逐步给出明确的 Bug 解决指导方针：哪些 Bug 是可以不理
睬的（Won’t Fix） ，哪些是可以推迟到下个版本处理（Postponed） 。比如在最终 Build
到来前的几周，也许非常严重的 Bug，像数据丢失、程序崩溃之类的也都要推迟到下个
版本再解决了。
13. 当一线员工出现争执、无法达成一致意见的时候（尽管这种情况不多见） ，管理层要快
速给出处理意见
等等。