10-1 微软缺陷管理.ppt

微软缺陷管理与bugfree 三权分立制 PM来定义需求、书写出来每个功能特性 (Feature)的设计文档(Spec) Dev写代码来实现这个Spec Tester来测试 Dev做出来的东西是否符合 PM定义的 Spec，三个角色之间并无必然的上下级关系，只是分工合作完成某个功能(Feature)。我将之形容为“三权分立”，三者之间有效合作并制衡。 三权分立制 PM将写好的需求设计文档(Spec)保存到 SharePoint文档库中，所有相关的人都可以随时查看；Dev用Source Depot （功能类似CVS的微软内部源代码管理工具）来保存源程序；Tester把发现的Bug记录到Raid中以有效跟踪这个问题的处理流程。 100%由缺陷跟踪工具驱动 RAID/BMS的基本功能 完整的Bug数据库 整个产品组的中央记录和控制 强大的查询功能，有效地跟踪项目的状态 所有的记录无法删除，对于每个记录只能一直添加内容 丰富的报表功能，为产品发布提供判断标准 RAID/BMS的基本功能 Raid从一开始就支持多用户 一个团队中的所有人都可以创建、指派Bug，或者改变Bug状态 用户可以非常自由的去定制Raid 基于SQL，很多有用的报告可以被生成出来 管理层需要所有Bug都在Raid中被有效的跟踪处理 RAID/BMS Raid的价值在于它密切跟踪当前产品的实际Bug状态，使项目组中的成员非常有效的协调他们的工作。大家都很聪明，如果一个工具是容易理解的、而且管理层提供其使用指南（比如Bug怎么被指派和解决），那么简单的工具也能提供巨大的价值。 bug管理体制 在整个产品的研发过程中，特别是在测试产品、修复Bug的中后期，团队中所有人都生活在Raid中： -?测试人员（Tester）只要发现问题就立即新建一个Bug予以跟踪并指派给相关的开发小组长（Dev Lead） -?开发小组长会判断这个Bug属于某个特定的开发人员（Dev）并指派给他处理 -? 开发人员会根据Bug的详细描述信息找到问题所在，修改程序解决这个Bug并把Bug返回给当初的测试人员；或者有争议的时候，把Bug指派给这个Feature的定义者PM，要求一个澄清说明 -? 测试人员在看到某个Bug被解决后，就去验证这个Bug是否真的不存在了，根据最初的发现步骤去证实问题真的解决了就关闭这个Bug；若还能重现，或者不同意开发人员的解法，可以激活这个Bug，返还给当初的开发人员做进一步调查处理 bug管理体制 每月、每周甚至每天，参与这个产品研发的人都收到一封当前Bug状态的Email：每个人都上有多少Bug，Dev、PM、Tester头上Bug数最多的前5名都是谁，哪个子产品、子模块中的问题还是处于上升阶段，整个Bug的趋势怎么样等等。这是最详尽的产品状况“内参”，暴露在团队中每个成员的面前，一览无遗。只要你的名字被列在Email中，你就非常紧张，因为你脑袋上的Bug比较多、影响整个产品的质量。这些该死的Bug等待着你去快速处理，尽快把自己从排行榜上去掉。每解掉一个Bug，或者把Bug转给另外的人去处理，就会舒一口气，因为头上又少了一个；某一天你头上的Bug数降为0了，心里就会非常高兴 bug管理体制 -当测试人员和开发人员无法达成一致意见的时候，由对应的PM出面做协调，判断这个Bug的严重程度、对用户可能的影响，根据产品的进度和项目资源做出评估，是否真的需要修理掉这个问题 -管理团队利用Raid来跟踪整个进度：单个人的工作、小组的进度，整个产品研发进度 Bug 及常见类型 功能未实现，和规格说明书不一致 不能工作：死机，没反应 不兼容 边界条件 界面、消息、提示不够准确，不友好 把尚未完成的工作也作为一个Bug 文档与帮助信息中的缺陷也是Bug RMS缺陷管理系统 Bug 记录中的有效信息 状态 负责人 问题种类 严重级 优先级 修改时间 登记时间 缺陷来源 解决方案 运行环境 缺陷关联 附件 附图 缺陷细节 Bug 的严重程度 死机，数据丢失，主要功能组完全丧失，系统悬挂 主要功能丧失，导致严重的问题，或致命的错误声明 次要功能丧失， 不太严重，如提示信息不太准确 微小的问题，对功能几乎没有影响，产品及属性仍可使用. 如有个错别字 激活的Bug数量的趋势 代码完成前：很少 代码完成后：增长很快 接近Beta: 下降 接近RC: 奔向零 产品质量和里程碑的信号 每天新建的Bug 与 修正的 Bug 相比较 Active 状态 Bug 的总数 激活的Bug数量的趋势 微软的一天 微软的一天从几点开始？ 答案：半夜 为什么？ 因为Daily Build是所有工作的核心，而且是在半夜自动启动。 微软的一天 每日构造Daily Build 你知