• 让客户做决定
• 让设计指导而不是操纵开发
• 合理的使用技术
• 提早集成，频繁集成，降低新代码集成带来的破坏性变化
• 一直保持可以发布
• 提早实现自动化部署
• 使用演示获得频繁反馈
• 使用短迭代，增量发布

10 让客户做决定

开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。

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

11 让设计指导开发而不是操纵开发

设计满足实现即可，不必过于详细
Design should be only as detailed as needed to implement

严格的需求—设计—代码—测试开发流程源于理想化的瀑布式②开发方法，它导致在前面进行了过度的设计。这样在项目的生命周期中，更新和维护这些详细的设计文档变成了主要工作，需要时间和资源方面的巨大投资，却只有很少的回报。我们本可以做得更好。

设计可以分为两层：战略和战术。前期的设计属于战略，通常只有在没有深入理解需求的时候需要这样的设计。更确切地说，它应该只描述总体战略，不应深入到具体的细节。

良好的战略设计应该扮演地图的角色，指引你向正确的方向前进。任何设计仅是一个起跑点：它就像你的代码一样，在项目的生命周期中，会不停地进一步发展和提炼。

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

CRC（类—职责—协作）卡片的设计方法

• 类名
• 职责：它应该做什么？
• 协作者：要完成工作它要与其他什么对象一起工作？

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

12 合理的使用技术

盲目地为项目选择技术框架，就好比是为了少交税而生孩子。

每一门技术都会有优点和缺点，无论它是开源的还是商业产品、框架、工具或者语言，一定要清楚它的利弊。

13 保持可以发布

下面是一个简单的工作流程，可以防止你提交破坏系统的代码。

本地运行测试
检出最新的代码
提交代码

14 提早集成，频繁集成

敏捷的一个主要特点就是持续开发。

15 提早实现自动化部署

提早在客户的机器上进行部署，避免最后部署时才发现问题。同时也要实现自动化部署。

质量保证人员应该测试部署过程
QA should test deployment

一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。

16 使用演示获得频繁反馈

定期地，每隔一段时间，例如一个迭代的结束，就与客户会晤，并且演示你已经完成的功能特性。

要频繁地获得反馈。如果你的迭代周期是一个季节或者一年（那就太长了），就应把周期缩短到一周或者两周。完成了一些功能和特征之后，去积极获得客户的反馈。

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

17 使用短迭代，增量发布

确定使产品可用的核心功能，然后把它们放在生产环境中，越早交到用户的手里越好。

即使是美国国家航空航天局（NASA）也使用迭代和增量开发方式开发用于航天飞机的复杂软件。

根据项目的大小，理想的发布周期是几周到几个月。在每个增量开发周期里，应该使用短的迭代（不应该超过两周）。每个迭代都要有演示，选择可能提供反馈的用户，给他们每人一份最新的产品副本。

关于迭代时间长短一直是一个有争议的问题。
有时团队无法在开发新的代码的同时又要维护很多已经完成了的代码。解决方案是，在每4周的迭代中间安排一周的维护任务。没有规定说迭代必须要紧挨着下一个迭代。

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

固定价格的合同会是敏捷团队的一大难题。我们一直在谈论如何用持续、迭代和增量的方式工作。但是现在却有些人跑过来，想提早知道它会花费多少时间及多少成本。

试试下面的办法。
主动提议先构建系统最初的、小的和有用的部分（用建筑来打个比方，就是先做一个车库）。挑选一系列小的功能，这样完成第一次交付应该不多于6~8周。向客户解释，这时候还不是要完成所有的功能，而是要足够一次交付，并能让用户真正使用。

第一个迭代结束时客户有两个选择：可以选择一系列新的功能，继续进入下一个迭代；或者可以取消合同，仅需支付第一个迭代的几周费用，他们要么把现在的成果扔掉，要么找其他的团队来完成它。

如果他们选择继续前进。那么这时候，应该就能很好地预测下一个迭代工作。在下一个迭代结束的时候，用户仍然有同样的选择机会：要么现在停止，要么继续下一个迭代。

对客户来说，这种方式的好处是项目不可能会死亡。他们可以很早地看到工作的进度（或者不足之处）。他们总是可以控制项目，可以随时停止项目，不需要缴纳任何的违约金。他们可以控制先完成哪些功能，并能精确地知道需要花费多少资金。总而言之，客户会承担更低的风险。
而你所做的就是在进行迭代和增量开发。

敏捷不是意味着“开始编码，我们最终会知道何时可以完成”。你仍然需要根据当前的知识和猜想，做一个大致的评估，解释如何才能到达这个目标，并给出误差范围。