Sam Guckenheimer曾经是VITS的首席客户代言人，负责VSTS外部设计的整个过程。本书描述了他对软件项目思考方式的一个框架，这一思考方式能够得到VSTS工具的直接支持。

　　·Amazon前50名超级畅销书
　　·微软公司授权光盘附增VSTS试用版
　　·微软公司选定的培训教材
　　·为准备使用VSTS的开发团队量身定做
　　　本书不讲述如何具体操作VSTS，而讲述VSTS的思想及其实践。本书不仅包括了最新的软件工程领域的思想和概念，还为软件开发提出了一种崭新的思维方式——价值增加。价值增加本书的核心思想，同时也是VSTS的核心设计理念。
　　本书理论与实例并重，图文并茂，运用大量实例详实地论述了如何将最现代的软件工程思想和价值增加的思想应用到需求、项目管理、架构设计、开发和测试等软件开发生命周期中的各个领域中。
　　本书适合那些正在考虑使用Visual Studio Team System（VSTS）来管理软件项目的团队阅读，也可供软件项目管理人员、开发团队成员学习参考。

　　“这是一本的关于软件工程的第一流著作。在对计划、文档、管制、审计能力和组织等闪光点的讨论中，Sam分别展示了敏捷的和较正式的两种实践的情况，并且还描述了每种情况的理想条件。虽然展示的是使用VSTS的情境，但是其指导性是普遍适用的。”——Bill Curtis博士，Borland软件集团首席过程官
　　“Sam Guckenheimer把我们引入到一个值得信任的透明度的年代，这将对我们管理软件开发项目的方式进行一场革命。” ——David J. Anderson ，《Agile Management for Software Engineering》的作者
　　“本书让我们开阔了眼界：打开了通往软件工程新时代的大门。”——Francis T. Delgado，Avanade公司资深规划经理

第1章价值增加的思维方式
1.1思维变迁
1.1.1有待和谐的三股力量
1.1.2什么软件值得构建
1.2思维方式的对比
1.3对流的关注
1.3.1与工作消减的对比
1.3.2透明度
1.4一个工作项数据库
1.5使过程适合于项目
1.6小结
参考文献
第2章价值增加的过程
2.1微软解决方案框架
2.2迭代
2.2.1为什么迭代
2.2.2长度
2.2.3不同的视野，不同的粒度
2.2.4优先排序
2.2.5修改过程
2.3风险管理
2.4让过程适合项目
2.4.1自适应与计划驱动
2.4.2要求的文档与隐含的知识
2.4.3隐式与显式的审核关卡和管理模型
2.4.4审计与法规关注
2.4.5规定的组织与自组织
2.4.6一次一个项目与一次
多个项目
2.4.7地理边界与组织边界
2.5小结
参考文献
第3章需求
3.1什么是你的愿景
3.1.1战略项目
3.1.2自适应项目
3.2何时细化需求
3.2.1需求是易变质的
3.2.2谁关心需求
3.3人物和应用场景
3.3.1从人物开始
3.3.2应用场景
3.3.3研究技术
3.3.4提早具体化
3.3.5故事板
3.3.6应用场景的宽度
3.3.7客户验证
3.3.8制定应用场景
3.4人物、应用场景及它们的替代术语
3.4.1参与者和用例
3.4.2用户故事
3.5兴奋点、满意点和不满意点
3.6服务质量
3.6.1安全性和隐私
3.6.2性能
3.6.3用户体验
3.6.4可管理性
3.7卡诺分析
3.7.1技术接受生命周期
3.7.2收集数据
参考文献
第4章项目管理
4.1理解偏差
4.2使用描述性的而非规定性的度量元
4.3项目健康的多个维度
4.4回答日常问题
4.4.1剩余工作
4.4.2项目速度
4.4.3计划外工作
4.4.4质量指示器
4.4.5缺陷率
4.4.6重新激活
4.4.7缺陷的优先级
4.4.8实际质量与计划速度
4.5估计迭代
4.5.1自顶向下
4.5.2自底向上
4.5.3精细化
4.5.4 估计的质量
4.5.5回顾
4.6优先分配
4.6.1优先分配的实验
4.6.2什么让优先分配有效率：红线
4.6.3在优先分配中发生了什么
4.6.4逐步增强和解决问题
4.6.5迭代和优先分配
4.7让审计者满意
4.8小结
参考资料
第5章架构设计
5.1架构的价值增加观点
5.2面向服务的架构
5.2.1Web服务和SOA
5.2.2契约优先的设计
5.3自由度的约束
5.3.1基线架构
5.3.2验证架构决策
5.3.3精细化基线
5.3.4参考架构
5.4 VSTS和面向服务的架构
5.5服务质量的理念
5.5.1安全性
5.5.2性能
5.6公民权理念
5.7针对运行而设计
5.8小结
参考文献
第6章开发
6.1开发的价值增加观
6.2从开发者的视点看质量
6.3使用测试驱动的开发来确保需求的清晰
6.4通过自动和手动代码评审来解决编程错误
6.4.1自动的代码分析
6.4.2手动的代码评审
6.5用单元测试和代码覆盖度提供立即的反馈
6.5.1先测试还是先编码？
6.5.2代码覆盖度
6.6使单元测试更好
6.6.1使用数据
6.6.2配置
6.6.3构件集成测试
6.6.4构建确认测试
6.6.5性能调整
6.7防止版本扭曲
6.7.1签入
6.7.2搁置
6.7.3分支
6.7.4哪些文件需要版本管理
6.7.5自动化构建
6.8 让工作保持透明
6.9小结
参考文献
第7章测试
7.1测试的价值增加观
7.2基本问题
7.3我们交付了客户价值吗
7.3.1自动应用场景测试
7.3.2让你的测试与UI变更无关
7.4服务质量适合使用吗
7.4.1负载测试
7.4.2安全性测试
7.4.3易用性测试
7.5我们测试了变更吗
7.6我们没测试过什么吗
7.6.1需求
7.6.2代码
7.6.3风险
7.7软件在生产环境和实验室环境中运行一样吗
7.8我们测试的足够吗
7.8.1定义“足够好”
7.8.2探索测试
7.8.3为发现而测试
7.8.4 错误的自信
7.9我们什么时候应当测试
7.9.1签入循环
7.9.2每日构建循环
7.9.3验收构建循环
7.9.4迭代循环
7.9.5项目循环
7.10哪些测试应当自动化
7.11我们的团队或外包团队的效率怎么样
7.12小结
参考资料
第8章报告缺陷
8.1警示性的故事
8.2软件缺陷的生命周期
8.2.1报告缺陷就像写新闻
8.2.2主观数据
8.2.3客观数据
8.2.4评估数据
8.2.5计划
8.3小结
参考资料
第9章项目问题解析
9.1低估
9.1.1不均匀的任务分解
9.1.2架构盲点
9.1.3范畴蠕变
9.1.4不充分的缺陷分配
9.1.5资源漏洞
9.2开发实践过于松弛
9.2.1构建失败
9.2.2不充分的单元测试
9.2.3重新激活
9.2.4虚报
9.3测试通过了，解决方案却不能工作
9.3.1高缺陷发现率
9.3.2测试失去时效性
9.4解决方案停留在测试
9.4.1测试失败
9.4.2过少的测试
9.5小结
参考资料
第10章总结
10.1预料中的批评
10.2再论价值增加
参考资料