这条玉律在厨房里面的说法是：“在开始做下一道菜前，先把当前这道菜上给客户”。软件开发最大的问题是一大堆事情并发进行，因此其中的一些工作就不可避免地会在后期被丢弃，这就意味着努力被浪费。
先专注于案例1；使它完全能够正常工作；运行相关的测试；书写与之关联的文档；嵌入所有相关的代码；然后才能开始下一个任务；
非常明显，这一条建议应该被包含在任何一个关于软件开发建议的列表中；如果一个程序员在嵌入前做了所有适当的预防措施，进行了足够的测试，是绝不会导致构建失败的；如果构建失败了，说明有人想走捷径；
当编写某个类的时候，你应该在脑海中有一个与之对应的使用案例，同时你应该只提供对这个使用案例来说是必需的方法。有时候程序员会考虑这个类潜在需要的一些功能，此时你应该把这些考虑作为注释加在旁边，但是决不要写任何代码，直到这些潜在功能真正被需要用到的时候；
- l 决不要在某个使用案例真正需要之前，去添加一个数据成员
这一条建议跟前面一条一样，只是它的对象变成了类的数据成员。有时候可能看起来很明显某条“用户”纪录将会在某处被使用；但是你绝对不应该去添加那个数据成员，直到你有一个具体的使用案例明确地要用到这个数据；
敏捷软件开发的精要就是应对不确定性和快速响应变化。在开发工作的前期，你可能没有获得完整的信息，因此你应该尽可能延迟做决定；但是有的时候这个决定不得不做以便开发工作能够继续，你没法再继续等待下这个决定所需要的所有信息了；此时，你应该根据手头所掌握的信息先做个你认为是最好的决定，然后在获得更多的信息之后，也要有勇气去改变之前的决定；
质量的改进是永无止境的，因此你应该坚持不懈地寻求可以被改进的地方，同时要注意收集识别和定位软件质量问题的方法。
敏捷开发是用来帮助团队应对未来之不确定性的方法，但是对已经发生的事情，是不应当存在不确定性的；所以各种类型的尝试应该持续不断地开展，同时每次尝试都应该有纪录，以此来度量其成效；
开发人员太容易把设计目标转向技术可能性方面了。实际上最重要的是人，我们永远不要忘了软件的最终目的，是帮助某些人更好的完成工作；
很多开发人员和经理们认为产品只是你提交给客户的功能及相关代码，其它一切都是不重要的；事实上测试代码应该被作为产品不可分割的一部分予以考虑，它值得在设计阶段就开始进行全面地考量，在很多情况下，甚至应该作为最终产品的一起提交给客户；
测试用例本身能被用来澄清一个设计的最终意图；而且在很多情况下，设计的缺陷会在完成测试用例的时候被发现。想想看在编码之前先书写测试用例的话，能有多少时间被节省下来。但是要记住：先写用例1的测试，然后编写用例1的代码，这些都要在开始用例2之前完成；
坦白地说，这已经成了一个在任何软件开发原则中都会被提到的陈词滥调，因为它确实太重要了。发现并且消灭软件开发过程中的浪费是一个永无止境的工作。任何不增加最终用户价值的付出都是浪费，如果你不能确信它对最终用户有什么价值的话，很可能你将不需要它。
请理解这样一个事实：一旦构建失败了，项目团队中的每一个人都会受到影响，因此没有什么事情比确保核心代码能被正确构建和测试更重要了。我曾经看到过一些团队允许构建失效延续几个月，因为每个人都认为它是别人的责任，每个人都忍受痛苦，却没有人采取行动解决问题。在这方面一点小小的努力会使整个团队都受益，应该成为团队的共识。
大的，复杂的项目应该被拆分成一个个小的项目团队，并且在小团队内部进一步被分发到一个个程序员手上；但在这个过程中，决不能失去对整个产品最终目的和最终用户需求的理解；人们应该时刻把目光聚焦在满足最终用户需求的目标上面。
组织代码，使高度关联的事物位于相近的位置，如果有可能的话，最好把它们放在一个类里面。这是面向对象设计原则的规则之一 - 封装，理想的情况下，所有在类外部的代码，都不需要知道类的内部是如何工作的。有些程序员为了某种目的很喜欢在不同的文件之间传递一些细节信息，譬如为了保持所有相同的数据类型在一起，或者为了按照字母顺序排列。诸如此类的操作会给系统带来不必要的复杂性。所以指导原则是把不相关联的东西分组，以此来降低系统的复杂度。
【译者】有的人把这句话理解为Check in之前运行所有的单元测试，有的人理解为运行test cases，实际上个人认为这些都应该在check in之前运行。
从微观层面来说，代码确实应该按照最优方法来写以避免无谓的浪费，然而对于超出方法层面的优化，则应该等到整个系统经历了压力测试之后开展，而且这种压力测试是基于某个具体的用户使用案例的。
如果只基于对静态代码的理解，就做出对系统整体性能的直觉判断，几乎总是错误的。相反，对整个系统的性能进行度量，识别出那些确实对系统性能有重要影响的1%的代码，并且专注于优化这一部分代码，才是王道。
当一个开发人员实现一个使用案例的时候，所有被改动过的，但是没有改动完成或者没有经过测试的代码，都会产生代价。允许这些完成一半的变更持续存在几天或者几个星期，会显著增加工作量被浪费的风险，因为其中很多半成品最终可能不得不重做。
假设有3个任务，每个需要1天来完成，若同时启动这3个任务，在3天内每天都并发处理它们，这样会导致9个工作单元的开销。如果顺序处理这3个任务，每天完成一个，在前面的任务完成之前，并不开始下一个任务，这样只会导致3个工作单元的开销；
这跟我们的直觉并不相符，直觉告诉我们当有3件事情需要处理的时候，可能同时开展3件事情的是比较合理的；然而软件开发跟物理的建设并不相同，短周期的，快速的，完整的任务不仅会减轻认知上的负载，而且会减少几个人之间未完成工作的相互冲突。
完成一个特定任务所需要的代码行数，不同的程序员之间会有巨大的差异。代码行数并不会告诉你太多关于任务完成情况或者代码质量方面的信息。导致代码质量不同的因素可能多达200个，这使得计算代码行数变得毫无意义；如果要计数的话，就用使用案例吧。
在应用这条规则的时候要小心谨慎，因为有些代码实在是太脆弱了，这使得改变它们变得很困难，但是总体原则是你要使这些代码跟真实的使用案例相匹配，所以不应该害怕去改变它们；一个数据成员在过去可能是一个整数，但是当使用案例需要它成为一个浮点数的时候，请不要犹豫，去改变它。
当涉及大块不容易理解的代码时，有一种倾向：“让睡着了的狗躺在那吧”；其中一个例子就是在往一个类里面添加新的方法替代老方法时，很多开发人员会保留旧有的方法以防万一。这种情况下，我们应该额外付出一些努力去检查老方法是否依然必要，如果没有证据显示非要保留它不可的话，就应该将其删掉；
最糟糕的改动就是把一大段代码注释掉，然而却不把它们删除。被注释掉的代码，应该在单元测试成功运行之后，代码签入之前，立即被删除。在任何时候添加代码都是容易的，然而任何时候删除代码都是困难的，因此，如果在某刻，你认识到可能有些东西是没有必要的，就应该额外花一点时间去确认这段代码确实可以被删除，这将提高代码的可维护性。
一个例子是往配置文件中添加了太多的最终用户看不懂的东西。
- l 除非你真正准备开始编码，并且打算测试你的变更，否则不要设计
你应该对于系统将要做什么，系统架构的目标是什么有个粗略的理解，但是除非到了开发迭代允许某个具体的设计被实现并且测试的时候，你都不应该进行详细设计，也不要把关于某个功能实现的具体描述写下来。
详细设计仅需要覆盖刚刚好能够满足当前使用案例需要的内容。软件开发中最大的浪费就是花了很多时间在不需要的详细设计事宜上，或者是由于错误的假设而导致的重新设计。
跟物质的加工不同，软件是能够被很容易地进行重大变更的。实际上有足够的证据证明，软件本身相对于用来描述该软件的设计文档，更容易被改变。进一步说，就是软件本身比说明文档更能够说明它是被设计来做什么的。因此，你应该把时间花在直接实现上，这样客户就能够亲眼看到最终设计细节。如果你未能满足客户要求，不得不改变最初的设计，直接变更软件本身要比变更说明文档更加容易。更重要的是，当客户看过系统运行以后，你所得到的关于他们希望系统如何运行的信息要清晰得多！
- l 在检测和报告异常情况的代码中，花时间添加一个完整的问题描述
程序员通常会懒得添加说明，以至于在抛出的异常中，只有非常简浅的关于问题的描述。他们以为自己是唯一一个会看到这个问题的人，而且认为自己会根据这个含糊的描述想起该问题的详细情形。事实上，由于不正确的，或者是不完整的错误描述导致的客户支持开销，比任何其它的原因都要高。所以对每一个错误信息的描述，你都应该假设自己在对刚走进房门的，对编码没有任何经验的陌生人解释该问题。毕竟，最终用户以及客户支持部门，对编码是没有任何经验的。
