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

活动用户
3,586
项目
70
工作项
716,858
源代码文件
23,681,882
构建
47,309
微软开发工具事业部面临的挑战
• 项目周期长 • 接受客户的反馈并进行调整 • 团队成员的工作与生活的平衡
• 按照“peanut butter approach”来完成所有
的功能
什么是敏捷?
• 目标: 以低成本，快速地开发出好的软件*.
• 开发中的技术环节的工作量并不用人月来 衡量
我们的总体项目流程
我们的总体Scrum 流程
项目关系人， 客户 产品Backlog – 功能
Sprint 4 Week Iterations
SpSrpinrtinBtaBcakclokglo-gT–as任ks务 每日 Sync up 会议
Sprint 计划
开发人员的单元测试
持续集成
功能团队一起工作在同一个功能分支上
构建是自动进行的
快速构建 用于测试核心的功能场景 (30-60 分钟)
任何构建失败都必须马上被修复
完全构建 用于运行完备的测试 (数小时甚至更长)
任何构建失败都必须在本次迭代中被修复
适时的代码签入能够极大的减少冲突及集成问题
测试的层次结构
一个Acceptance Test的例子
稳定阶段
维护功能团队所在独立分支的代码质量
代码覆盖率分析并填补差距 回归测试 探索性测试 (Bug Bashing)缺陷大扫除 Drive Release Criteria/Quality Gates Communicate Quality/Readiness for
Team Branch
Feature Branch
Dev/Test Code
Dev/Test Code
Team Branch
Feature Branch
Feature Branch
Dev/Test Code
编码实现及测试
维护功能团队所在独立分支的代码质量
代码签入流程
维护功能团队所在独立分支的代码质量
• DEV201
在大型研发团队中玩转Agile — 微 软研发团队敏捷开发最佳实践
日程
• 微软开发工具事业部概况及面临的挑战 • 敏捷开发简介 • 经验分享：Visual Studio Team Architect团队
的敏捷实践
• Q&A
微软开发工具事业部概况
• 我们的使命: Make every software project successful with MS platform and tools
Integration
Quality Gates
Maintaining Team Branch Quality
Quality Gates
迭代回顾与总结
哪些工作完成了?
需要持续改进的部分 …
Scrum Taskboard
总结的教训: 计划
• 指定整体的计划和路线图是非常重要的 • 好的架构设计是不能被忽略的 • 依赖关系需要小心的进行管理
• 交付物:
– UML Diagrams – Layer Diagram – Dependency Graphs – Architecture and Model Explorers
• 团队:
– 5 Feature Crews with 6-8 crew members
我们的开发方式
• 将当前正在运用的优秀实践与敏捷开发的 优秀的实践结合起来应用于我们开发当中
• Altair Basic Interpreter – 微软发布的第一个 产品
微软开发工具事业部概况
• 超过3000 名雇员, 超过 25个产品团队 • 我们的客户
– 非专业开发人员及编程爱好者 – 专业开发人员 – 测试人员 – 设计人员 – 企业级系统架构师
一组很炫的数字
TFS 在微软开发工具事业部的应用 (截止09年6月)
– Scrum – Extreme Programming – Test Driven Development – Kanban, …
传统的软件生命周期管理 vs. 敏 捷
经验分享: Visual Studio Team Architecture团
队的敏捷开发实践
项目概览
• 目标:
– Deliver architectural tools that help customers manage software complexity.
• 我们采用了根据我们具体情况优化过的 Scrum
功能团队
• 一个能够很好的进行自我管理且富有战斗 力的团队通常由2-3个开发人员，2-3个测试 人员和1个项目经理组成
• 团队对所开发的功能或者服务负责
• 基于特定的时间进行迭代开发并发布功能
• 在每次进行代码分支合并以前必须达到质
Scrum
• 以项目管理的实践为核心 • 迭代式开发 • 由一系列的短周期的迭代组成
– 对设计的可测试性提出反馈 – 对设计的复杂性提出反馈 – 验证设计是否满足了需求
• 开发人员在测试计划审核中的作用 质 量计划
– 对测试的重点领域（优先级）提出反馈 – 测试是能够自动化的吗?
代码分支结构
Feature Branch
Team Branch
Feature Branch
VS Main Branch
确定能够被完成和集成的功能列表
产品 Backlog
Sprint Backlog
功能定义
Story Parts …
一个功能定义的例子
一个功能定义的例子 (续…)
Test Comments
PM Comments
Dev Comments
设计文档及测试计划
• 测试人员在设计文档审核中的作用 质 量设计
持续集成
Sprint 测试
• Acceptance Testing
– 验证功能
• Functional Testing
– 验证功能组件
• Integration Testing
– 验证功能组件的组合
• Security Testing • Performance and Stress Testing
• 敏捷是一系列的原则
– 敏捷本身并不代表任何流程或者方法论
* * Ivar Jacobsen
敏捷来自百度文库核心原则
• 为非技术人员及客户提供更好的项目透明 度
• 在开发周期中尽可能早的提供产品的商业 价值
• 尽可能早的接纳客户的反馈
• 创造机会去接纳变化
敏捷的典型实践
• 以下的几组实践的框架都能很好的支持敏 捷的核心原则