Bug管理的经验和实践

微软的研发管理可以从以下几个方面描述：
（1）研发人员分工明确。主要的三个角色：PM (Program Manager)、Dev(Developer)、Tester三者分工明确、接口清晰，PM 来定义需求、书写出来每个功能特性(Feature)的设计文档(Spec)，Dev 写代码来实现这个Spec，Tester 来测试Dev 做出来的东西是否符合PM 定义的Spec，三个角色之间并无必然的上下级关系，只是分工合作完成某个功能(Feature)。形容为“三权分立”，三者之间有效合作并制衡。国内企业好像还没有PM 这个角色，而测试人员又往往成为开发人员的附庸，一个Bug 是否要被解决全由开发人员说了算，这很糟糕，就像政治上一个权力没有被有效的制衡一样，一定会产生各种问题。（2）研发工具很配套。PM 将写好的需求设计文档(Spec)保存到SharePoint 文档库中，所有相关的人都可以随时查看；Dev 用Source Depot （功能类似CVS 的微软内部源代码管理工具）来保存源程序；Tester 把发现的Bug 记录到Raid 中以有效跟踪这个问题的处理流程.（3）分阶段的研发流程。和任何软件公司一样，微软的研发无非也分为规划、开发、测试、发布等几个阶段。但是微软的研发流程不走形式，可以统一产品组所有员工的思想，并且能够有效地控制住进度。做完一个版本后，还会让所有员工匿名投票，找出这次研发过程中出现的各种问题以便在下个版本中解决(此过程称为Postmortem，挺吓人的一个词)。微软的bug 管理体制:在整个产品的研发过程中，特别是在测试产品、修复Bug 的中后期，团队中所有
人都生活在Raid 中：
- 测试人员（Tester）只要发现问题就立即新建一个Bug 予以跟踪并指派给相关的开发小组长（Dev Lead）
- 开发小组长会判断这个Bug 属于某个特定的开发人员（Dev）并指派给他处理
- 开发人员会根据Bug 的详细描述信息找到问题所在，修改程序解决这个Bug 并把Bug返回给当初的测试人员；或者有争议的时候，把Bug 指派给这个Feature 的定义者PM，要求一个澄清说明
- 测试人员在看到某个Bug 被解决后，就去验证这个Bug 是否真的不存在了，根据最初的发现步骤去证实问题真的解决了就关闭这个Bug；若还能重现，或者不同意开发人员的解法，可以激活这个Bug，返还给当初的开发人员做进一步调查处理
- 当测试人员和开发人员无法达成一致意见的时候，由对应的PM 出面做协调，判断这个Bug 的严重程度、对用户可能的影响，根据产品的进度和项目资源做出评估，是否真的需要修理掉这个问题
- 管理团队利用Raid 来跟踪整个进度：单个人的工作、小组的进度，整个产品研发进度