敏捷走到头了！

作者：Kurt Cagle是一名数据科学家兼未来学家，关注计算机技术与社会的交汇。他是智能数据公司Semantical，LLC的创始人，目前在开发一个基于云的知识库，将于2020年初公开发布。

敏捷是一种强大的方法，但在日益由数据驱动的世界，它可能未必是正确的方法。

我们开始使用曲棍球棒时，我就知道敏捷走到头了。每天早上8点，一个团队的开发员和架构师会站在镶嵌有白板的房间，开始传递一根玩具曲棍球棒。你接到曲棍球棒时，应该会开始长篇大论：原谅我，上帝，我有罪。我昨天就写了两个模块，因为开了一整天的会，又饿着肚子；我的工作缺不了Joe，他本周因肺炎请病假了。

那个scrum大师（坐着的那个人，别人都站着）会在敏捷工具Rally或Jira中及时记下这点，然后会说：“你差三个模块。预计今天可以写好这些模块吗？”

“scrum大师，我会按您的要求写三个模块，我拖慢了团队的平均进度，现在有负诸位。”

“伙计，你看着办，sprint（迭代开发周期）下周二完工，管理层盯着。”

神圣的曲棍球棒随后会传递给下一个开发员；就像惴惴不安的僧侣一样，我们将该死的曲棍球棒递给下一个可怜虫时，我们其余人会长松一口气。

这不再是一种方法，它已成了一种宗教；就像大多数宗教一样，它对外人、甚至必要时对参与者来说其实没有多大意义。

敏捷起初是一个激进的概念。通过将整个产品周期分解成多个较小、易于管理的单位，并与小团队合作，可以更高效地完成项目（尤其是软件项目）。这个概念实际上仍然适用。

小即好

敏捷宣言（Agile Manifesto）与大多数此类声明一样，最初确实是个好主意。核心原则很简单：你其实不需要一大批人来开发软件项目才能完成任务。甚至正相反，到了一定程度，更多的人只会加大沟通阻力，并减慢项目进度。许多真正出色的开源项目都是由2人至12人组成的小型开发团队完成的，人数控制在7人为宜。

你的团队是这等规模时，设计几乎可以作为小组活动来完成。说到显示可证明的进展，两周是合理的时间。开会时间要短，让客户在场可以使他们了解内情。另一种方法：“瀑布方法”（Waterfall methodology）意味着，客户常常要等六个月才能看到产品；该阶段结束时发布产品通常会出现这一幕：客户缩在某个角落生闷气。

敏捷很时髦、很酷，还涉及斐波那契数列。有什么不喜欢的呢？

这些年来，我开始意识到一个微妙但很重要的特点。敏捷宣言一开始就搞错了——与其说小团队工作起来更高效是由于它们可以遵循一种精简的方法来完成项目，还不如说小团队接手小项目才得以遵循一种精简的方法、碰碰成功的运气。

开放软件项目之所以成功，就是由于完成一个项目所需的任务是比较独立的（self-contained）——可以针对任务快速编程，可以在几周内交付功能；设计可能很紧急，因为早早建好界面后不断改进是可以接受、甚至受到鼓励的做法；一旦完成，维护是别人的问题。

同样重要的是，在开源软件中，客户可能最终会过问项目几个月，因为那几个月通常是最关注设计的时段。然而项目拖得越久，其他需求就越有可能占用这个客户越来越多的时间，以至于客户的参与顶多也就看一眼。

敏捷为便条纸（Post-It Note）所做的贡献比历史上其他任何技术都要多。

变得敏捷

敏捷横空出世时，典型的软件项目恰好属于敏捷擅长的范畴内。大多数软件项目基于Web，可以在几天内建好Web界面。它们用数据库来存储状态，Web开发员通常可以随意访问该数据库。这些项目花4到6个月（8到12个为期两周的sprint）才能完成，它们主要面向客户（用户界面是体验的重要组成部分，而且客户实际上可以亲眼看到变更出现。）

它们也是如果功能被砍，应用程序实际上不会因缺少的这项功能显著降级的项目。大概在这个时候，最简可行产品（minimal viable product）概念开始深入人心——这个概念是指，头几个sprint之后，即使开发随后立马停止，产品也是有用的。

毋庸置疑，公司企业开始引起注意，变得敏捷很快成为了当时的口号。敏捷从一种粗略的宣言变成了一种正式的方法，项目经理（现在有了scrum大师这个重要的术语）将与经理合作，提出“故事”，描述他们希望产品完成什么任务（即之前所谓的需求），并提出随后成为完成那些故事所必需的步骤的“任务”，这些任务确立了经理（通过scrum大师这个代理）与开发员或设计师之间的合约。

随后会在这个框架内出现某种“舞蹈”，应用程序的整体形状发挥作用，然后出现层层深入的细节，最后是具体实施。从理论上来说，如果跟踪这些信息，你就可以确定项目是否延后；如果项目延后，分配额外的资源以改进有问题的方面。

从业务的角度来看，这是巨大的胜利。软件项目本质上对经理来说有点可怕——你投入大量资金，却不能充分保证会因投入而看到任何成效，于是能够在图上看到红色、黄色、绿色的方框可能让人稍稍安心。

估计的问题在于，它有赖于事先了解所有事实。编程本质上就是适度可知的创新。实现的敏捷方法最初旨在更好地处理这些事实。

敏捷在哪里碰壁？

当然，问题在于细节，在于人类行为的本质。

大多数项目管理立足于这个想法：任务是可度量的，基于完成这同一任务的其他人设定的度量标准。组装装配线是一项很容易预测的任务（旧经济中是这样），又由于经常组装，可以估计组装所需的时间（出入没几天）。遗憾的是，开发软件不可预测。几乎无一例外的是，就算标价很高，购买现成软件通常至少更便宜，即使从企业组织的角度来看未必总是更好。原因很简单——你寻求的功能早已存在，有人尝过了首次（数次）构建这个应用程序的苦头。

构建登录功能需要多长时间？编写用户界面大约需要一小时。编写后端代码可能短则30分钟，长则30天。如果你希望与一个只支持LDAP的非标准平台上的Active Directory验证系统全面集成，又希望将两遍（two-pass）电子邮件验证系统集成到里面，那么用户界面（UI）是你最不担心的方面。一个漂亮的网络图仪表板显示你系统中所有组件如何相互关联，并允许拖放操作，你觉得怎么样？别吓我了。我仍在做这方面的恶梦。

计算机编程界存在一种谬见：所有应用程序最终都可以分解——也就是说，可以将复杂的应用程序分解成多个较简单的应用程序。然而实际上，除非你让正确组合的组件正常运行，否则常常无法让更复杂的行为实际开始工作；就算那样，你也会在数据可用性的同步、内存使用及释放以及竞争条件等方面遇到问题——等你做好了大部分管道工作，这些问题才显露出来。

这就是为什么“但它会扩展吗？”进入各地程序员的词汇库。只有在你几乎完全构建好了系统，并尝试让系统在更极端的条件下运行时，扩展问题才出现。解决方案常常需要丢弃你刚构建的相当多组件，这让各地的经理们惊愕不已。

这就是为什么如果能助一臂之力，开发员很讨厌确定任务具体需要多长时间的原因之一。开发员要将其工作与其他开发员整合起来时，尤其是对于同时开发的那些组件而言，这就成了更严重的问题。如果两个组件的相互关系之间存在“阻抗不匹配”，重新设计那些组件可能增添难以衡量的时间和复杂性。

它还表明敏捷并不总能很好地扩展。集成依赖关系常常未加以跟踪（或被归入层次化的故事），但它往往是任何软件开发中最容易变化的方面之一。

实际上，这与其说是敏捷的错误，还不是说是其最常用工具的错误。严格来讲，这样的项目图是信息图，而不仅仅是树。你在空间、时间、组织、抽象和复杂性等方面有依赖项，针对复杂性估计时间常常是这些工具最薄弱的环节。另一方面，若有太多的人参与项目，这项工作也会变得更糟，因为管理这类项目的复杂性会逐渐加大。

这种方法的还有一个结果是，面对庞大团队，规划所需的时间常常最多占到开发可用总时间的四分之一。另一个结果是，对最简可行产品的持续强调意味着在任何一个时间点，开发员最终花费大量的时间来构建和展示他们迄今为止的工作成果，占了可用时间中另外的10%到15%，常常耗费在被扔掉的代码上。

由于这实际上在相当于两周的sprint中留给开发的时间只有“一周”，另一个缺点是你在这个sprint内只能完成最基本的组件。一旦你为scrum会议耗费了另一天，尤其如此。这种会议通常只有15分钟，但实际上，出现问题时，会议很可能越来越长。将sprint延长到三周较为明智，但实际上很少有组织这么做。

这种会议的另一个副作用影响到了经理，他们的角色决定了常常参与组织中多个层面的scrum，这意味着他们因此没多少时间从事战略性的领导工作，并迫使他们进行微观管理，通常效果不佳。

对敏捷最热衷的常常是人力资源咨询机构，尽管它们在任何项目方面的目标是，让受雇开发项目的开发员和支持人员尽可能多。这颇具讽刺意味，因为出现的情况是，敏捷在经典的瀑布方法（注重精确的规范和详细的预先规划）实际上优先的业务部门用得最多。

以数据为中心的问题不是很适合敏捷擅长处理的独立的开源领域。随着越来越多的商业项目往这个方向发展，敏捷这种方法的效用随之下降。

数据项目和后敏捷世界

除此之外，值得一提的是，对大批的项目而言，传统的敏捷方法适得其反。尤其是企业数据项目不符合适合使用敏捷的标准，这有几个原因：

企业数据系统（EDS）格外重视数据建模，视数据源和组织规模而定，复杂性决定了需要短则几天、长则几个月。

EDS项目往往专注于查询、转换和数据移动（摄取和服务），没有一个通常面向客户。

EDS项目通常在进行中，需要结合自动化数据摄取和主动数据筛选，而不是有时间限制的应用程序开发。

由于EDS具有通常广泛的特性，navigator、知识库、数据中心和类似应用程序比专门的应用程序更合适，这意味着对定制开发的需求也保持在最低限度。

公平地说，虽然企业知识领域有几种开发方法，但这个领域本身足够新，没有一种方法可以像敏捷在应用程序开发领域那样在企业数据系统领域扬名立万。这应该不足为奇——近期才开始关注企业数据本身。

企业数据项目的一个关键方面不在于系统之间管道的技术集成，而在于将数据模型从一个系统映射到另一个系统，无论是通过筛选还是通过机器学习。换句话说，所开展的那种工作正从工程问题（用于连接系统的专用短期项目）变为筛选问题（通过少量的技术工具来映射模型）。

这种转变也表明了敏捷的未来最终会怎样。在许多方面，我们正告别以应用程序为中心的时代——应用程序更轻盈，主要基于Web：在这种环境下，连接至数据集和复合企业数据将比基于客户端的复杂功能更重要。移动应用程序也是如此——智能手机和平板电脑应用程序日益只是移动HTML + CSS外面那层薄薄的外壳，这与“某某有应用程序”时代相比是个巨变。

客户端是相对轻盈的端点，这意味着敏捷最初问世并最适合的那个环境：独立的开源应用程序在消失。如今，典型的应用程序更可能是某种数据流，价值不在于编程，而在于数据本身，因此编程（以及广泛得多的现有工具）比20年前、甚至比10年前简单得多。

也许这类应用程序的最后一片天地是游戏这个类别；即使在这个类别，也出现了几种一致稳定的工具集，比如Unreal Engine，这意味着技术组件日益融合，而敏捷其实完全退缩到设计和媒体创作等领域。

从长远来看这表明工作方法正朝异步事件模型发展；在这种模型中，信息流连接起来、映射，然后以不可预测的方式转换成原生模型。我们发布平台，然后发布“如同连续剧”的内容，一些小到一条推文，一些大到数GB的游戏更新。虽然敏捷的一些方面会仍然存在，但后敏捷世界有不同的优先事项和要求，我们预计最后接它班的任何范式会将信息流作为信息的基本单位来处理。

因此，敏捷没“死”，但它变得越来越边缘化。