没有任何计划在遇敌后还能继续执行。
我们真正的敌人是变化。
让用户和客户参与开发很重要。
习惯10：让客户做决定
开发者(即项目经理)能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。你不需要给业务上的关键问题做决定，毕竟那不是你的事情。
和客户讨论时，不要从技术的角度，而要从业务的角度介绍每种方案的优缺点，以及潜在的成本和利益。
习惯11：让设计指导而不是操纵开发
设计文档应尽可能的详细。在高层方面，详细描述对象的关联关系，在底层方面，详细描述对象之间的交互。
画关键工作图(用UML)，因为要使用类及其交互关系来描绘系统是如何组织的。然后才是开始编码。
不要把时间浪费在编码前具体细节的设计上。
卡片式设计方法：类名，职责(它应该做什么)，协作者(要完成工作他要与其他什么对象一起工作)
好的设计应该是正确的，而不是精确地。
习惯12：合理的使用技术
根据需要选择技术，不要盲目的选择技术及框架。
这个技术框架真能解决这个问题吗？
你将会被它拴住吗？
维护成本是多多少？
任何技术都会有优点和缺点，一定要清楚它的利弊。
不要开发那些你容易下载到的东西
习惯13：保持可以发布
任何时候只要你没准备好，那就是敌人进攻你的最佳时机。
在团队工作，修改东西时必须很谨慎，你要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。
防范措施：在本地进行测试；检出最新的代码；提交代码
版本控制管理：CVS，Subversion，Git
习惯14：提早集成，频繁集成
代码集成时主要的风险来源，要想规避这个风险，只有提早集成，持续而有规律的集成。
习惯15：提早实现自动化部署
习惯16：使用演示获得频繁反馈
不一致的术语是导致需求误解的一个主要原因。保持清晰可见的开发
习惯17：使用短迭代，增量发布
迭代开发是，在小且重复的周期里，你完成各种开发任务：分析、设计、实现、测试和获得反馈，所以叫做迭代。迭代结束就标记一个里程碑。
软件开发不是精细的制造业，而是创新活动。
对付大项目，最理想的办法就是小步前进，这也是敏捷方法的核心。
询问客户，哪些是使产品可用且不可缺少的核心功能。不要为所有可能需要的华丽功能而分心，不要沉迷与你的想象，去做那些华而不实的用户界面。
使用短迭代和增量开发，可以让开发者更加专注于自己的工作。
习惯18：固定的价格就意味着背叛承诺
方法：主动提议先构建系统最初的、小的和有用的部分，第一次迭代完了让用户选择。