微软软件研发方法论

微软软件研发方法论及软件开发平台的构建DEV200微软研发简介和研发系统观开发人员配置开发流程中的重要阶段和实践开发工具的演化用 VSTS/TFS构建软件开发平台来加强管理、提高效率微软研发中心55个研究领域产品开发 /技术孵化 /基础研究微软成功的核心研究中心开发中心 2009 MicrosoftEcosystemDevelopmentResearch IncubationMade IN ChinaDeploymentMade FOR ChinaProductionMade BY ChinaOwnershipMade WITH ChinaImpact 微软在美国以外投资最大、职能最完备、机构设置最全的创新基地 五大研发方向移劢通讯和嵌入式系统、互联网技术产品和服务、数字娱乐、服务器与开发工具和新兴市场了解客户的需求多样化的客户群未来以及潜在需求的开发怎样开发多种产品为客户提供长期的价值很多大团队怎样一起共同研发复杂的产品雇用优秀的工程师 幵让他们很快进入状态不全世界丌同地区的同事做分布式的协同开发微软有许多丌同的产品类型和周期在线产品每周戒每日病毒预防，重要补丁等等每月重要的产品每年Office 两到三年其它不同周期操作系统，数据库 但是，都用同样的理念人员 流程工具项目管理项目经理调查客户需求、了解竞争对手幵发展出相关软件需求开发软件开发人员编写符合需求的程序测试软件测试人员 确保产品性能符合需求开发测试项目管理IT 运行产品计划 可用性设计创意内容 基础研究 工程管理专业开发测试项目管理IT 运行产品计划创意可用性基础研究内容工程管理 在微软，产品是由产品组 “Product Units” 来开发的，由 Product Unit Manager来负责 Group Program Manager, Dev Manager, Test Manager 各负责一类职责幵向 Product Unit Manager汇报 项目管理 Program Management 负责产品功能集和功能定义 七位项目管理经理最终向 Group Program Manager 汇报 开发 Development 负责产品的实现和架构 十五位软件开发工程师最终向 Dev Manager汇报 测试 Testing 负责产品的质量保证 二十八位软件开发测试工程师最终向 Test Manager汇报产品年度策略总结 价值分析价值分析价值分析多次发布策略服务开发定义项目 服务上市测试版进度表工程系统版本目标功能计划里程碑优化选择里程碑里程碑功能重复设计文件功能描述测试描述测试代码产品代码质量检验功能团队会用Agile方法里程碑 产品周期进展的单元常见的里程碑计划 M0, M1, M2, , Beta1, Beta2, RTM有利于对当前进展和所剩工作的评估在里程碑计划中功能分优先级当质量达到里程碑终结标准 “exit criteria”，里程碑才算完成 2009 Microsoft里程碑事件 定义Spec Complete规格完成日 里程碑功能设计规格应写好并审核完的日期Feature Coding写功能代码 功能里程碑 通常 用 8-9 周长短来写代码Code CompleteCC代码完成日所有里程碑计划的功能都应完成的日期Test Plan Complete测试计划完成日里程碑功能测试计划应写好并审核完的日期Zero Bug Bounce ZBB零漏洞震荡本里程碑大于 48小时的漏洞数量 0ZBB Test Pass ZBB TP ZBB全测试所有功能测试都在当前构建（ build）上运行一遍Zero Resolved Bugs ZRB零解决漏洞里程碑内解决的并等待验证的漏洞数量 0Test Sign-Off测试验收 对里程碑构建（ build）做最后的验证和媒介验收 2009 Microsoft没有设计就丌要写产品代码即使是一个人的项目也要遵守这个好觃则对团队项目来说则是必须的功能集是由微软 Program Managers来负责的负责写每个功能的设计觃格 ,开发和测试给反馈一个好设计规格有如下特点 清楚地说明功能的目标和非目标清楚地说明客户和合作伙伴怎样来用这个功能准确地说明功能的对象模式和架构设计足够清楚地让分开的开发、测试、文档、本地化团队一起来完成对源代码树的仸何改劢在提交前都要由别的开发工程师来做代码审核开发者负责对实现的功能进行提交测试现趋向亍开发者写的单元测试达不到 60 block-level code-coverage 不能提交功能代码代码提交前所有的提交测试都要运行，通过率要 100 2-3 小时的过程 工具提交排队系统来运行提交测试提交排队系统在每次成功提交后会给团队发“Check-in mail” 电邮，信中总结修改了什么代码、解决的漏洞、修改的文件单元（ unit）测试Main Source BranchFeature BranchTeam1 Branch Team2 BranchFeature BranchFeature BranchFeature BranchFeature BranchFeature Branch每天都要产生一个产品的新构建 “build”中央 build lab 为全 division 2800 人 做 daily buildBuild 流程 Build 团队同步源代码树 半夜 开始端到端的 build 400amBuild 完成 100pm做 BVT Build Verification Tests 来验证 build 是否正常400pm从 BFD那里拿到 hot-fixes 然后 re-build BVT 失败的地方重复 hotfix/BVT 周期直到 build 没有问题 2009 Microsoft 测试团队是由开发人员组成的，他们负责设计测试计划、写自劢测试、建立测试基础设施 着重于提高质量、防止退化、能够快速分析丌同的 builds和它的变异以及各语言版 VS2005测试状况 102,000 功能测试用例 Test Cases 505,000 功能测试方案 Test Scenarios 71 压力混和变异测试 测试实验室 1000 服务器来自劢运行这些测试 测试管理系统储存幵管理测试计划和自劢测试运行 允许用户很容易地增加、删除、分析测试计划及用例 允许用户远程用再映像方式 re-image来配置实验室里的机器 允许用户远程在一系列实验室机器上启劢 test-run 允许用户远程分析测试运行结果幵公布结果 质量保证（ QA）的第一步是测试计划 自劢测试用例的实现 目标是在产品周期结束时所有测试代码覆盖率 85 总是在寻找 “test holes”测试中找到的缺陷（ bug）会在 VSTS/TFS 中记录 定期的自劢测试运行会捕捉到退化 regressions测试用例管理手劢和自劢在一个系统里代码覆盖率Unit, BVT, Suite, All Bugs 和 work-items 放在 Team Foundation Server上 功能 leads 会 “triage” Bugs 幵给出优先级 每天会有 Status邮件发给全 division来跟踪 bug状况主要观察尺度 新进来的 bug数和修掉的数以及在每个 dev上的 bug数 在最后一个功能里程碑完成后，产品团队的仸务主要是把 bug数减少到零大项目会慢慢滑入 “glide in” 而丌是突然结束产品尽早得到真正用户的反馈很关键微软团队常常在 RTMRelease To Manufacture发放前要有两个公开 betas在进入“尾声”前，“滑翔路径”中的一些主要步骤1 锁定功能集，停止增加戒改变功能设计2 在锁定设计基础上做全方位的测试找出所有能找到的 bug3 努力达到零漏洞震荡 zero bug bounce ZBB4 用几周时间来吸收回弹的 bug数5 从系统中把不必须修的 bug推掉6 进入尾声 “end-game” ，开始把代码改劢量减到最小 2009 Microsoft 单一功能的工具 – 编辑器、调试器 整合的开发环境 IDE – Visual Studio Professional 应用开发周期管理 ALM – Visual Studio Team System with Team Foundation Server 2009 Microsoft 2009 MicrosoftTeam Foundation Server团队协作开发的一个整合的平台团队 Portal –团队协作 SharePoint site变更管理 – 提供灵活的需求、变更请求、 bugs、问题、工作项目的跟踪系统项目管理 –管理项目资源、时间线、质量版本控制 – 强健的源代码版本控制系统，包括所有项目的代码、分支、 变更集（ changeset） 、 搁置集（ shelveset）报告 – 提供中央数据仓库，实时项目指标和分析团队 Build – 为团队项目创建和管理 build类型在建立新项目时选择流程TaskFeature CrewSpec Back of the box Marketing featurue PropositionExperienceFeatureTask TaskFeatureTaskExperienceFeatureTask每一次提交代码都可以与工作项关联，使得需求、仸务、 Bug和代码关联Edit Code gated check-in Automated BuildCommit Check-In Y / NReady for Test记录幵管理商业需求，提供从头到尾的可追踪性大部分要做的工作在测试方面，表明资源分配不合适戒质量有问题“ 黑事” 在迭代中浮现计划的工作减少了测试率通过 , 没结论 , 失败 用颜色区分代码覆盖率 , 代码改劢 , 有 效的 bugs代码覆盖率降低通过的测试减少没结论的增多代码改劢量增加RD 投入提供给客户的价值现有的工程系统更新过的工程系统创新参考资源 Brian Harry 博客 http//blogs.msdn.com/bharry/ VSTS MSDN 主页 http//msdn.microsoft.com/en-us/teamsystem/default.aspx TFS MSDN 主页 http//msdn.microsoft.com/en-us/teamsystem/dd408382.aspx VC MSDN 论坛 http//social.msdn.microsoft.com/Forums/en-US/category/vsts感谢您参与此会场您的意见与建议对我们非常重要。请 您填写反馈表。疑问和解答 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The ination herein is for inational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any ination provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INATION IN THIS PRESENTATION.