精益和敏捷：完美的结合还是冲突中的孽缘？

毫无疑问，我正在试图煽动大家。在某些方面，我对这个话题的后半段是确信无疑的。

在软件开发领域，LeanAgile 似乎已经成为一个单词，提出这样的问题或许会让人感到很惊讶。所以先陈述一些附加说明。

我认识 Mary 和 Tom Poppendieck 夫妇十几年了。我们是朋友，同时也是世界上最大的面向对象用户组的同事，都在明尼阿波利斯。Tom 是我在圣托马斯大学（位于明尼苏达州，维尔京群岛, 不是太糟糕的寒冷气候）的学生，他是我出版的有关面向对象的书籍的技术评论家之一。

除了无法忍受他们的书比我的更热销外，我是由衷地敬重和钦佩他们的内容和思想。他们的书是专业领域的独鳌，所陈述的内容理应被世界各地的软件开发者（包括敏捷方法论开发者）学习和应用。

那倒底是怎样的问题呢？

简单来说，精益和敏捷的基础是根本不同的世界观，因此也毋庸置疑地在一些关键论点上呈对立势态。在接下来的段落里我会尽量展现他们的相反世界观，阐明冲突，然后给出如何尽可能和解的建议。

精益世界观 = 生产

一些出自精益软件开发（Lean Software Development, An Agile Toolkit）的引言介绍了我的断言，精益的世界观是一种生产世界观。

Jim Highsmith 的前言，“Mary 和 Tom Poppendieck 把精益工业实践运用到了一个新的层面，他们告诉我们怎样在软件开发里使用精益理论。” 以及，“…为将精益技术从工业环境引向软件开发用提供了丰富的信息资源。”

摘自 Ken Schwaber 的前言的一些字眼和语段，“工业过程控制”， “敏捷过程”， “Mary 在制造业和产品研发的背景。” 以及在 22 页的介绍中, “虽然认识到误用隐喻的危害，但我们相信软件研发与产品开发是类似的，软件开发行业可以从检测产品开发方案对产品开发过程的改进中的变革来学习更多的经验。”

生产和流程之类的词汇，以及隐喻贯穿于整本书的纹理中。虽然有对 19 世纪生产思想的明确否决（比如 Taylorism），但是同样有也对开明生产模型的完全采纳（比如丰田生产模式）。

具体的敏捷实践是从对生产的贡献角度评估而来的。如果某个特定的敏捷实践被认为与精益生产过程模型相冲突，那么这种实践必须予以修改或取消。

精益并不完全是关于过程的。例如，下面是精益的七项基本原则，

• 消除浪费
• 增强学习
• 尽可能迟缓做决策
• 尽可能迅速给交付
• 增强团队
• 构建完善
• 纵观全局

只有第一个是毫不含糊地相系于流程，相系于生产。

这些基本原则暗示了在精益的其他方面超越生产世界观的方式。我们会在本文的最后部分回到对这个话题的的阐述上。

敏捷世界观 = 理论构建

我非常荣幸能够和很多的敏捷理论的发明者和倡导者共同参与和讨论。我曾经和圈内人士讨论关于敏捷的哲学基础，并且发现它们的一致性。但只有 Alistair Cockburn，把这种思想记载到了书中。

在附录 B，227 页到 239 页，Cockburn 的敏捷软件开发一书中包含了一篇 Peter Naur 在 1985 年写的文章，题为“编程理论构建。”

Naur 认为把开发软件的行为看成生产程序和其他文件的行为是错误的。他举出几个例子来论证经验数据不匹配生产模型的发展模式，包括文档的草草了断，以及是否有一些形式可以向那些没有参与初始阶段创作的成员转达对项目计划的理解，而这体现了规格化的欠缺。

理论构建，Ala Naur，得益于个人和集体的努力：

• 理解世界
• 理解软件如何在世界中形成，又如何与世界相整合
• 理解软件的实质以及如何最好地阐明这个本质
• 理解你是否已经得到前三个认知权

观测活动和理论构建包括叙述大量的故事（Story），探索思想，尝试更多途径，测试你的理解，通过唤起认知来扩大对自己的物理内存，并迭代地完成对这些事情的增量。

看上去非常像一个敏捷环境，但是一点没有与生产环境的相似之处。

除了引用了 Ryle 的关于理论持有的思想，Naur 并没有明确制定理论构建的基本原则。如果他有制定的话，那肯定是和 XP 的简单，交流，勇气和反馈的价值观一致的。

世界观的冲突

精益把软件开发看成一种从概念到产品的过程。精益想通过完全不同于传统概念优化的方式和价值观来提升整个过程。

敏捷把软件开发看成一个构建协商一致的概念理论的过程，同时把所得的产物看成一个副产品，只是对这个理论的一种诠释。

由于两种理论的基本世界观是完全不同的，有冲突自然在所难免。而这些冲突体现在工具和实践的层面中。

例如，产品 backlog。

敏捷的前提是基于用户故事的模块化思想。用户故事就是“客户希望系统可以去实现的”。（Kent Beck）

用户故事来自于用户、别名、客户或者业务等。故事的产生要远远快于他们的能够被执行，特别是在一个大型项目的初始阶段，或者当目标是“敏捷化”为整个企业的时候。

几乎所有的敏捷项目都会建立一个产品 backlog，一系列的故事会被付诸实施。这一系列的故事可能会非常大，我曾经看到在一些项目里，产品 backlog 有数百个故事。

精益把产品 backlog 看成是目录清单或者是废物。Mary Poppendieck 建议产品 backlog 应该被消除或者削减尺寸使其与团队集体速度相吻合。

敏捷把产品 backlog 看成新兴理论的快照视图。即使这种快照试图会以贴满墙壁的故事卡片来展现，它也仍然不是目录清单！这些卡片就像外部存储卡一样，而每一块卡片都可以唤起对于事件如何处理的详细对话和理解。

当产品 backlog 足够大，并且其成分中有大量 churn 时，敏捷化更能显示它的作用。Churn 来自于一系列的对话，故事的实质，故事的优先级，开发者对尚未理解的故事的反馈，那些与预期想象不同或易或难的故事，需要重新定义影响因素来帮助开发的故事，或者用户接受故事完成的反馈。

最后，churn 减少了，产品 backlog 也会逐渐稳定。新故事的加入只会被视为点滴，而故事的优先权也只是象征性地调整一下。单从这一点看来，也许更容易把产品 backlog 看成是目录清单。但不管怎样，backlog 仍然是理论的物理表现。它提供了所有正在进行的研发工作的精髓内容。

Backlog 为软件研发提供的关键性支持等同于电影制作的连贯性编辑和技术策划。当注意力都集中在单一场景中，很容易忘了主角在前一场景最后一帧中穿的蓝色衬衫，而不是红色的。你会忘了在太空中听不到爆炸声。类似的错误也会在故事贯彻执行中发生，而产品 backlog 提供了连贯性以及对精髓误解的更正。

在我所接触过的所有敏捷化项目中，我一直坚持以类似于信息极速跟踪的故事卡片信息墙的方式来使用产品 backlog。故事即时聚焦和整体产品 backlog 的故事的简单检查被安排为每天的基本任务。在每个案例规划和回溯中，产品 backlog 会被重新过目和具体讨论，从而达到更新每个成员对合成理论状态的了解。

这个例子的关键点在于，你的世界观必然会丰富你对事件的解释。一个简单的产物，比如产品 backlog，基于你的世界观的层次，会展现出不同的现实因素、目标、价值和功能等。在这种情况下，基于“生产世界观”来做出解释只会对敏捷软件开发不利。

我知道这只是很一般的论证，并且只用了一个单一的例子来论证。但这只是空间有限的原因，而非缺乏实例。

和解

婚姻是幸福的，除了一些误解，争执和相互起冲突的目标。精益和敏捷作为这样美妙的一对，这段姻缘会持久吗？

当然可以，但是有三个前提忠告。一个是给精益的，一个是给敏捷的，最后一个是给双方的。

精益需要拿掉“生产理论的有色眼镜”，从包含七个精益基本原则的全盘角度去审视敏捷和敏捷开发过程。如果不单单是从“消除浪费”的基本原则去评估产品 backlog，那么 backlog 在“增强学习，延缓决策，增强团队，构建完善，纵观全局”等方面的贡献还是相当明显的。

当然了，敏捷从业者也必须做同样的改变。当你听到敏捷从业者谈论他们所做的事情 - 他们的词汇，暗喻，贯彻实施，无不反映了敏捷是生产的替代模式的观点。但问问关于 Naur 和理论构建的敏捷话题，却只会得到一片空白。

精益和敏捷都应该杜绝使用纯文字或者死记硬背的方式，工具和做法。工具和做法只不过是对价值，原则和哲学的表达。而他们不是唯一可能的表达方式，也不可能是最好的一种。 除非能够理解为什么要这么做，这些工具倒底是什么，否则任何一方都不能够实现他们各自创始人的关于“使用，适应和超越”的告诫。

AgiLean（类似于 tabloids, bennfier, brangelina）属于一见钟情的案例。他们的蜜月就是用新方式来合并思想的激动人心的时刻。但是那个时代已经过去。如果这段结合想要持久，双方需要超越彼此表层的吸引 - 因为如果只是停留在那个层面上，冲突再所难免。

查看英文原文： Lean and Agile: Marriage Made in Heaven or Oxymoron?

译者简介：王菲菲，朱拉隆功大学计算机科学与技术硕士，现就职于某外资 IT 咨询公司。主要从事银行电信业商业智能和数据挖掘分析的咨询工作。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。