1.5 简化
敏捷宣言背后的一条原则是“最大化未完成工作的数量”。这意味着想要交付最少的产出（output）并使其结果（outcome）最大化（正如在1.2节所介绍的），并且只使用绝对必要的流程。我在1.2节中讨论过交付正确的工作，这里我想讨论一下如何简化交付正确工作的方法。
简化意味着团队一开始就应该采用一种刚好够用（barely sufficient）的方法。当团队启动一个新项目时，应该首先确定对项目成功绝对必要的活动，然后就只做这些活动。在项目进行的过程中，经过一些反思，你可能意识到需要一些额外的活动来克服所经历的挑战。这很好，只要你的团队也愿意放弃一些不再需要的活动。你想要从一个勉强够用的方法开始，是因为团队往往会发现停止某些进行中的活动比增加新活动要困难。从一组小的活动开始，你就给了团队一个保持精简流程的战斗机会。
简化意味着采用最直接的路径到达目的地，并且毫不留情面地询问为什么有人想走其他路径。简化也意味着不要让完美成为良好的敌人。我这里主要指的是晦涩难懂的建模语义、用例格式、商业规则语言以及类似的东西。我见过把太多时间浪费在模型是否100%正确的学究式争论上的情形，而模型只不过是用来辅助进行有关最终产品的沟通的。在有些情况下，准确性是需要的也是必要的。例如，当为团队和利益相关者整理共同使用的术语表（glossary）时，或者记录业务规则以便未来参考时。但是，如果模型或工作是为了中间沟通，就没必要穷究细节，因为你总是能通过对话进行澄清。
简化意味着用简单的规则指导复杂的行为。不要指望规定的流程能控制团队的工作方式。给团队提供一些直接的指导原则，并让他们从中学习。有些最优雅的解决方案是最简单的。不要掉入开发不需要的复杂的解决方案的陷阱。
最后，简化意味着如果一个模型不容易被记住，那么它被使用的机会也就几乎为零。这就是我更喜欢2×2矩阵的原因，如情境领导模型（context leadership model）和基于目的的对准模型（purpose-based alignment model）（都会在第12章介绍）。限制为二维的想法可能过于简单，但这增加了模型被用于一些良好目的的可能性。另外，因为这些模型相当简单，它们很可能包含一些细微的差别，这使得他们非常强大，以适用于不同的情况。
当启动会议投稿系统时，我们从一个很小的流程开始，这一流程是我们经过一些调整后发现特别适合我们的（由于我们团队的规模较小且对该领域非常熟悉）。我们发现，冲刺计划会议（sprint planning meeting）、站会（standup）和演示（demo）给我们造成太多流程开销，因为我们对于一个版本中想处理的用户故事顺序已有共识，并且当为我这个产品负责人准备好用户故事进行验收并提供反馈时，我们通过版本库进行沟通。随着项目的推进，我们在必要时增加了一些额外活动，但整体上我们能保持整个方法非常有效。