3. 敏捷原则
在这个章节，我们来具体检查12条原则。每一条都被编号和命名，以方便参考。（这些名字是我自己从XP那里偷来的。）
#1 交付价值：“我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。”。就象以前芝加哥的很早投票和经常投票的投票者，这条原则要求及早并持续集成和交付。关于草图式建模（modeling-as-sketches），最明显的批评就是只能进行同行评审。就象Bertrand Meyer在〔8〕里所说的，模型不会告诉你它是否是正确的，但是代码会。
可执行模型避免了这个问题，因为它们可以根据真实的输入得到真实的输出。这意味着我们得到了来自真实的正在运行的系统的反馈。
#2 利用变化：“即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。”反馈暗示着变化。我们不可能抵挡住变化，只能利用它们。
合作胜过“合同谈判”的要点是，敏捷过程需要由用户来决定需要哪些功能，以及按照怎样的顺序构造它们。比如，SCRUM，提供了两组卡片来记录功能。一组卡片提供了整个系统的有顺序的功能集，另一组卡片则记录了在当前30天冲刺要被执行的那些功能。作为必须的，客户和开发者争相去重新排列这些卡片，也就是这些功能的相对优先级。
#3 经常发布：“经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。” 结构化分析的先驱者之一Steve Mcmenamin曾经说过，一个项目如果在18个月之内无法发布，那个这个项目已经死了。现在，甚至18个星期看起来也象一个很长的时间。敏捷过程建议尽可能把你的迭代过程做得短，尽管每次迭代的时间不是完全的相同。
“交付（delivery）” 并不总是意味着“发布（release）”。“交付”是内部的，面向团队的，而“发布”是外部的，面向客户的。一个客户没有必要每三个星期就得到一个新的产品，但是我们自己的团队应该可以尽可能经常使用集成的系统，因为这样可以增强我们自己对产品的信心。
可执行模型就是可运转的软件。
#4 现场客户：“在整个项目开发期间，业务人员和开发人员必须天天都工作在一起。”。这个原则的目的是利用变化。（参见#2原则）。在一个实时的和封闭的环境中一起工作，意味着开发者和硬件工程师，操作人员，甚至是市场部门，一起工作，从而保证我们的确是在构造一个正确的系统。这个原则也有助于建立相互之间的信任。
一起工作是重要的。相比其他方式，它让非软件专业的知识成为工作的一个部分。
#5 信任有活力的团队：“围绕有活力的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。”构造一个产品时，有两样东西必须属于同一组人，一是责任；二是权力，决定“怎样做才最好”的权力。因为我们知道人的影响因素是第一位的，我们必须找到最好和最有活力的人，并让他们做他们的工作。信任他们。
这暗示着团队管理者的工作就是让项目的工作轻松一点，去除障碍，并不让自己成为障碍。当然，管理者们需要知道这个项目符合日程表，并符合需求，团队中的人们也需要知道。
#6 面对面：“在团队内部传递信息，最有效和最有效率的方法是面对面交谈”。通讯要用全部的带宽进行。虽然e-mail是一种伟大的技术，但是它压制了其他的交流方式。在e-mail中没有“身体语言”，也没有声音的音调。在这样的情况下，反馈无法很直接，也很难注意到细微差别。
把一些交流保存下来也是有价值的，所以任何的项目都必须问：文档化记录的交流和单纯的交谈的应该保持怎样的比例，才是有利于理解的，包括提供给不在项目中的人们？什么才是正确的文档？正确的文档中应该包含什么？
在AA中有一种对文档的蔑视，认为文档是为他们自己的好处才做的，所以我们也必须问问我们自己，什么是一个文档的真正目的，当它具有永久的价值（相对于临时的价值）时，才制作它。
#7 可工作的软件：“可工作的软件是进度的首要衡量标准”可执行模型的一个重大的优势在于可以尽早的让系统运行，这能帮助你早点知道你是否有麻烦。因为我们现在可以通过运行来验证模型。我们可以得到真实的结果，来清楚地预示软件所能做到的。
翻译（translative）方法比行为（behavioral）方法更有价值，这点特别的真实。因为翻译方法把软件架构从应用中分割了出来，使得可以更早更快地来构造一个可验证的的模型。
这条原则经常被程序员和管理者曲解。这条原则不是允许去hack，敏捷过程强调良好的设计和持续的实施。这条原则强调了真正的产品的重要性，并强调了只生产必要的东西。
#8 可持续开发。“敏捷过程提倡可持续的开发速度。赞助人（sponsors）、开发者和用户应该能够保持一个长期的、恒定的开发速度。”这条原则反对依赖英雄，但是并不排除冲刺。我们都有这样的经历，有时候要排除前一天晚上偶然发昏埋下的错误。
这条原则是管理方面和技术方面的原则，同时也是生活的原则（我们总是希望拥有工作之外的生活），告诫大家不要耗尽精力。
你应该问问自己什么样的组织是你希望的。如果成功的唯一道路是成为一个英雄，而且不管这是否是一个有效的策略，那么现在是时候去寻找新的工作了。
你应该问问自己你希望从工作中得到什么。我们中的一些人想把自己全身心投入到工作中去，另外一些人不是这样想。两种想法都不是“正确的”，但是我们所有人都应该警惕，不要让其他人的期望妨碍了自己的判断。
#9 技术优秀： “不断地关注优秀的技能和好的设计会增强敏捷能力。”这条原则真的是一句断言。良好的设计真的可以提高我们的能力来应付变化吗？我们是否应该时刻警惕着来保证我们做的是良好的设计？如此重新陈述，明白无疑的答案必须是响亮的“是”。那么什么是良好设计的特征？这条原则请求开发组织和个人不要进入“快速却杂乱”的状态？
模型可以被设计得很好，也可以被弄得很差。不幸的是，我们已经倾向于在语法上理解模型：如果它看起来可以工作，图形和连线不太松散，那么就是好的。Leon Starr在他第一本书中[9]，有力并且风趣地谴责了“模型编码（model hacking）”。良好的分析提高了敏捷。
相关的一个概念是重构（refactoring）。它建议，一旦一部分代码已经很清楚地变得不再内聚，你就应该重新组织这部分代码。这样的概念同样适用于建模。就我个人而言，我曾经忍受很多分析会议，在讨论中，建模者和专家们宁愿延迟去定义什么是铣床，解释说，这是因为如果要找出每种完全不同的铣床，需要作太多的工作。“噢，我们会再细分它的”。继承和划分子类是（很多中方法中）的一种方法，来完成一个重构过的模型，但是首先你要已经把模型做好。当你要编码的时候重构你的模型。（参见 Kent 和 Martin 的《Refactoring》〔10〕）。
#10 简单是根本的：“简单——使未完成的工作最大化的艺术——是根本的”前面的原则都是关于“优雅”的，这会有一个副作用，把“简单”仅仅当成一种最简单主义。毕竟，如果代码是优雅的而且易于修改，我们就不需要去作这些（不必要的）事情。这个概念是一个在XP里用一个缩写YAGNI描述，“你将不需要它（You Ain’t Gonna Need It.）”。
在建模中，这个思想当然也是适用的，只做必须做的事情，并优雅地做。
#11 自组织的团队：“最好的架构，需求和设计出自自组织的团队。”让一个值得信任的专业人士组成的团队，和客户或者领域专家，在同一地点一起工作，来构造良好的设计，那么他们当然可以得到良好的需求，架构和设计。(如果这样都得不到，还能有什么方式可以得到？)。有一种期望，如果有很多的交互和一些处理规则，那么“正确的”架构，需求和设计就会魔术般的“出来”了。
在构造团队时，我建议要基于你可用的技能，而不是试图去强迫你可用的“资源”(这是管理上对你的同事的称呼)去作你需要的事情。如果他们喜欢他们想作的事（还有，他们希望去学习的事情），人们通常非常有动力，而且他们知道如何去作。一旦一个团队领会到他们具有什么技能，他们就可以如何去弥补他们的缺陷。
#12：反省和调整：“团队要定期反省如何才能做得更有效，然后相应调整他们的行为。”Cockburn建议给每个项目使用不同的方法，在你还没有开始项目的任何工作之前，当然不可能非常敏捷地来定义你的方法，这意味着在某种意义上你必须“你要在你前进的过程中调整你的方法。”如果你盲目地一直用同样的方式做事情，而且它并不能做得好，你将注定失败。
Fowler[7]引用了Kerth下面的问题，周期性的问自己，来作为“过程检查（process check）”：
哪样东西我们做好了？
我们学到了什么？
哪些东西我们可以做得更好？
什么东西困扰着我们？
因此，这条原则是一个警告，来监视你在作什么，并定期改造你的方法。“过程检查”是 一个方式，来问问我们自己，我们是否在正确的时间做正确的事情。
