转 微软的缺陷管理方法.docx
- 文档编号:29619216
- 上传时间:2023-07-25
- 格式:DOCX
- 页数:21
- 大小:31.83KB
转 微软的缺陷管理方法.docx
《转 微软的缺陷管理方法.docx》由会员分享,可在线阅读,更多相关《转 微软的缺陷管理方法.docx(21页珍藏版)》请在冰豆网上搜索。
转微软的缺陷管理方法
转微软的缺陷管理方法
一.团队组织
1.微软团队模型
项目经理,开发,测试人员比例为5%,31%,64%。
产品团队中,权威仅仅来自于知识,而不是来自于职位。
Peoplearemostproductiveworkinginsmallteamswithtightbudgets,timedeadlines,andthefreedomtosolvetheirownproblems.–BillGates
通过有效的风险管理,使不确定因素达到最小
使用小团队并行工作,达到最多的同步点
定期编译与快速测试,使产品的稳定性和可用性达到最佳
2.各角色的职责
1)ProductManagementTeam让客户满意
;Target:
确定产品远景,获取并确定用户需求,开发并维护商业安全,满足用户需求。
;Role:
部门负责人为ProductGeneralManager,下设ProductUnitManger,ProductPlanning,MarketandResearch,Evangelism与PublicRelation的部门负责人;evangelism:
说服别人,产品推销,原意为"战斗似的热情"
;Task:
进行GroupProgramManagement,清楚地知道用户的需求,并给出详细定义,即用专业术语描述;确保新产品带来利润;控制用户的期望值;设计大概的产品特性和进度表;管理市场,推销及公共关系。
2)ProgramManagement在项目约束条件下交付
;Target:
制定开发功能规范,在团队内沟通与协商,维持产品进度并报告产品状态,保证在产品约束条件下按时发布产品。
;Role:
projectcoordination,productarchitecture,releasemanagement
;Task:
管理产品细节,如feature的详细设计;促进团队沟通与交流,如planfollowingup;控制全局,保证项目按时完成,生产过程中的tradeoff。
3)SoftwareDevelopmentManagement按产品规格交付
;Target:
开发出满足设计规范和用户要求的产品。
;TeamRole:
软件架构师(SoftwareArchitect)与软件开发工程师(SoftwareDevelopmentEngineer)
;Task:
进行SoftwareDevelopmentManagement,包括database,systemservice,userinterface。
4)SoftwareTesting解决所有问题后发布
;Target:
开发测试策略和计划,保证解决了所有已知问题后,再发布产品。
;TeamRole:
测试工具软件开发工程师(SoftwareDevelopmentEngineerinTest,SDE/T)与软件测试工程师(STE)。
;Task:
进行testmanagement,compliancetesting,configurationtesting,integrationtesting,stresstesting测试工具的编写-开始于,TestCase确定之后,并根据TestCase来设计。
;通过使用来发现bug不是真正的测试,只能发现一般用户问题,属于最基本测试范畴;
;测试要考虑所有出错的可能性,错误的承受力,运行的性能问题,软件的兼容性;
;一流的测试人员,不仅要找出bug,还要定位引起bug的代码行;对设计缺陷,测试人员应提出一个更合理的设计,并确保此设计易于开发人员实现。
ActiveBug指当前必须修改的defect。
5)UserEnducationTeam提高用户胜任力
文档编写,用户培训;保证使用文档要全部清除地写出来,提高用户使用产品的技能,保证大多数用户能够充分利用产品的功能。
6)Logisticmanagement平滑产品部署
产品实施与维护。
3.开发过程特点
1)文档齐备:
每人清楚了解自己需要做的工作;功能规范由一个3-5人的小组负责完成。
2)相互阅读代码:
实现目标为同一个feature,代码间可能相互依赖,有助于整体提高效率;避免核心代码由一人完全控制。
3)代码注释:
包含详尽的调试信息,便于理解与问题解决。
二.项目管理
1.管理机制
•;组织架构
;产品开发行政结构,一个ProductUnitManger,下设三个平级的部门经理,团队项目经理(ProductUnitManager),软件开发经理(DevelopmentManager)和测试经理(TestManager);每个部门经理管几个组长,每个组长下再有3到5个具体工作人员,如项目经理,软件开发人员与测试人员。
;产品设计,产品实现和产品测试,三权分立,相互配合,相互制约,相互依赖,有助于建立明确责任制,从而保证产品开发的顺利完成。
;软件开发与测试经理/组长,均为专业技术人员出身,能够指导部下工作或代替他们完成任务;这样人员的行政管理就是领域专家式管理,保证了开发从技术上思考和评判设计方面的问题。
员工也会乐意接受能真正了解他具体工作的人领导,并给与充分的尊重,同时也能避免开发人员虚报所需工作日的情况。
;微软行政级别决定员工工资,股权等福利待遇,而职务头衔与行政级别并不是直接挂钩的。
技术人员只要能力强,贡献大,行政级别与工资,福利待遇可能同高层一样,不需成为经理或领导才能获得较高级别的待遇。
这样他们可安心自己擅长的工作,其能力和贡献,可经不断的提级来得到认可和回报。
•;项目经理配置
;随着软件产品项目规模增大,产品质量问题,开发周期问题,内部管理等问题越来越突出,必须从根本上加强项目的组织管理,从而微软产生了项目经理这一职位。
;项目经理全权负责产品的最终完成,其任务涉及:
了解用户需求;进行产品的功能定义,规划和设计;做各种复杂决策,保证开发队伍顺利开展工作,及跟踪程序的错误等。
项目经理占开发总人数的1/5,即每个开发小组中,有一个项目经理,两个软件工程师,与两个软件测试工程师。
;具体工作描述:
1)制定产品远景计划,写出项目规格说明书;
;确定商业机会后,产品单元经理制定出粗略的商业计划书,交项目经理准备项目计划草案,包括远景描述,主要功能,建议的时间表,里程碑及所需的资源。
;主持由开发测试骨干参加的会议,对计划草案进行全面的分析讨论,确定主要功能模块。
;对每一模块编写一页纸规模的设计说明书,包括功能优先级的制定与理由,对资源的估算,时间表的估算,风险评估,同其他功能块的关系;目的要评估实现这个功能块的成本,目标与条件。
;召集产品单元经理,各部门经理参加的设计说明书评审会,汇总所有功能块说明书,对进度,功能块的取舍做总结和决定。
2)制定工作详细任务表,跟踪任务的执行情况,保证其符合规格说明书的原始设计。
3)指导项目开发的过程设计与实现;对各种具体方案进行取舍并做出决定。
4)组织会议,评审程序错误;协调成员之间交互配合。
5)产品完成后,主持项目总结报告会,讨论此次的经验与教训;下一版本的改进,及具体的行动计划。
•;项目经理要求
;项目经理通过产品单元经理,对软件设计工程师和测试工程师的资源和任务分配进行调整,但不会直接下达行政命令;其核心任务是业务领导,掌握产品全局观念和进度,协调开发人员与测试人员的工作进度,及同与产品有关的其他人员接触,如市场,用户支持,客户教育等。
;对团队的领导,主要依靠其个人威信(credit),开发人员和测试人员的尊重和配合;其威信来自于工作中表现出的领导力,洞察力和判断力,以及高素质的技术专长和出色的协调沟通能力。
1)领导能力保证项目组的高效运作,如,召集每周的项目进度会议,确定工作日程并进行跟踪,提交项目进度报告。
2)洞察力和判断力,有助于在复杂情况下,迅速找到问题症结所在,并提供解决对策。
3)技术专长使其能真正帮助开发人员解决设计上难题,帮助测试人员分析和判断程序错误;懂得开发人员和测试人员的共同语言,使之感到你对他们的理解和尊重,从而赢得大家的信任。
;项目经理面试问题:
1)在过去做过的产品项目中,哪一个你觉得最自豪?
为什么?
2)你解决过的最难的技术设计问题是什么?
为什么采用那种解决方案?
3)你有什么项目是按计划的时间完成的?
未能按时完成的原因主要是哪些方面?
2.软件开发过程softwaredevelopmentinMircosoft1)Newproductproject提议;2)市场分析预测是否有用,是否是需要的;
3)技术可行性分析是否能够实现;4)产品研发计划和实施步骤;
5)高层论证和审批支持者;6)项目确立和执行人力资源和财务资源的配置
3.微软项目管理--多里程碑式流程
•;每个里程碑完成部分功能;便于团队集中力量完成一个又一个功能;提供多个机会以适应需求的更改
如何完成一个里程碑
•;步骤一:
达成共识Vision/ScopeApprovedMilestone
;基本完成需求调研和分析(产品经理负责);确定大方向和长中短期目标,Vision来说明,并激励团队;评估Opportunities&Risks;分析可利用资源限制,证明该产品值得去做;
;项目管理团队:
设计新产品目标,具体实现方法;描述产品结构,用户情景覆盖80%以上功能。
;软件开发团队:
开发技术原型,检验新产品价值,并展示产品未来预期。
•;步骤二:
完成项目计划ProjectPlanApprovedMilestone
;定义详细的逻辑设计,功能设计规范(项目经理负责),其优先级;所有角色参与审阅功能规范;
;评估进度控制风险,功能技术风险;RiskAssessment通常在物理设计之后,立即执行。
;制订总体开发计划和进度表,包括资源与职责的分配,制订测试,开发计划和进度表;
;产品管理团队:
概念设计和市场推销计划/进度表;
;软件开发团队:
物理设计和开发计划/进度表,Task-levelEstimating。
•;步骤三:
完成功能ScopeComplete/FirstUseMilestoneαVersionPhrase
;版本化的功能规范,完成全部功能代码的编写;Allfeaturesbuilttospecification
;及时进行模块间的整合,及时发现问题(dailybuild);版本控制工具VSS;
;测试团队:
测试规范与TestCase设计,BMS缺陷跟踪,实现解决Bug自动流程;
;产品管理团队:
控制用户的期望,推销,价格,包装(正式产品为GoldenRelease)
;项目管理团队:
项目跟踪/沟通,按照综合进度表不断检查进度;制定β版本计划。
•;步骤四:
稳定与发布ReleaseMilestoneβVersionPhrase
;全面地测试功能;开发组全力配合解决Bug;决定哪些Bug到下个版本中解决;
;预测发布日期;编写操作手册与帮助文档;
;基于版本发布:
每一个版本有明确清晰的目标,解决或终结产品中的某些问题;
;成立Triage小组:
由PM,Dev与Test的负责人组成,决定对发现Bug的处理。
三.微软的开发管理经验:
100%以Bug为核心
Bug追踪归类:
Fixed:
已修复或更正;Duplicated:
某bug以被别人找出来了;Won'tfix:
可忽略不计
Postponed:
此bug不很重要,可推迟到下一阶段解决,或更正风险太大,bug本身影响有限;
Bydesign:
不符合逻辑,也不符用户需求,但同设计吻合;
Notrepro:
某bug自动消失,可能处理其他bug时,一并修复了。
1.Bug及常见类型
•;功能未实现,和规格说明书不一致;不能工作:
死机,没反应;不兼容;边界条件
•;界面、消息、提示不够准确,不友好;把尚未完成的工作也作为一个Bug;文档与帮助信息中的缺陷
4.RAID/BMS的基本功能
•;完整的Bug数据库;整个产品组的中央记录和控制;强大的查询功能,有效地跟踪项目的状态
•;所有的记录无法删除,对于每个记录只能一直添加内容;丰富的报表功能,为产品发布提供判断标准
5.Bug记录中的有效信息
•;状态;负责人;问题种类;严重级;优先级;修改时间;登记时间
•;缺陷来源;解决方案;运行环境;缺陷关联;附件;附图;缺陷细节
6.Bug的严重程度
1)死机,数据丢失,主要功能组完全丧失,系统悬挂;2)主要功能丧失,或致命的错误声明
3)次要功能丧失,不太严重,如提示信息不太准确;4)微小的问题,对功能几乎没有影响,仍可使用.
7.激活的Bug数量的趋势
•;代码完成前:
很少;代码完成后:
增长很快;接近Beta:
下降;接近RC:
奔向零;
•;产品质量和里程碑的信号
•;每天新建的Bug与修正的Bug相比较;Active状态Bug的总数
四.微软的一天
1.每日构造DailyBuildDailyBuild是所有工作的核心,而且是在半夜自动启动。
•;DailyBuild的意义:
模块得以及时整合;要求程序员及时把最新代码放入代码库
•;用脚本语言和编译/链接工具实现
•;BVTBuildVerificationTest:
对Build进行验证
•;BlockingBug:
让Build无法完成的问题;BVT中发现的问题
2.程序员每天上班前最担心什么?
答案:
因为自己昨天的代码check-in,造成BlockingBug.每天的Build是所有人当天工作的基础,程序员需要Build验证与其他模块的接口;测试需要Build发现新Bug,并验证新Build中已解决的Bug。
有BlockingBug怎么办?
解决问题,并对今天的Build打Patch。
答案:
打开缺陷跟踪工具,查看指定给自己的Bug,解决高优先度的Bug;为质量重于新功能。
从版本控制工具中Checkout代码;修改代码(解决Bug或实现新功能);取得版本工具中最新变化,在本机Build和单元测试;请开发组同事作CodeReview;Checkin代码
3.测试人员第一件事做什么?
答案:
打开Raid/BMS,查看指定给自己的Bug,验证已解决的Bug;根据测试用例检验今天的Build;在Raid/BMS中记录新发现的Bug4.专家会诊
•;参加者:
项目经理和开发组长、测试组长
•;通过Raid/BMS评估每个未解决的Bug:
决定Bug优先度;可否等到下个里程碑或版本?
谁来解决
•;预测项目实际进度和发布时间
缺陷走势图
5.回顾微软的一天
•;构造:
dailybuild;开发:
解决blockingbugs,实现功能,check-out,codereview,check-in
•;测试:
BVT,使用测试用例进行测试;项目经理/组长:
专家会诊
6.微软的做法解决了那些常见问题?
质量问题
•;以前解决过的问题发布时又出现了,需要返工;无法预估发布时间过早发布,带来质量和维护问题
•;测试发现的问题被忘却或不了了之;无法衡量测试员和开发员的工作;程序中的问题往往在发布后才发现
文档管理问题
•;文档与程序脱节,文档成为程序结果的描述;项目组把写文档看成负担
团队协调问题
•;开发人员各自为战,进行整合时发现模块衔接中的严重问题需要作大的改动
•;没有保管好公司以往的版本和代码,无法满足用户对旧版本的更改要求;开发人员离职对项目带来很大冲击,没有人知道代码在哪,或无法读懂
五.提高软件管理的步骤
1.使用Raid/BMS,将流程管理自动化;2.使用测试用例管理工具;3.使用文档管理工具;
4.使用版本控制工具,进行DailyBuild5.建立代码标准;6.建立CodeReview机制;
7.建立专家会诊机制;8.建立团队沟通机制;9.根据需要调整团队结构
产品设计考虑问题
1Who:
为谁设计,用户是谁?
不能为所有人服务;
2What:
要解决哪些用户问题?
3Why:
为什么要解决这些用户问题?
例:
曲别针,餐馆中尖头筷子,一正一反可供参考。
设计之源:
在于用户;设计之本:
要满足用户需求,方便用户使用,并且使生产制造工艺尽可能简单;不能把软件设计单纯当作自我技术水准,个人才智表达的方式。
(用户场景:
用户使用软件的特定环境或场合。
)
TheProgramManagementRoleTodayDevelopmentteamorganizationchart:
Marketing,DeveLead,PM,TestLead,DocumentationDeveloper:
MostlyC.S.majors;Input:
Spec,Bugs;Output:
SourceCode;Resolvebuildbreaks;Conductunittesting;BuddyTesting;Realitycheck:
what'spossibleTesters:
Manydifferentmajors;Input:
Spec,CompiledCode;Output:
Bugs,Sign-off;TypesofTesting:
ManualvsAutomated(regression),BasicvsFunctionalvsStress;Performance&Reliability;BuddyTestingMarketing:
MostlyBusinessmajors;Input:
MarketResearch;Outputs:
Long-termPlanning,Advertising,Packaging,DistributionChannels,InteractionwithSalesgroupsDocumentation:
Input:
Specs,Product;Outputs:
Books,OnlineHelp,Trainingclasses,onlinetutorialsPM:
nothaveauthority;Plans&Specsreviewedbymarketing,devlead,testleadandvp;everyonehasthrrighttoaskquestion,andcoulddisagreewithit.
WhatdoProgramManagersdo?
1)Designtheproduct;2)Writeproductplansandspecifications;3)Driveday-to-daydevelopmentprocess;4)Triage;5)Coordinatewithotherdepartments-location,Lrgal,otherproductgroups,etc.6)Communicateprojectstatus&schhedule;7)HoldPost-MortemDesignPMfocuson1)-4)aspects;ReleasePMaddresson3)-7)aspects.
7keyPMRoles1Designtheproduct
-Organizeadesignteam;Modulararchitecture-lowinterdependency;What'sthetargetmarket?
Usabilitystudies&customerfeedback;Puttogetheraprototype&demo;Howmanypeoplewillyouneed?
Howmanymonthswillittaketodevelop?
GetVPapproval2WriteProductPlansandSpecifications-BuildaConsensus
-VisionDocument:
WhattheVPapproved;
-FunctionalSpecification:
Whatfeatureswilltheproducthave?
Whatwilltheylooklike?
WhatfeatureswilltheproductNOThave?
Whataretheprojectmilestones?
ReviewdocumentswithallteamsExamplevisionstatement:
InternetExplorerIncreaseIE'smarketshareto65%in1998bydeliveringthepremimerinternetclientforcorporationsandendusers,afastandrobustexperience,thelowestownershipcost,andthebestcomplementtoMicrosoftOffice.
3Driveday-to-dayDevelopmentProcess
-UsePersuasion,notauthorityPersuasionstyles:
Logos-uselogicalreasoning;Pathos-appealtotheperson'semotions;Ethos-appealtotheperson'scharacterandcorevaluesKeeptheDev'scoding,thebuildsbuildingandthebugsflowing;Spottroublebeforeithappens
-TypicalTroubleSpotsUnforeseenvacation,familiyleav;Jobchanges-peoplepromoteorleav/jointeaminmid-productcycle;Higherpriorityprojects
-FromDevelopmentWorkloadimbanlance-oneDevgetswaybehind;Toofeature-
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 微软的缺陷管理方法 微软 缺陷 管理 方法
![提示](https://static.bdocx.com/images/bang_tan.gif)