微软的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，像数据丢失、程序崩溃之类的也都要推迟到下个版本再解决了。
当一线员工出现争执、无法达成一致意见的时候（尽管这种情况不多见），管理层要快速给出处理意见。
