Steve Resnick，是BlueMetal Architects的创始人和总经理，这是一家专注于IT策略、架构、设计和交付的咨询与产品开发公司。BlueMetal Architects使用敏捷方法按时并符合预算地交付产品。在创立BlueMetal Architects之前，Steve是微软技术中心（MicrosoftTechnology Center）的首席技术官（CTO），在那里他负责组织按地理分布的团队来开发解决方案，并将其部署到世界范围内的数据中心。他使用敏捷方法来管理和跟踪大小不一的项目。Steve从20世纪90年代中期就开始使用微软技术工作。他对于高伸缩性的Internet系统、事务处理系统和技术集成经验丰富。他在2008年和别人共同撰写了Essential Windows Communication Foundation一书。
　　
　　Aaron Bjork，是微软的资深程序经理，在TFS团队中负责敏捷实践和工具方面的工作。在2008年加入TFS之前，Aaron在VisualStudio团队中作为一名软件工程师和开发领头人。Aaron热衷于应用程序生命周期管理解决方案，渴望看到团队能够提升软件工程实践。

　　《Scrum敏捷开发高级教程：使用Team Foundation Server 2010》不是一本简单的Scrum方法学的介绍书籍，也不是一本介绍TFS的工具书，而是一本融合了多方面知识的经验性书籍——跟随Scrum的应用步骤介绍TFS的具体用法，跟随TFS的特性功能阐述Scrum的实践。《Scrum敏捷开发高级教程：使用Team Foundation Server 2010》的3位作者是来自不同背景却在TFS和Scrum方面都经验丰富的专家。正因为他们把各自互补的经验总结融入到了《Scrum敏捷开发高级教程：使用Team Foundation Server 2010》中，所以才能清楚地让我们领悟到如何利用TFS这一工具很好地应用Scrum过程，为我们推出优秀的软件提供保障。

　　特性或人员规划的基础是什么？如果项目失控，会在何时知晓？3种项目管理方法学分别这样解决计划的相关问题：
　　瀑布法——计划是可预测的。基于既定的团队和既定的技术，有经验的团队能够预测每个阶段和任务的持续时间。由于所涉及的任务和阶段通常都很复杂，因此这种方法对于项目的失控无法很好地应对。
　　MSF——类似于瀑布法，计划也是可预测的。然而，由于MSF是迭代式的，会包含很多频繁的发布，计划出现失控可以更容易地处理。随后的发布可以添加或删除相应的特性来应对前面的影响。
　　Scrum——计划是以经验为根据做出的。工作基于Scrum团队的速度进行规划。随着持续不断的冲刺进行，基于完成的实际工作情况，估计会变得越来越准确。由于采用了固定期限的冲刺，规划会非常可靠。不过由于特性可以添加到冲刺中或从冲刺中移除，而发布又要适应固定的周期，因此功能范围就会缺乏可靠性。
　　1.3.4 人员
　　团队如何组织？人们何时加入或离开项目？3种项目管理方法学分别这样解决人员相关的问题：
　　瀑布法——在项目的不同阶段会有专门的团队投入工作。在技术专家被分配到项目中之前，业务分析师就需要在项目早期完成需求定义工作。一旦开发工作开始，业务分析师就成为一个次要的角色。测试工作在开发工作完成之后开始。项目管理是一个专门的角色，通常由项目管理部门指派。
　　MSF——专门的团队会投入项目不同方面的工作中，不过都是同时工作。角色被明确地定义，涵盖以可预测的方式构建和推出产品必需的所有方面。团队中的所有人都是互相平等的，以各自的职责为每个阶段做出贡献。
　　……

第1章 软件产品的推出
1.1 推出软件产品需要做什么
1.1.1 构思愿景
1.1.2 深入认识
1.1.3 筹备资源
1.1.4 规划进度
1.1.5 实现特性
1.2 项目管理方法
1.2.1 Scrum
1.2.2 MSF
1.2.3 瀑布法
1.3 方法学比较
1.3.1 产品定义
1.3.2 适应性
1.3.3 计划
1.3.4 人员
1.3.5 文档
1.3.6 项目周期
1.4 小结

第2章 组织Scrum团队
2.1 Scrum角色
2.1.1 Scrum MaSter
2.1.2 产品所有者
2.1.3 团队成员
2.2 扩展Scrum团队规模
2.2.1 团队专业化分工
2.2.2 Scrum of Scrums会议
2.2.3 产品积压工作
2.2.4 冲刺同步
2.2.5 统一架构
2.3 MSF和Scrum的对比
2.3.1 产品经理
2.3.2 程序经理
2.3.3 开发经理
2.3.4 QA经理
2.3.5 培训经理
2.3.6 发布经理
2.4 Scrum中的IT角色
2.4.1 项目经理
2.4.2 架构师
2.4.3 发布管理
2.4.4 QA经理
2.5 转变为Scrum
2.5.1 增强用户参与
2.5.2 减少文档撰写
2.5.3 简化计划安排
2.5.4 尽早发现问题
2.6 小结

第3章 在TFS中跟踪重要信息
3.1 了解TFS中的数据
3.2 选择Scrum
3.3 Scrum工件
3.3.1 产品积压工作
3.3.2 冲刺积压工作
3.3.3 冲刺燃尽
3.3.4 发布燃尽
3.4 Scrum活动
3.4.1 发布计划会议
3.4.2 积压工作梳理
3.4.3 冲刺
3.4.4 冲刺计划会议
3.4.5 每日Scrum会议
3.4.6 冲刺审查会议
3.4.7 冲刺回顾会议
3.5 小结

第4章 开始使用TFS Scrum模板
4.1 开始使用Scrum模板
4.1.1 下载并安装Scrum模板
4.1.2 把Scrum模板导入到TFS中
4.1.3 创建新的PBI
4.2 了解发布
4.2.1 发布计划会议
4.2.2 验收标准
4.2.3 PBI相关的其他信息
4.2.4 计划扑克
4.2.5 发布燃尽图
4.2.6 发布目标
4.3 交付的重要性
4.4 质量的重要性
4.5 确保可重复性
4.6 了解冲刺
4.6.1 划分PBI优先级
4.6.2 决定发布时间表
4.6.3 了解Spike
4.7 小结

第5章 工作项、查询和报表
5.1 工作项
5.1.1 Area Path和Iteration Path字段
5.1.2 产品积压工作条目
5.1.3 任务
5.1.4 冲刺
5.1.5 障碍
5.1.6 Bug
5.1.7 测试用例
5.1.8 共享步骤
5.2 工作项查询
5.2.1 查询类型
5.2.2 内置工作项查询
5.3 报表
5.3.1 Scrum报表
5.3.2 工程报表
5.3.3 制作自定义报表
5.4 小结

第6章 产品积压工作
6.1 管理产品积压工作
6.2 创建PBI并划分优先级
6.2.1 创建PBI的工具选择
6.2.2 PBI的工作流程
6.2.3 划分PBI优先级
6.2.4 录入PBI信息
6.3 连接工件：PBI、任务和Bug
6.3.1 将PBI连接到测试用例
6.3.2 将PBI连接到Bug
6.3.3 将Bug连接到PBI
6.3.4 将Bug连接到测试用例
6.3.5 将PBI连接到任务
6.3.6 将任务连接到PBI
6.3.7 将任务连接到Bug
6.3.8 未完成工作查询的使用
6.4 理解障碍
6.5 小结

第7章 跟踪质量
第8章 执行发布
第9章 执行冲刺
第10章 回顾会议
第11章 利用Spike改进Scrum
附录A
附录B