产品质量的基石——微软Bug管理

Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,产品质量的基石微软Bug管理,微软中国高级架构师,1,日程,微软项目管理,团队组织,项目流程管理,缺陷管理,开发管理的切面透视,微软的一天,如何提高软件开发管理的质量,2,团队组织,常见问题,没有人愿意做测试,觉得养不起那么多测试人员,开发人员不遵循规范，随心所欲,项目经理事必躬亲，分身乏术,3,微软团队模型,项目经理,开发,测试,发布经理,用户教育,产品经理,Communication,4,各角色的职责,角色,项目经理,开发,测试,产品经理,用户教育,发布经理,职责,编写功能规范，协调各角色关系,按照功能规范编写软件,质量控制,客户联系的桥梁，进行需求分析,让产品容易使用,保证产品顺利发布,5,项目管理,常见问题,无法决定项目所需的资源（人力和预算）,无法决定项目的进度表,无法控制外包项目的进度和质量,6,微软项目管理,-,多里程碑式流程,时间,功能,里程碑,1,里程碑,2,里程碑,3,7,多里程碑式管理,每个里程碑完成部分功能,便于团队集中力量完成一个又一个功能,提供多个机会以适应需求的更改,8,透视每个里程碑,I,E,N,V,S,O,G,I,N,N,I,P,L,A,N,I,G,N,N,D,E,V,L,O,P,I,G,E,N,S,T,A,B,I,L,Z,N,G,I,I,1.,达成共识,2.,完成项目计划,3.,完成功能,4.,发布,9,如何完成一个里程碑,步骤一： 达成共识,基本完成需求调研和分析 （产品经理负责）,确定大方向和长中短期目标,所有角色都参与讨论并真正认同结论,产生的文档：,常见用户情景：覆盖,80%,以上功能,Vision,：言简意赅地说明大方向，并有激励团队的作用,10,如何完成一个里程碑,步骤二： 完成项目计划,编写详细的功能规范（项目经理负责）,在编程前想清楚所有功能流程，并引导用户明确需求,所有角色都参与审阅功能规范,制订开发计划和进度表（开发团队）,制订测试计划和进度表（测试团队）,分配资源（人力和预算）,形成项目综合计划和综合进度表,产生的文档：,功能规范，开发计划，测试计划（用例），项目综合计划,开发进度表，测试进度表，综合进度表,11,如何完成一个里程碑,步骤三： 完成功能,开发人员分别完成自己的功能,使用版本控制工具,使程序员及时,check out,和,check in,，避免积累大量代码,及时进行模块间的整合，及时发现问题（,daily build,）,对每一项可测试的功能进行测试，无需等待,使用测试用例工具，对功能进行完整和重复的检验,使用,BMS,进行缺陷跟踪,记录所有程序问题,实现解决,Bug,的自动流程,按照综合进度表不断检查进度,使用的工具：,版本控制工具,VSS,缺陷跟踪工具,Raid/BMS,测试用例管理工具,12,如何完成一个里程碑,步骤四： 稳定与发布,测试组全面地测试功能，包括性能和稳定性,开发组全力配合解决,Bug,使用,BMS,进行,监测质量情况,预测发布日期,专家会诊机制：,决定,Bug,的优先度,决定哪些,Bug,可以等到下个里程碑或版本中解决,决定由谁解决某个,Bug,使用的工具：,版本控制工具,VSS,缺陷跟踪工具,BMS,测试用例管理工具,13,微软的开发管理经验：,100%,以,Bug,为核心,14,测试人员,Raid/BMS,项目经理,其他人员,构造员,开发人员,VSS,构造服务器,发布服务器,Exchange,100,%,由缺陷跟踪工具驱动,15,Bug,及常见类型,功能未实现，和规格说明书不一致,不能工作：死机，没反应,不兼容,边界条件,界面、消息、提示不够准确，不友好,把尚未完成的工作也作为一个,Bug,文档与帮助信息中的缺陷也是,Bug,16,RAID/BMS,的基本功能,完整的,Bug,数据库,整个产品组的中央记录和控制,强大的查询功能，有效地跟踪项目的状态,所有的记录无法删除，对于每个记录只能一直添加内容,丰富的报表功能，为产品发布提供判断标准,17,18,Bug,记录中的有效信息,状态,负责人,问题种类,严重级,优先级,修改时间,登记时间,缺陷来源,解决方案,运行环境,缺陷关联,附件,附图,缺陷细节,19,Bug,的严重程度,死机，数据丢失，主要功能组完全丧失，系统悬挂,主要功能丧失，导致严重的问题，或致命的错误声明,次要功能丧失， 不太严重，如提示信息不太准确,微小的问题，对功能几乎没有影响，产品及属性仍可使用,.,如有个错别字,20,激活的,Bug,数量的趋势,代码完成前：很少,代码完成后：增长很快,接近,Beta,:,下降,接近,RC,:,奔向零,产品质量和里程碑的信号,每天新建的,Bug,与 修正的,Bug,相比较,.,Active,状态,Bug,的总数,21,微软的一天,让我们看看项目中每个角色的一天是如何度过的,开发,测试,项目经理,注：里程碑的每个阶段每个角色的工作有不同侧重点，我们以“完成功能”阶段为例,22,微软的一天从几点开始？,23,微软的一天从几点开始？,答案：半夜为什么？,24,微软的一天从几点开始？,答案：半夜因为,Daily Build,是所有工作的核心，而且是在半夜自动启动。,25,每日构造,你知道自己所用,Windows,的版本号吗？,Daily Build,的意义：,模块得以及时整合,要求程序员及时把最新代码放入代码库,用脚本语言和编译,/,链接工具实现,BVT Build Verification Test,对,Build,进行验证,Blocking Bug,让,Build,无法完成的问题,BVT,中发现的问题,26,程序员每天上班前最担心什么？,27,程序员每天上班前最担心什么？,答案：因为自己昨天的代码,check-in,，造成,Blocking Bug.,为什么？,28,程序员每天上班前最担心什么？,答案：因为自己昨天的代码,check-in,，造成,Blocking Bug.,因为每天的,Build,是所有人当天工作的基础：,程序员需要,Build,验证与其他模块的接口测试需要,Build,发现新,Bug,，并验证新,Build,中已解决的,Bug,29,有,Blocking Bug,怎么办？,解决问题，并对今天的,Build,打,Patch,。,30,开发人员的正事,经历对,Build,的提心吊胆和争分夺秒之后，第一件事做什么？,31,开发人员的正事,经历对,Build,的提心吊胆和争分夺秒之后，第一件事做什么？,答案：打开缺陷跟踪工具，查看指定给自己的,Bug,，解决高优先度的,Bug,。因为质量重于新功能。,32,接下来，开发人员会,从版本控制工具中,Check out,代码,修改代码（解决,Bug,或实现新功能）,取得版本工具中最新变化，在本机,Build,和单元测试,请开发组同事作,Code Review,Check in,代码,33,Raid/BMS,测试人员,邮件系统,源代码,服务器,发布服务器,专家会诊,开发人员,Builder,1.,拿到新的版本,2.,记录,bug,3.,得到新的,bug,4.,解决,Bug,5. Check in,请求,6.,批准,7. Check in,8.,拿到最新源代码,9.,编译,10.,验证,bug,解决 并关闭,Check-in,过程,34,测试人员第一件事做什么？,35,测试人员第一件事做什么？,答案：打开,Raid/BMS,，查看指定给自己的,Bug,，验证已解决的,Bug,。,36,接下来，测试人员会,根据测试用例检验今天的,Build,在,Raid/BMS,中记录新发现的,Bug,37,专家会诊,参加者：项目经理和开发组长、测试组长,通过,Raid/BMS,评估每个未解决的,Bug,决定,Bug,优先度,可否等到下个里程碑或版本解决？,谁来解决,预测项目实际进度和发布时间,38,缺陷走势图,39,回顾微软的一天,构造,: daily build,开发,:,解决,blocking bugs,实现功能, check-out, code review, check-in,测试,: BVT,使用测试用例进行测试,项目经理,/,组长,:,专家会诊,40,微软的做法解决了那些常见问题？,41,质量问题,以前解决过的问题发布时又出现了，需要返工,无法预估发布时间,过早发布，带来质量和维护问题,测试发现的问题被忘却或不了了之,无法衡量测试员和开发员的工作,程序中的问题往往在发布后才发现,42,文档管理问题,文档与程序脱节，文档成为程序结果的描述,项目组把写文档看成负担,43,团队协调问题,开发人员各自为战，进行整合时发现模块衔接中的严重问题,需要作大的改动,没有保管好公司以往的版本和代码，无法满足用户对旧版本的更改要求,开发人员离职对项目带来很大冲击，没有人知道代码在哪，或无法读懂,44,提高软件管理的步骤,45,提高软件开发管理的步骤,使用,Raid/BMS,，将流程管理自动化,使用测试用例管理工具,使用文档管理工具,使用版本控制工具，进行,Daily Build,建立代码标准,建立,Code Review,机制,建立专家会诊机制,建立团队沟通机制,根据需要调整团队结构,46,Q & A,47,