您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 信息化管理 > 产品质量的基石__微软Bug管理
微软项目管理›团队组织›项目流程管理›缺陷管理开发管理的切面透视–微软的一天如何提高软件开发管理的质量常见问题›没有人愿意做测试›觉得养不起那么多测试人员›开发人员不遵循规范,随心所欲›项目经理事必躬亲,分身乏术项目经理开发测试发布经理用户教育产品经理Communication角色项目经理开发测试产品经理用户教育发布经理职责编写功能规范,协调各角色关系按照功能规范编写软件质量控制客户联系的桥梁,进行需求分析让产品容易使用保证产品顺利发布常见问题›无法决定项目所需的资源(人力和预算)›无法决定项目的进度表›无法控制外包项目的进度和质量时间功能里程碑1里程碑2里程碑3每个里程碑完成部分功能便于团队集中力量完成一个又一个功能提供多个机会以适应需求的更改1.达成共识2.完成项目计划3.完成功能4.发布步骤一:达成共识›基本完成需求调研和分析(产品经理负责)›确定大方向和长中短期目标›所有角色都参与讨论并真正认同结论›产生的文档:常见用户情景:覆盖80%以上功能Vision:言简意赅地说明大方向,并有激励团队的作用步骤二:完成项目计划›编写详细的功能规范(项目经理负责)›在编程前想清楚所有功能流程,并引导用户明确需求›所有角色都参与审阅功能规范›制订开发计划和进度表(开发团队)›制订测试计划和进度表(测试团队)›分配资源(人力和预算)›形成项目综合计划和综合进度表›产生的文档:功能规范,开发计划,测试计划(用例),项目综合计划开发进度表,测试进度表,综合进度表步骤三:完成功能›开发人员分别完成自己的功能›使用版本控制工具使程序员及时checkout和checkin,避免积累大量代码及时进行模块间的整合,及时发现问题(dailybuild)›对每一项可测试的功能进行测试,无需等待›使用测试用例工具,对功能进行完整和重复的检验›使用BMS进行缺陷跟踪记录所有程序问题实现解决Bug的自动流程›按照综合进度表不断检查进度›使用的工具:版本控制工具VSS缺陷跟踪工具Raid/BMS测试用例管理工具步骤四:稳定与发布›测试组全面地测试功能,包括性能和稳定性›开发组全力配合解决Bug›使用BMS进行监测质量情况预测发布日期›专家会诊机制:决定Bug的优先度决定哪些Bug可以等到下个里程碑或版本中解决决定由谁解决某个Bug›使用的工具:版本控制工具VSS缺陷跟踪工具BMS测试用例管理工具微软的开发管理经验:100%以Bug为核心测试人员Raid/BMS项目经理其他人员构造员开发人员VSS构造服务器发布服务器Exchange100%由缺陷跟踪工具驱动功能未实现,和规格说明书不一致不能工作:死机,没反应不兼容边界条件界面、消息、提示不够准确,不友好把尚未完成的工作也作为一个Bug文档与帮助信息中的缺陷也是Bug完整的Bug数据库整个产品组的中央记录和控制强大的查询功能,有效地跟踪项目的状态所有的记录无法删除,对于每个记录只能一直添加内容丰富的报表功能,为产品发布提供判断标准状态负责人问题种类严重级优先级修改时间登记时间缺陷来源解决方案运行环境缺陷关联附件附图缺陷细节1.死机,数据丢失,主要功能组完全丧失,系统悬挂2.主要功能丧失,导致严重的问题,或致命的错误声明3.次要功能丧失,不太严重,如提示信息不太准确4.微小的问题,对功能几乎没有影响,产品及属性仍可使用.如有个错别字代码完成前:很少代码完成后:增长很快接近Beta:下降接近RC:奔向零产品质量和里程碑的信号›每天新建的Bug与修正的Bug相比较.›Active状态Bug的总数让我们看看项目中每个角色的一天是如何度过的›开发›测试›项目经理注:里程碑的每个阶段每个角色的工作有不同侧重点,我们以“完成功能”阶段为例答案:半夜为什么?答案:半夜因为DailyBuild是所有工作的核心,而且是在半夜自动启动。•你知道自己所用Windows的版本号吗?•DailyBuild的意义:–模块得以及时整合–要求程序员及时把最新代码放入代码库•用脚本语言和编译/链接工具实现•BVT–BuildVerificationTest–对Build进行验证•BlockingBug–让Build无法完成的问题–BVT中发现的问题答案:因为自己昨天的代码check-in,造成BlockingBug.为什么?•答案:因为自己昨天的代码check-in,造成BlockingBug.因为每天的Build是所有人当天工作的基础:程序员需要Build验证与其他模块的接口测试需要Build发现新Bug,并验证新Build中已解决的Bug解决问题,并对今天的Build打Patch。经历对Build的提心吊胆和争分夺秒之后,第一件事做什么?经历对Build的提心吊胆和争分夺秒之后,第一件事做什么?答案:打开缺陷跟踪工具,查看指定给自己的Bug,解决高优先度的Bug。因为质量重于新功能。•从版本控制工具中Checkout代码•修改代码(解决Bug或实现新功能)•取得版本工具中最新变化,在本机Build和单元测试•请开发组同事作CodeReview•Checkin代码Raid/BMS测试人员邮件系统源代码服务器发布服务器专家会诊开发人员Builder1.拿到新的版本2.记录bug3.得到新的bug4.解决Bug5.Checkin请求6.批准7.Checkin8.拿到最新源代码9.编译10.验证bug解决并关闭测试人员第一件事做什么?答案:打开Raid/BMS,查看指定给自己的Bug,验证已解决的Bug。•根据测试用例检验今天的Build•在Raid/BMS中记录新发现的Bug•参加者:项目经理和开发组长、测试组长•通过Raid/BMS评估每个未解决的Bug–决定Bug优先度–可否等到下个里程碑或版本解决?–谁来解决•预测项目实际进度和发布时间缺陷走势图构造:dailybuild开发:解决blockingbugs,实现功能,check-out,codereview,check-in测试:BVT,使用测试用例进行测试项目经理/组长:专家会诊以前解决过的问题发布时又出现了,需要返工无法预估发布时间–过早发布,带来质量和维护问题测试发现的问题被忘却或不了了之无法衡量测试员和开发员的工作程序中的问题往往在发布后才发现文档与程序脱节,文档成为程序结果的描述项目组把写文档看成负担开发人员各自为战,进行整合时发现模块衔接中的严重问题–需要作大的改动没有保管好公司以往的版本和代码,无法满足用户对旧版本的更改要求开发人员离职对项目带来很大冲击,没有人知道代码在哪,或无法读懂1.使用Raid/BMS,将流程管理自动化2.使用测试用例管理工具3.使用文档管理工具4.使用版本控制工具,进行DailyBuild5.建立代码标准6.建立CodeReview机制7.建立专家会诊机制8.建立团队沟通机制9.根据需要调整团队结构Q&A
本文标题:产品质量的基石__微软Bug管理
链接地址:https://www.777doc.com/doc-480351 .html