创造有用的软件是门工艺。这是没有非黑即白的成功公式的。但是，却有一些敏捷工程实践，实践证明它已经屡次为企业增加了价值，但前提是要考虑周全之后再使用。在本文中，我将与大家分享5条具体的途径，你的企业能够通过这些途径从敏捷工程实践中获益。

（假设我们使用Scrum + 极限编程（XP）= 敏捷这条基本公式，那么在我讲敏捷工程实践时就会谈到公式中与XP相关的那一部分，比如测试驱动开发、结对编程和持续集成。）

James Shore在一篇精辟的博客中说：

“与XP（极限编程）相比，Scrum更加简单，对原有工作几乎也产生不了多大的影响，所以我看到很多人是从Scrum开始入手的。但其中的问题是，从Scrum开始入手的团队比从XP开始的团队多得太多了。XP团队在开始时会经历更多的痛苦，但在第一年就会达到高效的状态。”

我不仅同意他所说的，而且也亲眼见过很多次这样的情况。XP很难。它难在需要严格的纪律，另外，它的好处虽多却有时难以立杆见影。

我的父亲是一名牙科医生。他有一次告诉我说“找一位好的牙科医生是很难的。牙医能补牙或者杀死牙神经，但你5年内不会知道他做得好不好，因为你需要一段时间之后才知道他补得到底好不好。”XP与之非常类似。

我清楚最好的软件开发人员（而且知道上千名）在高压环境下是最遵守纪律的。

许多开发人员体验了敏捷/Scrum/精益/XP的做法。但是，严格的截止日期临近时，或者团队已经拖期时，再或者公司要求团队“快速完成”时，他们还能维持多高的纪律水平呢？

现在有很多XP实践，其中对商业而言最有价值的是：

• 测试驱动开发—TDD是你的商业安全网。因为测试是在编码之前完成的，所以写完的测试一定会运行失败，接下来再写代码使测试可以通过。TDD保证你的产品功能，不管公司和技术团队实现的是大规模的变更还是小规模的变更。
• 结对编程—让2名开发人员写同一段代码，使用同一个键盘和同一台显示器。因为结对大大降低了浪费的时间和缺陷，所以能带来更高质量的代码，并带来高水平的协作。
• 集体代码所有制和持续集成—如果每段代码不只有一个人熟悉，那么就不会有什么交流瓶颈了。把代码持续集成到一个主干可以避免重复和不匹配的代码。
• 重构—在当时的情况下，写的代码是解决已知问题的。通常，团队巧妙地解决了他们的问题，然后持续重构和修改代码，确保代码库能以最为高效的方式不断满足业务最新的需要。

然而给定的XP很难，它需要连续的训练和一定的时间保证才能做得好，高管们要的是速度。技术总监们、副总裁们、首席执行官们说“我希望我的工程团队获得更好的敏捷工程实践效果，使我们变得更快。”

最初，我同意 James Shore所说的，XP的确很难，实际上它违反了敏捷帮助团队更快的理念。事实上，XP有陡峭的学习曲线，而且很自然的是，这需要一定的学习时间，学习XP的团队肯定比什么都不学的团队更慢。

所以，如果“更快”不是敏捷工程实践真正的价值，那么什么才是它真正的价值呢？

我认为，敏捷工程实践真正的价值是，它们让公司以某种方式拥抱变化，事实上，这将成为一种竞争优势。

为什么呢？

当我们进入2014年，这个论点将在逻辑上成为合理的。如果现实果真如此，那么以此推理，在接下来的十年间，那些充分利用软件构建流程的公司将走向成功。

是的，这个道理大家都懂，有很多竞争优势是软件之外的。例如，那些能够充分利用数学工式去预测未来股票的对冲基金将拥有竞争优势。那些能够充分利用布艺和颜色去预测未来时尚的零售商店将拥有竞争优势。但是，随着7乘24小时的网络连接和全球信息共享，你刚想到一个好点子，你的竞争对手就将会去模仿它了。

这让我们兜了一圈又回到刚才的观念，那些能够充分利用软件构建流程的公司将超过他们的竞争对手，拥有巨大的竞争优势。这个概念的关键词是“流程”。它是技术栈无关的。从敏捷工程实践中充分获益的关键是，出现危机的时候仍能极力地坚持最起码的流程原则。这就像是锻炼身体。假设你休假的时候每周锻炼五次，上班的时候每周锻炼一次，那么实际上你每周只会锻炼一次。如果离截止日期还远的时候才实践结对和TDD，一旦要到截止日期了就把敏捷抛到一边，那就说明你并没有勤奋地实践敏捷流程。

能够让企业通过使用敏捷工程实践获益的五种具体方法是：

1.可以随机应变的灵活性

我的公司为大型零售商创建了一个电子商务平台。在六个月的开发周期中，前三个月团队具有自主权。我们两周一个迭代，并且每两周发布一次代码。某天，产品团队做竞争情报研究时发现，一个竞争对手针对退货修改了他们销售和信用卡的处理方式。因为我们完成的代码上个迭代已经充分测试了，并和其他代码集成好了，而且已经发到生产环境中了，所以我们清楚自己的代码非常可靠，即使变更也不会有任何宕机或缺陷之类的重大风险。

第二天，我们决定不再继续既定的构建，而是开了个需求收集会，估算多久能完成新的特性，并对用户故事重新排序。数天之内，我们就把一组新特性确定好范围，排好优先级，由团队优先来完成这些任务。两周之后，修改后的信用卡退货引擎就发布到生产环境中了。没发现任何缺陷，销售团队对此非常满意。

这完全得益于包括测试驱动开发在内的敏捷工程实践，公司清楚他们能够依靠技术团队快速应变，尽可能地降低在线品牌展示质量的风险，从而始终保持着市场的竞争力。

2.可以实时地重新分配开发团队的成员

如果要达到这种随机应变的灵活性，在两周内就发布新的信用卡退货引擎，那么团队在本迭代只为这个特性上安排两名工程师就不太够了，实际需要四名。由于团队采用了结对编程和集体代码所有权的缘故，所以团队中的成员熟悉每一段代码，我们可以随便拉一对已经完成其他故事的程序员去完成这个新的优先级更高的故事，当我们重新排定的优先级之后仍能维持原有的速率。

使用敏捷工程，项目不会因为某个摇滚巨星无法从其他事情中分身而阻碍了进程。整个团队可以转向新的需求。为新功能配备的最佳配置可以专心去完成新功能。团队处在一个不断交流的氛围中，所以为一个故事增加更多的工程师会很顺利，不会产生任何混乱。

3.自然而然地避免了去废弃持续了几个月的工作

经过充分测试再发布生产环境的代码还有另外一个好处，一旦完成就不会被废弃。当我们确认需要完成信用卡退货特性时，就可以把工作重心直接转到这个优先级更高的新特性上。在这个过程中不需要废弃任何工作。在我们要开始这项新工作之前，没有必须要完成或推迟的半成品。已完成的所有代码都是高质量的、无缺陷的、完整的和有效的。

4.坚信已完成的特性永远代表着项目最重要的那部分

几年前，我的团队为一个大型政府机关项目做一个项目。这个项目是个长期合作，我们编码就用了一年。因为我们使用了敏捷工程实践，所以代码会被持续发布到生产环境中。

在某一天的早晨，一位干系人对这个项目的优先级有了一些新的想法。他担心因此可能会使其他重要功能无法完成了。他不熟悉每天的项目进度，也没有意识到敏捷的商业价值。

所幸，工程团队实际上是紧贴业务开展工作的，每两周按业务的优先级完成他们的工作，在过去的一年中，最重要的特性已经完成了、已经完全集成在一起了、已经充分测试了，它们的质量坚若磐石。

公司坚信在任何时间点完成的都是最重要的特性。干系人可以放心软件的任何变更，不但多大都可能，而且都可以欣然接受且风险很低。

5. 能营销活动策划充满信心

我们都曾经经历过这样的事，公司策划一场营销活动。我经常和团队在一起工作，他们需要在确定的日期内完成软件的编码。去年，我负责一个教育服务性企业的项目。一场营销活动已经全面铺开。我们有一个明确的期限：返校日期。他们希望返校期间能产生巨大的销售额，所以这些特性必须在八月十号之前上线。由于日期是固定的，这场营销在电视、报刊和在线广告上也花费了大量的费用，电子商务网站必须在规定的日期内具备最必要的特性。

通常接下来会发生什么事呢？我看到无数的工程团队最终会处于一种左右为难的境地。八月一号那天，产品经理意识到无法满足时间要求，如果想让产品如期上线，工程团队就要在接下来的两周里每周拼命地干100小时的活。但是，如果团队的工作强度如此之大，就会把人搞得非常地疲劳和焦虑，这样就很容易出现工作上的失误。

如果团队能够设法做到严守敏捷原则，继续依靠工程最佳实践，那么测试驱动开发、持续集成、结对编程和其他方法将引导团队准时地发布并灵活地安排休息时间。

团队只需这么做。我们在高压时坚守敏捷原则，并握紧手里的枪。使用敏捷能为营销活动带来信心，其关键就是坚信这样的一个事实，其实许多特性可以有多种实现方式。例如，假设有一个特性是要把视频上传到你的网站上，那么至少有两种实现方式。方案A：花10天时间开发，使用户可以上传任何语言、任何格式和任何长度的视频文件。方案B：花1天时间开发，让用户可以把YouTube的链接粘到一个输入框里。

你怎么选择我不得而知，但如果我是产品经理，而且时间已经到八月一号了，那我肯定会选择方案B。

最终的结果是，我们在八月十号成功地发布了产品，它包含了所有的关键特性。我们有意欠下了大量的技术债，包括选择用一天的时间完成视频上传的特性。八月十号一帆风顺，之后我们把新特性和之前欠下的技术债重新排定了优先级。我们把技术债和新特性一起放到故事列表中重新排序，快速恢复到了两周一个迭代的平稳工作效率中。

概括起来说，敏捷工程实践的价值已经超越了工程团队，对整个企业的好处是显而易见的。持续运用高效开发过程的公司将带着巨大的优势同我们一起走进下个十年。让你的团队以最适合的方式去实现敏捷工程实践吧，如果你有任何问题都可以向我提问，我会非常乐意地与你一起一边喝喝咖啡、喝喝啤酒一边详细地交流讨论的。