微软研发团队敏捷开发最佳实践.ppt

1、在大型研发团队中玩转Agile 微软研发团队敏捷开发最佳实践,DEV201,日程,微软开发工具事业部概况及面临的挑战 敏捷开发简介 经验分享：Visual Studio Team Architect团队的敏捷实践 Q & A,微软开发工具事业部概况,我们的使命: Make every software project successful with MS platform and tools Altair Basic Interpreter 微软发布的第一个产品,微软开发工具事业部概况,超过3000 名雇员, 超过 25个产品团队 我们的客户 非专业开发人员及编程爱好者 专业开发人员 测试人员

2、 设计人员 企业级系统架构师,一组很炫的数字,微软开发工具事业部面临的挑战,项目周期长 接受客户的反馈并进行调整 团队成员的工作与生活的平衡 按照“peanut butter approach”来完成所有的功能,什么是敏捷?,目标: 以低成本，快速地开发出好的软件*. 敏捷是一系列的原则 敏捷本身并不代表任何流程或者方法论,8/23/2020,8,* * Ivar Jacobsen,敏捷的核心原则,为非技术人员及客户提供更好的项目透明度 在开发周期中尽可能早的提供产品的商业价值 尽可能早的接纳客户的反馈 创造机会去接纳变化,敏捷的典型实践,以下的几组实践的框架都能很好的支持敏捷的核心原则 Sc

3、rum Extreme Programming Test Driven Development Kanban, ,传统的软件生命周期管理 vs. 敏捷,8/23/2020,11,经验分享:Visual Studio Team Architecture团队的敏捷开发实践,项目概览,目标: Deliver architectural tools that help customers manage software complexity. 交付物: UML Diagrams Layer Diagram Dependency Graphs Architecture and Model Explore

4、rs 团队: 5 Feature Crews with 6-8 crew members,我们的开发方式,将当前正在运用的优秀实践与敏捷开发的优秀的实践结合起来应用于我们开发当中 我们采用了根据我们具体情况优化过的Scrum,8/23/2020,14,功能团队,一个能够很好的进行自我管理且富有战斗力的团队通常由2-3个开发人员，2-3个测试人员和1个项目经理组成 团队对所开发的功能或者服务负责 基于特定的时间进行迭代开发并发布功能 在每次进行代码分支合并以前必须达到质量要求,Scrum,以项目管理的实践为核心 迭代式开发 由一系列的短周期的迭代组成 开发中的技术环节的工作量并不用人月来衡量,我

5、们的总体项目流程,Sprint Backlog - Tasks,项目关系人， 客户,4 Week Iterations,我们的总体Scrum 流程,每日 Sync up 会议,Sprint,产品Backlog 功能,Sprint Backlog 任务,Sprint 计划,确定能够被完成和集成的功能列表,产品 Backlog,Sprint Backlog,功能定义,Story Parts ,一个功能定义的例子,一个功能定义的例子 (续),Test Comments,PM Comments,Dev Comments,设计文档及测试计划,测试人员在设计文档审核中的作用 质量设计 对设计的可测试性提出

6、反馈 对设计的复杂性提出反馈 验证设计是否满足了需求 开发人员在测试计划审核中的作用 质量计划 对测试的重点领域（优先级）提出反馈 测试是能够自动化的吗? 存在没有测试到的领域吗？,代码分支结构,VS Main Branch,Team Branch,Feature Branch,Dev/Test Code,Team Branch,Feature Branch,Dev/Test Code,Team Branch,Feature Branch,Dev/Test Code,Feature Branch,Feature Branch,编码实现及测试,维护功能团队所在独立分支的代码质量,代码签入流程,维

7、护功能团队所在独立分支的代码质量,开发人员的单元测试,持续集成,功能团队一起工作在同一个功能分支上 构建是自动进行的 快速构建 用于测试核心的功能场景 (30-60 分钟) 任何构建失败都必须马上被修复 完全构建 用于运行完备的测试 (数小时甚至更长) 任何构建失败都必须在本次迭代中被修复 适时的代码签入能够极大的减少冲突及集成问题,持续集成,Acceptance Testing 验证功能 Functional Testing 验证功能组件 Integration Testing 验证功能组件的组合 Security Testing Performance and Stress Testing

8、,Sprint 测试,测试的层次结构,一个Acceptance Test的例子,稳定阶段,代码覆盖率分析并填补差距 回归测试 探索性测试 (Bug Bashing)缺陷大扫除 Drive Release Criteria/Quality Gates Communicate Quality/Readiness for Integration,维护功能团队所在独立分支的代码质量,Quality Gates,Quality Gates,Maintaining Team Branch Quality,迭代回顾与总结,需要持续改进的部分 ,哪些工作完成了?,Scrum Taskboard,总结的教训:

9、计划,指定整体的计划和路线图是非常重要的 好的架构设计是不能被忽略的 依赖关系需要小心的进行管理,总结的教训: 质量,在迭代的上游阶段就要强调质量 重视代码质量并努力修复代码陷阱 重构往往意味着额外的成本增加 持续集成永远是你最好的朋友,总结的教训: 交流,高效的沟通与写作是必须的 沟通的透明度是必不可少的 维持一个统一的节奏是重要的 达到一个统一的节奏往往是不那么容易的,总结的教训: 流程与工具,选择那些能够适应团队和项目的实践 使用那些能够被团队很容易的适应并且也能很好适应开发流程的工具 每次迭代中的总结与回顾如果能够被很好的跟进将是非常有效的,敏捷开发在大型团队中有效吗?,我们从其他团队承接了额外的功能集 我们在Beta 1以后根据用户的反馈又增加了超过10项新的功能 我们按照我们的日程高质量的完成了我们的工作,成功的要素,人 是人写出了软件，所以人是软件项目成功的最重要的因素 流程 保留当前的流程实践中好的部分并且将它们和敏捷开发中好的实践相结合，共同应用到开发实践中来 工具 使用工具来帮助软件项目中的人遵循好的实践要求同时不让他们付出过多的学习成本,8/23/2020,44,微软中国研发集团服务器与开发工具事业部,商用平台 开发工具 管理与服务,团队博客： 我们关注的论坛 ,Windows Server解