与未知同行——敏捷开发中的反馈与反复

与未知同行——敏捷开发中的反馈与反复

作者： baiyuzhong分类：高端视点  阅读：1,325 次添加评论

文 / 殷亮

理性王国的失意者

在古希腊的托勒密（Claudius Ptolemaeus）所构想的体系里，人类在宇宙内被指派到了一个中心位置，太阳围绕着地球朝升暮落、日复一日。一直到400多年前，哥白尼亲手将以天之骄子自居的人类从这一显赫的位置上驱逐下来。在1858年前，人类也一直认为自己是万物之灵，凌驾于自然规则之上，较其他生命高出一等。然而达尔文跑遍大半个世界后却告知我们：我们又错了，我们犯下了一种对宇宙的不虔诚罪。同样，在软件业诞生以来的半个多世纪的时间里，我们曾试图将编程与工业生产等同起来，高喊软件工程化与软件科学化，但时间再一次证明了我们的无知。

人类对于自己知道什么及未来会发生什么，总是过于乐观。因为人是这样一种动物—他们活在未来，行动在现在，靠着对未来的预测来决定当下的行动。关于未来，我们确有所知，但实际上也就“仅此而已”。然而却总有一种企图将一切置于理性王国之上的倾向，在灵魂深处挥之不去。也正是这种对不确定性的厌恶和对预测能力的盲目自信，使软件开发在很长一段时间内都只能黯然深陷于瀑布流程的炼狱之中。

我的思想应向我指示我正站在何处，但不该向我透露我将前往何方。我爱对未来的无知，不愿因焦急和对未来预先付出的代价而毁灭。

——弗里德里希•尼采（Friedrich Wilhelm Nietzsche）

在Larry Constantine笔下的混沌年月里，“无数的管理者为保持控制力和稳定而努力，为软件性能和可预测性而竭尽心思……站在项目负责人的角度，他们试图理解和管理无比复杂的开发技术和流程，但技术变化的步伐却越来越快，从而导致复杂性不断增高，也更加难于管理”。先行者向着自然科学般的绝对精确前进，试图消除软件开发过程中的一切不确定性，但真理却放弃了他们。我们总是认为能知道更多就能做到更多，这种状态就像尼采所说的“精神越来越重，变成骆驼走进沙漠”，而精神的重负无疑就是通往敏捷开发路上最顽固的障碍。

反馈-变更的必要条件

沟通的极限

有一种决定论的思想—坚持认为世界的因果结构很强，如果给出世界在某一时刻的整个状态的完整描述，那么在这些因果律的帮助下，过去或未来的任意事情都能够被计算出来。当然，我们都知道，想以一己之力去了解“世界某一时刻的整个状态”，无疑是力所不逮的。但现在我们假设这是可能的事情，可以通过现在的描述，预测到未来的状态；那么，在软件开发中，假如我们知道客户现在想要的和团队当前的状态，是否就可以预测出将来能否顺利交付软件呢？Alistair Cockburn对此给出的回答是：“不可能”。

Cockburn在《Agile Software Development: The Cooperative Game》一书中详尽阐述了沟通的不完全性，并认为完全的沟通永远不可能实现。换句话说，即使客户知道自己想要什么，但也很难用某种语言或文字将信息完整传递给我们。这样，我们都不需要去争论是否可以通过现在预测未来了，因为在真实世界里，我们甚至连准确理解现在身边的一切都做不到。

这种沟通的不完全性，是由于语言和文字中的歧义与含糊不清是不可避免的。我们日常生活中的种种误解及对误解的解释，是每一个人的人生中都共有的经历。当然，这并不是说语言与文字的歧义是无法消除的，像我们所归纳的设计模式和所创造的UML语言，实际上都是在消除歧义方面的一种努力。通过设计模式和UML，我们在沟通方面的精确度有所提高，但随之而来的却是明晰度和可读性方面的损失。另外，学习曲线陡增与应用范围狭窄，却使得这种方式很难推广到我们生活中的每一个领域。因此，我们很可能永远也无法创造出一种精确的需求语言，让客户去学习并准确描述其需求。就像我们永远也不可能在软件开发过程中让团队放弃一切口头与文字上的沟通而只使用UML一样。

反馈：他山之石

在一切需要创造全新事物的活动中，都有一定的对未来的不尽知，这种不尽知在其他领域里也如此，而不独软件开发为然。画家在开始作画前脑中所构想的，与最终完成的作品会有所不同；电视剧，从最开始的剧本编写到开播，剧情也必然存在出入；而管理者，如果只能在给定清晰的目标以及完全的信息后才能行动，那么必然不能胜任岗位，在这个变化的世界中处理问题。从这些相似的领域中，软件开发者能学习到什么呢？

很显然，画家无法在脑中构建出一幅完整的图像后再开始动笔，因为大脑对于成像而言快速有余但细节不足，难以保存且缺乏稳定性。画家所能做的，不过是参照着脑中的模糊影像，有了一定的准备后便开始下笔。之后，他每画完一笔，画布上都产生了一个新的版本，渐渐地，他下一笔的位置不再依赖脑中的影像，而是更多地根据眼前的中间版本来调整。脑中的影像映射了整个轮廓，但并未暗示其中的任何一笔。

而就电视剧而言，由于其中涉及大量情节和角色，所以在拍摄之前将剧本冻结无疑很难。因此，在拍摄过程中根据现场的展现来不断完善剧本是必不可少的过程。在美国和日本，电视剧甚至都不是一次性制作完成的，而更多采用边播边拍的模式。制作公司根据观众的反馈来调整接下来的剧情发展，使之更符合他们的喜好。

通常来说，企业决策所针对的“事件”都是独一无二的：一方面是由于不可能有大量相同的或类似的其他事件，足以让我们获得近似的概率；另一方面，企业决策通常都依赖于对未来的展望与对人的展望，而时间与人的不可控使得每个决策都不能等而视之。

1924年，在Alfred Sloan, Jr.的领导下，通用汽车公司开始实施一种全新的生产计划控制政策：要求各汽车分部每十天从经销商处获取实际销售信息，并与之前的月度预测相比较。然后每月再对整个形势进行一次仔细的分析以确订当初的预计是过高还是过低。如果认为预测过高，生产计划量马上削减；如果发现零售需求大于原来的估计，生产计划量将增加。“一言以蔽之，公司并不试图事先制定一个僵硬的年度计划，然后不论零售需求如何变动均将其坚持到底，现在公司悉行的政策是将生产始终置于控制之中”【摘自1926年通用汽车管理人员向美国管理协会的介绍】。而在此之前，整个汽车产业都是以死板的年度预测来做有关产量的决策，这种忽视未来不确定性的方法实际上是导致1920年与1924年整个汽车产业溃败的主要原因。

在各个领域里，人们在创造全新事物时，所运用的手段有一个共有的特质：迅速执行，然后频繁调整。因为要在一开始就知道未来的一切，是惊人的奢侈，可能是我们都负担不起的。而如果将整个创造过程看做一个封闭系统，直到最后一刻才打开的话，那么一旦与现实有偏差，返工成本又可能是我们所难以承受之重。因而我们强调创造过程中的反馈；就像一个射击手，从开始瞄准到扣动板机，一直都在依据自己的所见来调整角度，而最终角度通常很难在开始时就能确定下来。同样的，画家通过眼前所见得到反馈，电视剧制作公司通过观众得到反馈，而管理者则通过真实的执行情况得到反馈。倘若他们不这样做，就只能通过自己的大脑来反馈，但从大脑计算中得来的反馈怎会比双眼所见更清晰、比观众评价更有效、比事实证明更真实呢？大脑有它的伟大之处，但大脑也有受限的一面。

因此，在敏捷价值观里，我们强调客户协作，也就是承认从客户处持续得到反馈和从实际的构建活动中得到反馈的重要性。客户也许一开始并不知道他真正想要的是什么，但他们可以从我们交付的中间产品中得到启发；我们也是一样，也许一开始并不能完全理解从客户那里得到的需求，但除了客户，我们还能从谁那里得到这些呢？除了与客户协作，我们还能通过哪种途径去接近双方共同的目标呢？我们别无选择。同时我们还看到，无论是在开发过程中引入对模糊性的容忍，还是强调反馈的重要性，实际上都不是软件业的新发明，我们不过是在照搬其他领域的最佳实践而已。然则他山之石，可以攻玉。

反复

前文讨论到，在一切需要创造全新事物的领域里，都存在对未来的不确定性。之后还找到了应对这种不确定性的有效方式—反复进行，而不是一步到位。但通过对现实世界的观察，我们也不难发现：虽然同样是创造新事物、同样存在不确定性，但反复方式并不能适应于所有领域。比如建筑业，很少见到不断“推倒再部分重建”的施工方式；而在医疗业，虽然在某些特殊场合，医生也会通过验药物、观察患者反应来渐进治疗，但大多数情况下，这种方式显然不可取。那这些领域与前文讨论的情况有什么不同之处呢？

先看一下建筑业，在施工过程中进行结构调整无疑会大费周折，再小的变更也可能导致大面积重建，原料与工期的损失都将十分可观；医疗业也有类似建筑工程的困境，医生面对的是无价的健康，任何未经深思熟虑的决定都可能给患者造成不必要的伤害，这一成本无疑也是不可估量的。然而软件开发则不同，我们可以通过修改有问题的代码行调整未满足需求的模块，然后重新编译，这一变更的成本往往极其廉价—而这种廉价甚至给行外人士一种错觉，认为在已有的基础上增加功能或变更功能几乎不需要额外成本。

由此可以推断出，反复进行的一个重要条件是可以廉价变更。除软件开发外，这一点对于艺术构建与剧本编写也是显而见的，且这两个领域不仅可以廉价变更，似乎还有种可称为“将错就错”的优势。在一个信息顺畅的企业里，决策变更通常也能迅速得到执行，尤其是近年来随着实物期权（real option）理论的发展，企业管理者决策时往往会着重考虑后续的灵活性。反之，在变更成本非常高的领域，如乐团演奏、航天工程等，都需要事前充分准备，因为一旦开始则难以反复。

由于在一些领域里，存在着廉价的变更方式，使得“反馈—变更”成为一种可能的战术。因此我们也可以说，对于反复方式而言，存在中途变更的可能性且代价不高，是它的必要条件。但我们还不能将其视为充分条件，因为在一些领域中，虽然变更并不会导致昂贵的开销，但人们并不采取反复的方式来进行。比如一般的租赁协议，尽管在双方都同意的情况下，变更合同的成本是廉价的，然而先短期试租再根据反馈签订长期合同的情况并不常见。另一个例子是农场种植。假如某一农场想种植新的作物品种，通常也不会先通过少量种植获得反馈后，再进行大量种植。这是因为，在这些领域里，虽然未来也存在一定程度的不确定性，但这种不确定性的波动范围很小。上面我们提到的合同约束下的租赁、某一地区的气候，这些实际上都具有相当程度的稳定性，所以即使有廉价的变更方式，人们也不会以反复的方式去安排他们的计划。我们可以将上述讨论总结如图1所示的模型。

在这个模型中，我们提取了决定反复方式价值的两个维度：响应能力，在实施过程中变更的可能性和成本；不确定性，未来变化的不可知程度。在这两个维度上的取值都很高时，以反复方式进行的价值最高，软件开发便是最佳代表，因此敏捷交付在这一活动中具有极其重要的战略意义。另一个极端表现为低不确定性与低响应能力，在这里以建筑业为代表：建筑业的低响应能力，在前文已讨论过，它降低了建筑工程的灵活性，但这只是其中一方面；另一方面，由于有数千年经验的积累，建筑学和物理学科已发展得非常完善，其中的不确定性大大降低，因此，在建筑业中反复方式几乎没有任何价值。而其他两个象限，一个受低不确定性的影响，另一个受低响应能力的影响，使反复方式的价值大打折扣。因此虽然可以使用反复方式，但并不具有明显优势。现实表现是：在特定情况下，可以观察到采取反复方式的样本，但并不普遍。

当然，也并非所有软件项目都具备高不确定性与高响应能力，如我们所观察到的，某些内部系统或模仿型软件产品，项目的不确定性并不高，通过反复的方式来调整的意义不大。也就是说，我们无法从根本上同意这种极端的说法，认为敏捷方法对一切软件项目都是最优选择。这也是很多敏捷图书常常误导读者的地方。实际上只要某种理论—它陈述的是一种可被观察到的事实规律，那么它就必然有它的前提或约束条件。正如哲学家Rudolf Carnap所指出的：

“有时会认为某个规律是基本的，但后来却证明出其依赖于一定的时间地点或一定的事件……在许多领域，如生物学、社会学、人类学、经济学，有些规律初看起来好像普遍成立，但这种情况只是由于作者没有越出他的国家、大陆或他的历史时期的局限看问题所致”。

【Rudolf Carnap，1966，《An Introduction to the Philosophy of Science》。Carnap是逻辑经验主义创始人之一】

因此我认为，对于每个敏捷专家来说，他们的任务都不应该是急切地去证明敏捷方法有多么广泛的适应性，也不应该在自己的著作里加上“经我试验证明，在规模上百人的团队中敏捷仍然有效”的文字，这些都不是科学的精神。我们只有理解敏捷背后的机制并认清当前项目的特点后，才能确定是否应该以反复的方式来推进项目。一切理论或工具都有一个共同的缺点，那就是它并不能防止人们对其滥用。

量子力学的启示

1927年，后来的诺贝尔物理学奖得主Werner Heisenberg首次提出了“不确定性原理”（Heisenberg uncertainty principle）。该原理指出，在一个量子力学系统中，一个粒子的位置和它的动量不可被同时确定。这种不确定性也是量子力学中基本规律的重要部分。更重要的一点是，它意味深长地告诉我们现实世界是“非决定论”的。在这个由不确定性主宰的世界里，唯一能确定的就是我们对未来的不尽知，而这种不尽知，也是整个敏捷理论的核心假设。

在2005年的敏捷开发大会上，对不确定性的坦诚更是写入了《相互依赖声明》（DOI）：“我们（预料到了不确定性）通过迭代、预测和自适应来管理不确定性。”注意，是“管理”而不是“消除”不确定性。它们的不同之处在于：前者是我们对不确定性的友好接纳，而后者则是在这个由理性支配的世界里光亮无比但却永难实现的梦想。

我们现在拥有的与软件开发知识，比以往任何时期的软件工作者都要多很多。但同样的，我们的知识也肯定要少于100年以后的软件工作者。知识与规律在历史长河中不断地被修正，我们无法得知这是一个无限过程，还是最终会走向某种尽头。但在所能预期到的未来里，如何管理不确定性，仍然会是学科中最重要的课题；反馈与反复的组合，也仍然会是组织开发过程时最应考虑的方式。而我们必须继续与未知同行，并容许我们今天否认同样曾属于我们的昨天。

作者殷亮，创新科存储技术有限公司项目经理。目前在深圳工作，研究领域以产业竞争与组织理论为主，6年软件项目管理与组织顾问经验。

本文选自《程序员》杂志2012年04期，未经允许不得转载。如需转载请联系 [e-mail]

《程序员》2012年杂志订阅送好礼活动火热进行中