毫无疑问敏捷方法通过自己的方式已经成为行业中一种流行的实践。尽管我还没有看到一个严谨的研究证明敏捷相对于其他软件方法所拥有的好处，但是已经有很多有趣的现象证明敏捷方法是行之有效的。想要理解其中道理，我们可以通过多个角度来检查和分析敏捷方法。本文里，我将只从执行角度来讨论这个问题。阅读下文你将发现该选择只是应运而生而已。

　　几个月前，我读了一本由Chris McChesney, Sean Covey和Jim Huling三人合著的《The 4 Disciplines of Execution（4DX）》[http://www.4dxbook.com/]。由题目可以看出该书讨论的是4个原则—如果合理执行—任何组织都可从有效并高效地执行中获得巨大利益。这4个原则是多年来研究上百个组织和上千个团队以获知到底什么能使执行成功的结果。

　　在读这本书的时候，我总是情不自禁地将书中的概念与软件开发流程对它们的应用联系在一起。在书的最后，我意识到敏捷方法之所以能成功的主要原因是它有意和无意地吻合了这4个原则。

　　书中这4大原则排列如下：

　　关注于最重要的
　　以领先指标为行为导向
　　保持一个有吸引力的记分板
　　创建一套有节奏的责任制

　　现在就让我们（很）简洁地看一下这4个原则的各自意思，以及如何将它们与软件开发上下文一一对应。

　　关注于最重要的

　　简单地来说，你想完成的越多，你将完成的就越少。总是有好的想法值得去思考，但是什么是此时此刻你要关注的才是真正的问题。在软件开发中，把无法控制对众多好想法的分心也叫做需求漂移。你曾经工作过的项目是否发生过客户，或者产品需求分析人员，甚至开发人员不断地增加新需求，因为他们觉得某些功能不可或缺？这种情况往往发生在将需求收集与实际执行分离时发。就是说，我们总是提前不断收集需求直至最后难以在特定时间内关注任意需求。敏捷方法通过短迭代来解决这一挑战，只处理客户认为最重要的一小部分需求—或极为重要的。通过对这些迭代计时迫使团队只选择那些能在短时间内能完成的目标。从好的事物和同样好的事物中做出选择是违反直觉的，但正因为这样，我们才需要一个相应的流程来解决该问题。到最后，时间是有限的，我们需要对“到底什么是值得现在做的”做出决定。没有哪句话比苹果公司的COO—Tim Cook说得更好了：“每天我们都要否定掉那些好的想法。只有这么做才能让那些伟大的想法发生。”

　　以领先指标为行为导向

　　对性能评估可以通过收集两种类型指标来完成：滞后指标和领先指标。滞后指的是那些事后才检测和收集来的（比如：项目结束后），类似销售额，市场占有率，客户满意度等。领先指标，换句话说就是那些当流程还在进行时检测和收集来的，用来最终影响滞后指标（希望是积极的一面）的。举个例子，一个产品中执行可用性测试的数量就是一个领先指标，它可以用来影响客户满意度这一滞后指标。一个好的领先指标有两个主要特征：能够预测结果和可被调控。比如：可用性测试数量就是一个好的领先指标，因为它是一个可以预测客户满意度的指标，而且我们也可以控制产品可用性测试执行数目。

　　在软件开发中，常见的难题是我们无法明确定义领先指标。举例说明，软件包的稳定性就不是一个好的领先指标，因为一旦产品发布后，我们对其稳定性的控制非常有限。当然，我们可以随后不断发布服务补丁包来弥补，但是要承认的是，这个方法是最平庸的。另外，不稳定性与硬件还有关系，这又使问题变得更加不可控制。敏捷通过以下几种方法来解决这个问题。首先，用单元测试（每个类）的数量和质量，还有被广泛用作领先指标的构建失败率来评估其质量和稳定性。有些敏捷团队使用测试驱动开发来加强该领先指标。敏捷方法成功的另一个例子是持续重构概念。在重构和清理遗留代码上花费精力多少也是个好的领先指标，能显著地影响代码的可维护性这一滞后指标。敏捷方法同时也致力于通过客户满意度这一滞后指标来保证构建好的产品。该滞后指标通常受不断增加的客户参与和回馈链这些好的领先指标影响。

　　保持一个有吸引力的记分板

　　人们总是不可避免地使用不同方式来计分。作者强调计分应该由团队成员自己来进行，而不应该由他们的经理或领导来控制。这大大改变了游戏规则，因为这里强调的是参与度以及保持团队中每个人的兴趣。给团队成员一个机会让他们自己去观察项目到底是成功还是失败的，通过这样让成员更多地关注项目的发展方向。因此作为一个团队，这个具有吸引力的记分板应该由团队设计，并实时根据既定目标反馈来纪录项目状态。

　　查看那些在北美，欧洲或是亚洲的大小软件公司的敏捷实践，我还没有发现哪个敏捷团队不使用记分板，尽管他们可能并不这么命名。团队在项目一开始就设计了一个记分板，然后每天更新。至少，该记分板需要说明团队当前在解决哪些需求（目标），团队完成了哪些需求，以及还有哪些需求还在backlog里。根本不需要专家来告诉我们团队目前是成功或是失败。该记分板是，而且也应该是一目了然的。如果我们正在进行一个三个星期的迭代，一个星期后我们只完成了10%的工作量，显然我们正处于失败状态，必须采取行动。如果正在进行的工作在记分板中期不断累积，并且只有少量或根本没有输出结果，那我们团队目前也是失败的。事实上，如果难以判断团队目前是成功还是失败，那么它往往是失败的。不重视记分板上的数字是一个环境不健康的指标，并可能意味着需要更多的努力来提高团队对项目的拥有感，或者减少管理上对计分的干预，以及将团队视为一整体，而非将个人以成功或失败者对待。

　　创建一个有节奏的责任制

　　当确定了特定目标，明确了领先指标，及有了一个将团队每个成员到参与进来的记分板之后，团队应该定期以及频繁地互相协作以完成目标，改进领先指标，并最终赢得胜利。作者建议团队中所有人都应每周举行一次会议来简短汇报他们是否完成了对团队过去一周的承诺，他们为记分板做了哪些贡献，以及在接下来的一周他们想为团队承诺什么。作者建议团队每个人都应有自己的承诺以获取相应的成就感。这样团队成员将不再是遵循上级的指令，而是履行自己对团队的承诺。

　　敏捷方法通过站立会议提倡的正是这一常规性责任制实践（也指敏捷会议）。只是这些会议的频率比作者建议的要更频繁—一般是每天一次。由于该会议是站立的，向大家提醒了其简短性。所有团队成员都需汇报他们昨天做了什么，今天将做什么，以及他们目前是否有障碍。通常，团队成员会选择他们自己想要工作的内容，他们甚至会自己写些任务，然后加到记分板上—这又更加增强了团队对项目的成就感和承诺。

　　最后

　　在过去几十年来，软件参与者学到了一件事，那就是软件业里没有捷径。敏捷方法如同这4个原则一样，都不是捷径。尽管如此，我们也学到了没有必要在其他成千上万组织已经遇到并解决了的问题上重蹈覆辙。软件公司已经在改进他们的流程上花费了巨大的精力和资源。因此，我觉得如果我们从执行角度来检测软件流程中所存在的强项和弱点的话，将会获得很大的价值。将该视角留在脑海中，可以防止我们在还未真正理解使事物行之有效的原理之前，就滥用类似敏捷方法这样的热门话题。全球无数公司和团队滥用敏捷方法，从而使自己困入那些杂乱无章的，没有足够计划、设计或质量保证的软件实践中。经过这十多年来对敏捷宣言的推进，依然有些参与者无法在敏捷和混乱间划清界限。但是好消息是我们可以使用上面4个原则作为评估框架来回答下面这个问题：我们是否是真正的敏捷还是只是在假装敏捷？