《微软研发团队敏捷开发最佳实践.ppt》由会员分享，可在线阅读，更多相关《微软研发团队敏捷开发最佳实践.ppt（50页珍藏版）》请在三一办公上搜索。
1、在大型研发团队中玩转Agile 微软研发团队敏捷开发最佳实践,DEV201,日程,微软开发工具事业部概况及面临的挑战敏捷开发简介经验分享：Visual Studio Team Architect团队的敏捷实践Q&A,微软开发工具事业部概况,我们的使命:Make every software project successful with MS platform and toolsAltair Basic Interpreter 微软发布的第一个产品,微软开发工具事业部概况,超过3000 名雇员,超过 25个产品团队我们的客户非专业开发人员及编程爱好者专业开发人员测试人员设计人员企业级系统架构师
2、,一组很炫的数字,微软开发工具事业部面临的挑战,项目周期长接受客户的反馈并进行调整团队成员的工作与生活的平衡按照“peanut butter approach”来完成所有的功能,什么是敏捷?,目标:以低成本，快速地开发出好的软件*.敏捷是一系列的原则敏捷本身并不代表任何流程或者方法论,*Ivar Jacobsen,敏捷的核心原则,为非技术人员及客户提供更好的项目透明度在开发周期中尽可能早的提供产品的商业价值尽可能早的接纳客户的反馈创造机会去接纳变化,敏捷的典型实践,以下的几组实践的框架都能很好的支持敏捷的核心原则ScrumExtreme ProgrammingTest Driven Devel
3、opmentKanban,传统的软件生命周期管理 vs.敏捷,经验分享:Visual Studio Team Architecture团队的敏捷开发实践,项目概览,目标:Deliver architectural tools that help customers manage software complexity.交付物:UML DiagramsLayer DiagramDependency GraphsArchitecture and Model Explorers团队:5 Feature Crews with 6-8 crew members,我们的开发方式,将当前正在运用的优秀实践与
4、敏捷开发的优秀的实践结合起来应用于我们开发当中我们采用了根据我们具体情况优化过的Scrum,功能团队,一个能够很好的进行自我管理且富有战斗力的团队通常由2-3个开发人员，2-3个测试人员和1个项目经理组成团队对所开发的功能或者服务负责基于特定的时间进行迭代开发并发布功能在每次进行代码分支合并以前必须达到质量要求,Scrum,以项目管理的实践为核心迭代式开发由一系列的短周期的迭代组成开发中的技术环节的工作量并不用人月来衡量,我们的总体项目流程,Sprint Backlog-Tasks,项目关系人，客户,4 Week Iterations,我们的总体Scrum 流程,每日 Sync up 会议,S
5、print,产品Backlog 功能,Sprint Backlog 任务,Sprint 计划,确定能够被完成和集成的功能列表,产品 Backlog,Sprint Backlog,功能定义,Story Parts,一个功能定义的例子,一个功能定义的例子(续),Test Comments,PM Comments,Dev Comments,设计文档及测试计划,测试人员在设计文档审核中的作用 质量设计对设计的可测试性提出反馈对设计的复杂性提出反馈验证设计是否满足了需求 开发人员在测试计划审核中的作用 质量计划对测试的重点领域（优先级）提出反馈测试是能够自动化的吗?存在没有测试到的领域吗？,代码分支结构
6、,VS Main Branch,TeamBranch,FeatureBranch,Dev/TestCode,TeamBranch,FeatureBranch,Dev/TestCode,TeamBranch,FeatureBranch,Dev/TestCode,FeatureBranch,FeatureBranch,编码实现及测试,维护功能团队所在独立分支的代码质量,代码签入流程,维护功能团队所在独立分支的代码质量,开发人员的单元测试,持续集成,功能团队一起工作在同一个功能分支上构建是自动进行的快速构建 用于测试核心的功能场景(30-60 分钟)任何构建失败都必须马上被修复完全构建 用于运行完备
7、的测试(数小时甚至更长)任何构建失败都必须在本次迭代中被修复适时的代码签入能够极大的减少冲突及集成问题,持续集成,Acceptance Testing验证功能Functional Testing验证功能组件Integration Testing验证功能组件的组合Security TestingPerformance and Stress Testing,Sprint 测试,测试的层次结构,一个Acceptance Test的例子,稳定阶段,代码覆盖率分析并填补差距回归测试探索性测试(Bug Bashing)缺陷大扫除Drive Release Criteria/Quality GatesCom
8、municate Quality/Readiness for Integration,维护功能团队所在独立分支的代码质量,Quality Gates,Quality Gates,Maintaining Team Branch Quality,迭代回顾与总结,需要持续改进的部分,哪些工作完成了?,Scrum Taskboard,总结的教训:计划,指定整体的计划和路线图是非常重要的好的架构设计是不能被忽略的依赖关系需要小心的进行管理,总结的教训:质量,在迭代的上游阶段就要强调质量重视代码质量并努力修复代码陷阱重构往往意味着额外的成本增加持续集成永远是你最好的朋友,总结的教训:交流,高效的沟通与写作
9、是必须的沟通的透明度是必不可少的维持一个统一的节奏是重要的达到一个统一的节奏往往是不那么容易的,总结的教训:流程与工具,选择那些能够适应团队和项目的实践使用那些能够被团队很容易的适应并且也能很好适应开发流程的工具每次迭代中的总结与回顾如果能够被很好的跟进将是非常有效的,敏捷开发在大型团队中有效吗?,我们从其他团队承接了额外的功能集我们在Beta 1以后根据用户的反馈又增加了超过10项新的功能我们按照我们的日程高质量的完成了我们的工作,成功的要素,人是人写出了软件，所以人是软件项目成功的最重要的因素流程保留当前的流程实践中好的部分并且将它们和敏捷开发中好的实践相结合，共同应用到开发实践中来工具使用工具来帮助软件项目中的人遵循好的实践要求同时不让他们付出过多的学习成本,微软中国研发集团服务器与开发工具事业部,商用平台开发工具管理与服务,团队博客：stbcblog/我们关注的论坛,Windows Server解决方案协议工程商业在线服务,我们的精彩五年,Q&A,更多精彩演讲,DEV200：“微软软件研发方法论及软件开发平台构建”DEV202：“高效与流程导向的开发团队企业部署Visual Studio Team System最佳实践”ARC211：“架构利器Visual Studio 架构工具预览”,
