微软的Bug 管理指导原则

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