转 微软的缺陷管理方法.docx

转 微软的缺陷管理方法.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-