本书第四章讲的是“交付用户想要的软件”，目前我还是个学生，没有与用户打交道的任何经验。所有总结了如下几点：
1、 让客户做决定
a.让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
2、让设计指导而不是操纵开发
a.一旦开始了编码，一切都会改变。设计及其代码实现会不停地发展和变化。
b.好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。
c.即使初始的设计到后面不再管用，你仍需设计：设计行为是无价的。正如美国总统艾森豪威尔所说：“计划是没有价值的，但计划的过程必不可少。”在设计过程中学习是有价值的，但设计本身也许没有太大的用处。
3、 合理地使用技术
a.考虑引入新技术或框架之前，要先考虑几个方面：
b.这个技术框架真能解决这个问题吗？
c.你将会被它拴住吗？一些技术是贼船，一旦你使用了它，就会被它套牢，再也不可能回头了。
d.维护成本是多少？
e.每一门技术都会有优点和缺点，无论它是开源的还是商业产品、框架、工具或语言，一定要清楚它的利弊。
4、 保持可以发布
a.任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。
b.在团队里工作，修改一些东西的时候必须很谨慎。你要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。
5、 提早集成，频繁集成
a.绝不要做大爆炸式的集成。
b.提早集成，频繁集成。代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。
c.如果你集成得不够频繁（比如一周一次，甚至更糟），也许就会发现整天在解决代码集成带来的问题，而不是在专心写代码。如果你集成的问题很大，那一定是做得不够频繁。
6、 提早实现自动化部署
a.一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。
b.部署一个紧急修复的bug 应该很简单，特别是在生产服务器的环境中。你知道这会发生，而且你不想在压力之下，在凌晨三点半，你还在手工部署系统。
7、 使用演示获得频繁反馈
a.维护一份项目术语表。在项目的开发过程中，从术语表中为程序结构——类、方法、模型、变量等选择合适的名字，并且要检查和确保这些定义一直符合用户的期望。
b.清晰可见的开发。在开发的时候，要保持应用可见（而且客户心中也要了解）。每隔一两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
8、 使用短迭代，增量发布
a.增量开发。发布带有最小却可用功能块的产品。每个增量开发中，使用1 ～ 4 周左右迭代周期。
9、 固定的价格就意味着背叛承诺
a.软件项目天生就是变化无常的，不可重复。如果要提前给出一个固定的价格，就几乎肯定不能遵守开发上的承诺。
b.基于真实工作的评估。让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算
总结：编程是面向用户编程的，客户的需求是我们编程的目的，我们要尽可能满足客户的要求，交互出客户需要的系统或者软件。