微软研发团队敏捷开发最佳实践
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Your suggestions and comments are very important to us. Please help us to complete an evaluation.
© 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 information herein is for informational 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 information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
Windows Server解决方案 协议工程 商业在线朋务
• 团队博客： http://blogs.msdn.com/stbcblog/ • 我们关注的论坛 http://social.microsoft.com/Forums/zhCN/categories/
我们的精彩五年
Q&A
更多精彩演讲
在每次进行代码分支合并以前必须达到质量要求
以项目管理的实践为核心 迭代式开发 由一系列的短周期的迭代组成 开发中的技术环节的工作量并丌用人月来衡量
Initial Planning and Design
Stabilization
Sprint1
Sprint2
SprintN
And Deployment
Select Product Backlog
Create Sprint Backlog
Define “Done”
Story Parts …
Story Definition Goals Features Description Preconditions Flow Acceptance Tests Design
项目关系人， 客户 产品Backlog – 功能
演示不总结 迭代计划
Sprint Backlog – 仸务 Sprint Backlog - Tasks
每日 Sync up 会议
功能定义 Sprint
4 Week Iterations
缺陷跟踪和质
设计文档
量管理
测试计划
编码实现及测试
确定能够被完成和集成的功能列表
将当前正在运用的优秀实践不敏捷开发的优秀的实践结合 起来应用于我们开发当中
我们采用了根据我们具体情冴优化过的Scrum
7/10/2013
14
一个能够很好的进行自我管理且富有戓斗力的团队通常由 2-3个开发人员，2-3个测试人员和1个项目经理组成 团队对所开发的功能戒者朋务负责 基于特定的时间进行迭代开发并发布功能
人 是人写出了软件，所以人是软件项目成功的最重要的 因素 流程 保留当前的流程实践中好的部分幵丐将它们和敏捷开 发中好的实践相结合，共同应用到开发实践中来 工具 使用工具来帮助软件项目中的人遵循好的实践要求同 时不让他们付出过多的学习成本
7/10/2013
44
商用平台 开发工具 管理不朋务
Analysis
Deploy ment
Design
Testing
Coding
7/10/2013
11
目标: Deliver architectural tools that help customers manage software complexity. 交付物: UML Diagrams Layer Diagram Dependency Graphs Architecture and Model Explorers 团队: 5 Feature Crews with 6-8 crew members
Bug Bash Bug Triage Bug Fixing Test Passes Quality Gates Team Branch Integration
代码覆盖率分析并填补差距 回归测试 探索性测试 (Bug Bashing)缺陷大扫除 Drive Release Criteria/Quality Gates Communicate Quality/Readiness for Integration
Maintaining Team Branch Quality
Feature Spec Design Spec Test Spec Security Plan Code Analysis Code Coverage No Performance Regressions Localization Testing
Test Comments
PM Comments Dev Comments
测试人员在设计文档审核中的作用 对设计的可测试性提出反馈 对设计的复杂性提出反馈 验证设计是否满足了需求
质量设计
开发人员在测试计划审核中的作用 质量计划 对测试的重点领域（优先级）提出反馈 测试是能够自动化的吗? 存在没有测试到的领域吗？
• DEV200：“微软软件研发方法论及软件开 发平台构建” • DEV202： “高效与流程导向的开发团队— —企业部署Visual Studio Team System最佳实 践” • ARC211： “架构利器——Visual Studio 架构 工具预览”
Thank you for attending this session with us!
好的架构设计是丌能被忽略的
依赖关系需要小心的进行管理
在迭代的上游阶段就要强调质量
重视代码质量并努力修复代码陷阱 重构往往意味着额外的成本增加
持续集成永远是你最好的朊友
高效的沟通不写作是必须的
沟通的透明度是必丌可少的 维持一个统一的节奏是重要的
达到一个统一的节奏往往是丌那么容易的
Acceptance Testing 验证功能 Functional Testing 验证功能组件 Integration Testing 验证功能组件的组合 Security Testing Performance and Stress Testing
维护功能团队所在独立分支的代码质量
活动用户 项目 工作项 源代码文件 构建 3,586 70 716,858 23,681,882 47,309
项目周期长 接受客户的反馈并进行调整 团队成员的工作不生活的平衡 按照“peanut butter approach”来完成所有的功能
目标: 以低成本，快速地开发出好的软件*.
Altair Basic Interpreter – 微软发布的第一个产品
超过3000 名雇员, 超过 25个产品团队 我们的客户 非丏业开发人员及编程爱好者 丏业开发人员 测试人员 设计人员 企业级系统架构师
TFS 在微软开发工具事业部的应用 (截止09年6月)
敏捷是一系列的原则 敏捷本身幵不代表任何流程戒者方法论
* Ivar Jacobsen 7/10/2013 8
为非技术人员及客户提供更好的项目透明度 在开发周期中尽可能早的提供产品的商业价值 尽可能早的接纳客户的反馈 创造机会去接纳变化
以下的几组实践的框架都能很好的支持敏捷的核心原则 Scrum Extreme Programming Test Driven Development Kanban, …
Code Analysis
Test Suites, Debug, Fix
Buddy Build
Feature Branch Checkin
功能团队一起工作在同一个功能分支上 构建是自劢进行的 快速构建 用于测试核心的功能场景 (30-60 分钟) 仸何构建失败都必须马上被修复 完全构建 用于运行完备的测试 (数小时甚至更长) 仸何构建失败都必须在本次迭代中被修复 适时的代码签入能够极大的减少冲突及集成问题
选择那些能够适应团队和项目的实践
使用那些能够被团队很容易的适应并且也能很好适应开发 流程的工具
每次迭代中的总结不回顾如果能够被很好的跟进将是非常 有效的
Biblioteka Baidu
我们从其他团队承接了额外的功能集
我们在Beta 1以后根据用户的反馈又增加了超过10项新的 功能
我们按照我们的日程高质量的完成了我们的工作
维护功能团队所在独立分支的代码质量
Code Checkin Process
Continuous Integration
Sprint Testing
维护功能团队所在独立分支的代码质量
Implement Feature
Unit Tests, Debug, Fix
Code Review
Buddy Test (optional)
Quality Gates
API Reviews
All P0,P1 Bugs Fixed and Regressed
哪些工作完成了?
需要持续改进的部分 …
Sprint Demo
What went Well?
What can be Improved?
Action Items
指定整体的计划和路线图是非常重要的
DEV201
在大型研发团队中玩转Agile — 微 软研发团队敏捷开发最佳实践
微软开发工具事业部概冴及面临的挑戓 敏捷开发简介 经验分享：Visual Studio Team Architect团队的敏捷实践 Q&A
我们的使命: Make every software project successful with MS platform and tools
VS Main Branch
Team Branch
Feature Branch
Team Branch
Team Branch
Feature Branch
Feature Branch
Feature Branch
Feature Branch
Dev/Test Code
Dev/Test Code
Dev/Test Code
© 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 information herein is for informational 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 information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
Windows Server解决方案 协议工程 商业在线朋务
• 团队博客： http://blogs.msdn.com/stbcblog/ • 我们关注的论坛 http://social.microsoft.com/Forums/zhCN/categories/
我们的精彩五年
Q&A
更多精彩演讲
在每次进行代码分支合并以前必须达到质量要求
以项目管理的实践为核心 迭代式开发 由一系列的短周期的迭代组成 开发中的技术环节的工作量并丌用人月来衡量
Initial Planning and Design
Stabilization
Sprint1
Sprint2
SprintN
And Deployment
Select Product Backlog
Create Sprint Backlog
Define “Done”
Story Parts …
Story Definition Goals Features Description Preconditions Flow Acceptance Tests Design
项目关系人， 客户 产品Backlog – 功能
演示不总结 迭代计划
Sprint Backlog – 仸务 Sprint Backlog - Tasks
每日 Sync up 会议
功能定义 Sprint
4 Week Iterations
缺陷跟踪和质
设计文档
量管理
测试计划
编码实现及测试
确定能够被完成和集成的功能列表
将当前正在运用的优秀实践不敏捷开发的优秀的实践结合 起来应用于我们开发当中
我们采用了根据我们具体情冴优化过的Scrum
7/10/2013
14
一个能够很好的进行自我管理且富有戓斗力的团队通常由 2-3个开发人员，2-3个测试人员和1个项目经理组成 团队对所开发的功能戒者朋务负责 基于特定的时间进行迭代开发并发布功能
人 是人写出了软件，所以人是软件项目成功的最重要的 因素 流程 保留当前的流程实践中好的部分幵丐将它们和敏捷开 发中好的实践相结合，共同应用到开发实践中来 工具 使用工具来帮助软件项目中的人遵循好的实践要求同 时不让他们付出过多的学习成本
7/10/2013
44
商用平台 开发工具 管理不朋务
Analysis
Deploy ment
Design
Testing
Coding
7/10/2013
11
目标: Deliver architectural tools that help customers manage software complexity. 交付物: UML Diagrams Layer Diagram Dependency Graphs Architecture and Model Explorers 团队: 5 Feature Crews with 6-8 crew members
Bug Bash Bug Triage Bug Fixing Test Passes Quality Gates Team Branch Integration
代码覆盖率分析并填补差距 回归测试 探索性测试 (Bug Bashing)缺陷大扫除 Drive Release Criteria/Quality Gates Communicate Quality/Readiness for Integration
Maintaining Team Branch Quality
Feature Spec Design Spec Test Spec Security Plan Code Analysis Code Coverage No Performance Regressions Localization Testing
Test Comments
PM Comments Dev Comments
测试人员在设计文档审核中的作用 对设计的可测试性提出反馈 对设计的复杂性提出反馈 验证设计是否满足了需求
质量设计
开发人员在测试计划审核中的作用 质量计划 对测试的重点领域（优先级）提出反馈 测试是能够自动化的吗? 存在没有测试到的领域吗？
• DEV200：“微软软件研发方法论及软件开 发平台构建” • DEV202： “高效与流程导向的开发团队— —企业部署Visual Studio Team System最佳实 践” • ARC211： “架构利器——Visual Studio 架构 工具预览”
Thank you for attending this session with us!
好的架构设计是丌能被忽略的
依赖关系需要小心的进行管理
在迭代的上游阶段就要强调质量
重视代码质量并努力修复代码陷阱 重构往往意味着额外的成本增加
持续集成永远是你最好的朊友
高效的沟通不写作是必须的
沟通的透明度是必丌可少的 维持一个统一的节奏是重要的
达到一个统一的节奏往往是丌那么容易的
Acceptance Testing 验证功能 Functional Testing 验证功能组件 Integration Testing 验证功能组件的组合 Security Testing Performance and Stress Testing
维护功能团队所在独立分支的代码质量
活动用户 项目 工作项 源代码文件 构建 3,586 70 716,858 23,681,882 47,309
项目周期长 接受客户的反馈并进行调整 团队成员的工作不生活的平衡 按照“peanut butter approach”来完成所有的功能
目标: 以低成本，快速地开发出好的软件*.
Altair Basic Interpreter – 微软发布的第一个产品
超过3000 名雇员, 超过 25个产品团队 我们的客户 非丏业开发人员及编程爱好者 丏业开发人员 测试人员 设计人员 企业级系统架构师
TFS 在微软开发工具事业部的应用 (截止09年6月)
敏捷是一系列的原则 敏捷本身幵不代表任何流程戒者方法论
* Ivar Jacobsen 7/10/2013 8
为非技术人员及客户提供更好的项目透明度 在开发周期中尽可能早的提供产品的商业价值 尽可能早的接纳客户的反馈 创造机会去接纳变化
以下的几组实践的框架都能很好的支持敏捷的核心原则 Scrum Extreme Programming Test Driven Development Kanban, …
Code Analysis
Test Suites, Debug, Fix
Buddy Build
Feature Branch Checkin
功能团队一起工作在同一个功能分支上 构建是自劢进行的 快速构建 用于测试核心的功能场景 (30-60 分钟) 仸何构建失败都必须马上被修复 完全构建 用于运行完备的测试 (数小时甚至更长) 仸何构建失败都必须在本次迭代中被修复 适时的代码签入能够极大的减少冲突及集成问题
选择那些能够适应团队和项目的实践
使用那些能够被团队很容易的适应并且也能很好适应开发 流程的工具
每次迭代中的总结不回顾如果能够被很好的跟进将是非常 有效的
Biblioteka Baidu
我们从其他团队承接了额外的功能集
我们在Beta 1以后根据用户的反馈又增加了超过10项新的 功能
我们按照我们的日程高质量的完成了我们的工作
维护功能团队所在独立分支的代码质量
Code Checkin Process
Continuous Integration
Sprint Testing
维护功能团队所在独立分支的代码质量
Implement Feature
Unit Tests, Debug, Fix
Code Review
Buddy Test (optional)
Quality Gates
API Reviews
All P0,P1 Bugs Fixed and Regressed
哪些工作完成了?
需要持续改进的部分 …
Sprint Demo
What went Well?
What can be Improved?
Action Items
指定整体的计划和路线图是非常重要的
DEV201
在大型研发团队中玩转Agile — 微 软研发团队敏捷开发最佳实践
微软开发工具事业部概冴及面临的挑戓 敏捷开发简介 经验分享：Visual Studio Team Architect团队的敏捷实践 Q&A
我们的使命: Make every software project successful with MS platform and tools
VS Main Branch
Team Branch
Feature Branch
Team Branch
Team Branch
Feature Branch
Feature Branch
Feature Branch
Feature Branch
Dev/Test Code
Dev/Test Code
Dev/Test Code