微软软件开发流程实施

1微软软件开发流程实施WendyFan范文峰微软全球技术中心项目专员2002/5/202现存问题测试团队没有权威,没有明确的质量标准和员工度量标准团队成员之间缺乏有效沟通实现的功能不是最初的设计目标,既产品规格和产品开发的一致性产品规格更改维护产品进度无法控制测试计划文档管理3解决方法软件开发过程管理资源管理,包括管理时间,管理成本,管理人员产品管理,管理功能,实现,质量实施步骤团队建立-一个高效的团队具有如下特征目标一致,信念明确积极有效沟通,不要假设别人已经知道主动做事,主动促进流程改进,主动回复别人EMAIL等,主动共享信息通过Process使成员各司其职,每件事情必须有负责人数字化管理实现方式:流程+工具+文档+数字4实施考虑软件流程改进实施前提条件-作为软件企业的ERP系统,改变必然涉及每一个人的日常工作和思维方式,必须有强有力的领导支持和自适应的能力.企业已经建立了有效的邮件管理机制和信息共享机制(通过内部站点共享知识库,资源等).潜意识的有效沟通-使每一次需求更改都被所有的团队成员知道高效率协作,没有权利而是依靠权威和知识领先性的管理方法,结果是高创造性积极工作,发表意见,改进流程实施误区不考虑企业自身的情况,盲目实施流程过度强调工具的重要性:如过度强调自动化测试工具而忽略了测试5流程改进本质-注重沟通强调沟通,更注重实用性团队成员之间的相互牵制,三权分立;程序经理开发组测试组沟通不会自动发生日常会议TRD里程碑总结(PostMotem)每日,每周汇报BugTriageMeetingOneonereview6流程改进本质-使软件开发可控制使软件过程开发成为一个可控制的过程数字化管理:基于数字的软件开发度量树立时间计划的权威性,有效控制时间软件产品有清晰的标准:功能规格书(FunctionalSpecification)作为全组的标准,必须具有权威性基于功能的进度计划和多个检查点保证所有的功能实现符合功能规格书7流程改进本质-持续主动调整必须专门的人员监测整个软件开发流程,并加以调整.将尽可能多的流程书面化.制定六大服务器的OWNER.流程的不断变化和不同时期角色的工作重点调整8项目初始化(一)软件企业需要一个能够满足缺陷跟踪和管理的工具,同时能够为决策提供支持.市场调查(市场人员),并给出产品需求书产品前景目标用户产品包和构件平台支持,硬件和软件环境语言支持功能要求管理层决定实施该项目,并决定PM,TestLead,DevLead人选管理层决定ReviewMeeting的时间完成VisionStatement(前景陈述)9项目初始化(二)项目动员大会Audience听众:所有可得到的人力资源主题宣布项目开始项目前景陈述团队组织人力资源获得:招聘+培训项目发布时间10工作准则-明确准则,积极工作PM的工作进度监控,树立Spec和Schedule的权威性沟通中心,对内确保每一个理解产品的前景,功能和对外确保管理层的支持和满足顾客需求PM一般是整个TEAM的凝聚力所在PM的主要工作以写Spec,开会和查看EmailL,进度监控,查看BUG数据库和沟通为主DevLead的工作通过CodeReview代码审核提供高质量代码制定合理的时间计划技术选型,代码重利用从而达到按时完成代码总体构架设计和通用程序设计团队成员沟通TestLead的工作测试环境的建立测试策略制订测试方法和工具的选用测试案例的维护发布测试报告11M0目的设定项目目标和计划开始完成VisionDocument结束开始编码术语VisionStatement(Marketing),ProductSpecification(PM),testPlan(Testing),DevelopmentPlanandSchedule(Dev),UEStrategyandPlan(UE)PM责任1.完成产品规格书;2.确定产品功能优先级;3.确定项目日程表4.处理外部部件和其它组关系;测试计划检验开发组责任开发组日程表;代码和构架设计;决定各个功能在哪个里程碑完成;规格书检验;测试计划检验测试组责任规格书检验;初始化缺陷数据库;移植前一个版本中的延迟的缺陷数据;添加支持部报告的缺陷;用户教育规格书检验(易用性,完整性和与其它产品的关系),并反馈给PM;提供文档资料计划;日程安排管理层评估上个项目,并改进流程;评估从项目中得到的数据(如缺陷数据分析,工作量统计,缺陷质量);定义不同团队之间的合作方式;同意项目计划;12其它工作人员培训,熟练掌握各种工具.建立源代码服务器,培训TEAMMEMBER使用版本控制工具.确定各团队工作目录确定常规会议,如周项目状态会议新员工工作手册,使新的员工能够非常清楚的知道各个Server和环境安装,及工作流程建立Build服务器和Release服务器测试团队建立BUG数据库服务器建立团队工作信息发布站点,发布团队新闻,共享文档资源,TeamMember联系方式,任务列表等.13文档模板-FunctionSpecification人力资源+FeatureTeam(功能团队)前景描述平台要求语言支持(本地化和全球化)出错处理(日志,警告,信息)和最终返回错误信息用户场景(UserScenarios)功能细分和说明安装程序快捷键要求性能目标用户教育文档和进度计划进度计划(MicrosoftProject)UI设计文档14文档模板-Implementationspec实现文档是一个文档集,包括数据字典资源管理,指定Builder,BVT所有者,PeerReview开发环境,技术选型,程序构架和设计模式代码重用模块划分出错处理多语言支持性能考虑数据库设计公用接口设计15文档模板-测试计划(一)测试环境描述,包括服务器,安装程序描述人力资源划分测试流程及不同阶段的测试重点功能完备性测试测试目标,范围和质量标准测试区域划分易用性测试性能测试可靠性测试平台测试(使用矩阵)恢复测试回归测试缺陷跟踪工具16文档模板-测试计划(二)测试策略描述,频率和所有者测试案例开发和维护,制订测试案例覆盖标准自动化工具开发,决定何时进行自动化工具开发存在大量的API和大量的测试案例测试案例只需要结果”通过”或”不通过”,不需要用户的干预有大量的回归测试案例雇开发人员写自动化工具比雇多个TESTER便宜测试脚本开发测试工具源代码分析工具测试进度17如何实现成功的进度计划进度计划由整个开发团队来制定进度计划而不是PM单独制定事情无论大小,全部列入计划或算进缓冲保证进度计划的权威性.可以将进度计划贴在作战会议或工作房间的墙壁上PM必须非常清楚最重要的事情并推动执行.尤其是在不同的里程碑切换时.并将这一信息传达给全组.在制订计划时,必须考虑到会议,假期,汇报工作,单元测试,病假,解决缺陷和不可预料的事件.缓冲一般为30%~50%.在固定发布日期条件下,尤其应该增长缓冲.18如何实现成功的进度控制监控和度量每天队员发DailyReport,它的格式:HighlightShortcomingToDoList每周PM发WeeklyReport,DevLead和TestLead分别发WeeklyReport对当前项目状态进行总结,这些REPORT的听众必须是所有团队成员,包括管理人员.周报的格式和日报格式相同在周报中安排除了日常工作以外的其它必须检查的事宜.这可以补充进度计划的不足.每周召开团队会议,总结项目当前状态.19M1目的开发产品,保证代码质量并降低BUG数量开始编码开始结束测试团队认为编码按时符合规格书规范完成术语Testspecification;testcases;testscripts;unittesting;TRD;checkin;checkintest;BVT;AcceptanceTest;Dailybuild;MileStonePostmortems;BugCommittee;PM责任管理产品规格书,管理功能组工作状况,保持全组工作重点,推动工作进度开发组责任设计,记录和编码;单元测试,冒烟测试,每日构建,BVT;TRD;解决问题;保证按时完成;测试组责任设计,记录测试规范;写自动化测试编码;在正式提交的代码中进行可接受测试;在里程碑时运行所有的测试案例;报告和关闭缺陷;给出产品质量和功能完成性评估报告;认证功能完成;检验用户文档用户教育书写用户教育文档;基于用户任务来评估功能的完成;用户辅助工具;用户教育文档测试计划20工作流程(一)DEVELOPER检查BUG数据库和电子邮件.如果发现自己的BUG数量高于给定值,则停止开发,更改BUG.PM和LEAD检查BUG数据库和电子邮件.指定BUG给某一个TEAMMEMBER.如果可争议BUG太多,召开BUGTRIAGE会议,讨论BUG的优先级.每天的RELEASE中需要包含说明文件(本版本更正BUG,实现功能,改变的文件),如果是API测试应包含类库文档21工作流程(二)DEVELOPER每天早上从源代码服务器下载代码,更新其它程序员的改变.(SDSYNC)DEV编辑自己的文件(SDEDIT),完成某个FEATURE.DEV编译自己的本地源代码拷贝并进行单元测试,如无错误,交给BUDDYTESTER或CODEREVIEW测试.如果没有错误,提交到源代码服务器.通过这种方法保证源代码服务器中的程序始终是可运行的.如果本次CHECKIN完成了某一个功能,发送TRD到TESTTEAM,证明此功能已完成并可测试DEV发送日报.DEVLEAD指定专门的BUILDER和BVT人员.并写成BUILDSCRIPT.每天在固定的时间运行该BUILDSCRIPT.如,每天2:00AM.每天早上9:00-9:30对当天的BUILD进行BVT和冒烟测试,通过后提交到RELEASE服务器.22工作流程(三)TESTTEAM指定专门的可接受测试人员,并给出可接受的标准.9:30-10:00,指定的测试人员每天早上运行可接受测试,如果成功发EMAIL给全组.其它测试人员开始进行功能测试.功能测试仅测试那些已经发出TRD的功能.TESTTEAM发现BUG,并登记在BUG数据库中.TESTTEAM进行其它测试,如性能测试,本地测试和平台测试.测试频率和目标在TEST计划中制定.如果是MILESTONE结束时,运行所有测试案例.TESTTEAM根据TEST计划开发TESTCASE,编写自动化工具和测试脚本.TESTTEAM发送日报表23使用源代码控制工具放入源文件,文档资料和所有频繁改动的资料不要放入二进制代码,包括动态库和可执行文件只编辑需要改动的编码(SDEDIT)每次CheckIn时,填写变化列表.每次CheckIn之前,保证本地编译通过,并通过代码审核建立每日Release的源代码标签,便于回滚到某一个特定的Build时的源代码.24管理你的BUG数据库建立并备份你的BUG数据库定义BUG管理流程清楚地定义BUG类别和属性建立起BUG的权威性,如果一个BUG可以方便地被重现,该BUG必须被修复.设定BUG数上限DEV不能选择”不修复”和”设计”作为一个BUG的解决方案遇到争论时,BUG被指定给COMMITTEE,由COMMITTEE作出决定.COMMITTEE一般由PM,DEVLEAD和TESTLEAD组成.监测BUG数据库,利用数字标准作为衡量标准,并使全组人员知道这些数字.25软件开发度量(一)前提条件,在实施的过程中和过程后收集大量数据项目开发过程中的数据收集每日,每周登记的缺陷和解决的缺陷(按照严重性统计)跟踪每日已激活缺陷和已解决缺陷数目Fixed缺陷数目;已解决的缺陷