交付用户想要的软件

开发的目标应该由客户决定，因此为了让软件符合用户需求，要提早集成，频繁集成，使得代码一直保持可以发布，由于需要一次又一次给用户演示，因此应当提早实现自动化部署。

让客户做决定

开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。

平衡的艺术：

记录客户做的决定，并注明原因

不要用低级别和没价值的问题打扰繁忙的业务人员

不要随意假设低级别的问题不会影响他们的业务

如果业务负责人回答“我不知道”，这也是一个称心如意的答案，也许是他们还没想那么远，也许是他们只有看到运行的实物才能评估结果，尽可能给他们提供建议，实现代码的时候也要考虑可能出现的变化。

让设计指导而不是操作开发

好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节，因此它是目标，而不是具体处方。

如果写得太具体有两个弊端，一是程序员没有代码决定权，只是翻译伪代码，没成就感；二是，花费太多时间，如果项目变动，或者规划有问题，就浪费了大量时间。

平衡的艺术：

在真正代码验证之前，不要陷入太多的设计任务。当对设计一无所知的时候，投入编码也是一件危险的事情

白板、草图、便利贴都是非常好的设计工具，复杂的建模工具只会让你分散精力，而不是启发你的工作

12.合理地使用技术

根据需要选择技术，首先决定什么是你需要的，接着为这些具体的问题评估使用技术，对任何要使用的技术，多问一些挑剔的问题，并真实地回答。

平衡的艺术：

如果没有足够经验，不要急于决定用什么技术，如果再做系统原型，演示给用户看时，可以用散列表代替数据库

每一门技术都有优缺点，需要清楚它的利弊

不要开发那些容易下载到的东西

13.保持可以发布

任何时候进行项目展示时，都能很自信毫不犹豫地给别人演示最新构建的软件。项目一直处于可以运行的稳定状态。

平衡的艺术：

做了一些大改动，需要一个月才能保证发布，这种情况应该只是例外，不能养成习惯

如果不得不让系统长期不可以发布，那么做一个分支版本

14.提早集成，频繁集成

代码集成是主要的风险来源，要想规避这个风险，只有提早集成，持续有规律地进行集成。

平衡的艺术：

成功的集成就意味着所有的单元测试不停地通过

通常每天都要和团队其他的成员一起集成代码好几次。但是如果每次修改就集成，大部分时间花在集成而不是写代码，那么就是集成得太过频繁了

如果不够频繁，也许发现每天都在解决代码集成带来的问题，而不是专心写代码

15.提早实现自动化部署

一开始就实现自动化部署应用，使用部署系统安装你的应用，保证在不同的机器上用不同的配置文件测试依赖的问题。系统的安装或者部署应该简单、可靠及可重复。

16.使用演示获得频繁反馈

清晰可见的开发，在开发的时候保持应用可见（客户心中也要了解）。每隔一周或者两周，邀请所有客户，演示最新完成的功能，积极获得他们的反馈

17.使用短迭代，增量发布

短迭代让人感觉非常专注且具有效率。你能看到一个实际确切的目标。严格的最终期限迫使你做出一些艰难的决策，没有遗留下长期悬而未决的问题。

平衡的艺术：

如果每个迭代周期不够用，要么任务太大，要么迭代周期太短（所以一定要把握自己的节奏和时间）

如果发布功能背离用户需求，多半是因为迭代周期太长了

增量的发布时必须的，并且能为用户提供价值

18.固定的价格意味着背叛承诺

基于真实工作的评估，让团队和客户一起，真正地在当前项目中工作，做的具体实际的评估，由客户控制他们要的功能和预算。