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

1、微软研发团队敏捷开发最佳实践日程 微软开发工具事业部概况及面临的挑战 敏捷开发简介 经验分享：Visual Studio Team Architect团队的敏捷实践 Q & A微软开发工具事业部概况 我们的使命: Make every software project successful with MS platform and tools Altair Basic Interpreter 微软发布的第一个产品微软开发工具事业部概况 超过3000 名雇员, 超过 25个产品团队 我们的客户 非专业开发人员及编程爱好者 专业开发人员 测试人员 设计人员 企业级系统架构师一组很炫的数字活

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

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

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

5、sks项目关系人，项目关系人， 客户客户4 Week Iterations每日每日 Sync up 会议会议Sprint产品产品Backlog 功能功能Sprint Backlog 任务任务Sprint 计划确定能够被完成和集成的功能列表确定能够被完成和集成的功能列表产品 BacklogSprint BacklogStory Parts Test CommentsPM CommentsDev Comments设计文档及测试计划 测试人员在设计文档审核中的作用 质量设计 对设计的可测试性提出反馈 对设计的复杂性提出反馈 验证设计是否满足了需求 开发人员在测试计划审核中的作用 质量计划 对测试的重

6、点领域（优先级）提出反馈 测试是能够自动化的吗? 存在没有测试到的领域吗？VS Main BranchTeamBranchFeatureBranchDev/TestCodeTeamBranchFeatureBranchDev/TestCodeTeamBranchFeatureBranchDev/TestCodeFeatureBranchFeatureBranch编码实现及测试维护功能团队所在独立分支的代码质量维护功能团队所在独立分支的代码质量代码签入流程维护功能团队所在独立分支的代码质量维护功能团队所在独立分支的代码质量开发人员的单元测试持续集成l 功能团队一起工作在同一个功能分支上功能团队一

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

8、esting 验证功能组件的组合 Security Testing Performance and Stress TestingSprint 测试测试的层次结构一个Acceptance Test的例子稳定阶段l 代码覆盖率分析并填补差距代码覆盖率分析并填补差距l 回归测试回归测试l 探索性测试探索性测试 (Bug Bashing)缺陷大扫除缺陷大扫除l Drive Release Criteria/Quality Gatesl Communicate Quality/Readiness for Integration l 维护功能团队所在独立分支的代码质量维护功能团队所在独立分支的代码质量Qu

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