敏捷发布：拥抱异步流程

糟糕的敏捷

敏捷的历史和演变

敏捷带来了工具的革命

会议是同步瓶颈

异步

异步支持分布式团队

您应该采用敏捷后方法吗？

和许多同龄的软件开发从业者一样，我还记得互联网和敏捷开发出现之前的情况。那时候，编程意味着要用昂贵的工具，还要用一堆堆放在桌上的书籍。那时还没有 Google 和 Stackoverflow。工作场所的互联网也不是很普及。我学会编程的方法是使用 Commodore 64 电脑自带的 Basic 手册。敏捷开发当时还不存在。

从那时起，情况发生了变化，而且大多是朝着好的方向发展。Kent Beck 的《极限编程》一书问世时，我非常热衷于其中的概念和理念。当时我正在攻读软件工程博士学位，甚至在 2003 年的博士论文中引用了这本书。敏捷运动（Kent Beck 当然是《敏捷宣言》的签署者之一）在很多方面彻底改变了开发方式。

糟糕的敏捷

如今，每个人都在宣称/假装自己是敏捷的。所以，“敏捷”这个词已经变得毫无意义了。每家银行​​、保险公司，甚至那些蹩脚的小软件公司都在实践敏捷。Capital A 也当然是敏捷，因为他们“照本宣科”。任何对敏捷稍有了解的人都知道，这样做是完全错误的。我曾在各种会议、讲座、研讨会等场合与一些宣言的签署者共处一室，听他们详细阐述这一点。敏捷是一套工具和一种工作方式，你可以根据需要使用和调整。把书本作为起点，而不是最终状态。如果你什么都不懂，不妨从实践开始。

我已经有点厌倦“你做错了”这种观点了，它扼杀了对Scrum之类的批评，我认为Scrum在我们这个行业已经变得有点有害了。人们要么讨厌Scrum，要么喜欢它，而且大多都是出于错误的原因（无论哪种原因）。总的来说，人们不喜欢Scrum的广泛应用，不喜欢在毫无意义的会议上无休止的争吵，不喜欢为了如何“正确”地做而浪费精力和感情，无论“正确”意味着什么。就我个人而言，在过去15年里，我参与的几乎所有项目都见证了这种情况。一些轶事证据表明，我并不是唯一一个有这种想法的人。

不管怎样，Scrum 名义上已经取代了瀑布式开发，成为一种易于掌握的模式，组织无需进行太多实际改变即可将其重塑为敏捷开发。这并不意味着 Scrum 或敏捷开发不好，只是 Scrum 似乎已经成为糟糕的敏捷实施的首选工具。Scrum 甚至有专门的术语来形容这种情况：scrumbutt。

我们这个行业里，敏捷开发模式很不完善。大多数软件开发公司和20年前一样，枯燥乏味、愚蠢低效。政府的IT项目仍然错得离谱。银行仍然在误导性项目中投入巨额资金。像Lidl这样的公司仍然任由自己被SAP这样的公司坑（高达5亿美元）。郑重声明，我把这一切都归咎于这两家公司。

现在人人都信奉敏捷，而且还有一大批自封的敏捷专家/敏捷教练之类的人来帮你找到正确的方法。很多公司会提前雇佣这些人，确保他们“按规矩办事”，但这当然违背了初衷。

无论您对此有何看法，我们行业的一个趋势是，事情正在再次发生变化，人们正在超越敏捷，寻找不同的、相对较新的软件开发组织方式。只是为了将自己与那些不善于敏捷开发的人区分开来。

敏捷开发如今已有近20年历史。不做任何改变和调整，是无法取得进步的。有些人开始将敏捷开发称为“后敏捷时代”。无论如何，Scrum 绝对不属于后敏捷开发。

敏捷的历史和演变

当《敏捷宣言》签署时，大多数人实际上并没有在实践敏捷，或者任何与之类似的东西。当时，敏捷还是一个新兴事物，而且颇具争议。人们做着各种各样的事情，并且总是混淆和混杂流程、建模技术、需求工程方法和工具。当时，大学里大多教授瀑布式开发。

上世纪 90 年代末到 21 世纪初，人们尝试对建模语言进行标准化。UML 由此诞生，一度风靡一时，像 Rational（后来被 IBM 收购）这样的公司试图将其打造为开发流程的核心。结果，Rational Unified Process在当时被认为是时尚潮流，在当时看来，可以说是对敏捷方法的反制。Rational 和 RUP 最终落入了 IBM 手中；IBM 可以说是当时（以及现在）最不敏捷的公司之一。当时，蓝西装/白衬衫在 IBM 仍然非常流行。标准、认证、培训和相关咨询业务蓬勃发展。

UML 和 RUP 延续了瀑布式开发的传统，即先进行详细设计（当然要用 UML），然后完成需求规范（也用 UML，多方便啊），再进行实现工作，最后才开始测试。简而言之，这些工作也应该用 UML 和所谓的模型驱动开发来完成。值得庆幸的是，如今在严肃的软件开发讨论中，MDA 以及一系列（现在已经被废弃的）用于实现这些功能的软件已经很少被提及了。

但 RUP 也是迈向敏捷的垫脚石。Rational 也尝试过迭代。这意味着你必须在一个项目中多次使用瀑布模型；大约每季度一次。Rational 的前提是，这需要工具，大量的工具。非常复杂的工具需要大量的咨询。这就是 IBM 收购 RUP 的原因，IBM 通过让组织实施 RUP、培训软件架构师以及出售昂贵的软件许可证赚取了巨额利润。在那个年代，任何有自尊心的软件架构师都会有一些印有 Rational 标志的盒子和书籍。他们会挥舞着令人印象深刻的图表，通常会有大量的架构和设计文档，其中包含更多的图表。

敏捷开发极具破坏性，主要是因为它戳破了那个泡沫。抱歉，我使用了不太恰当的双关语。它在大约五年的时间里就消失了。从2000年到2005年，UML慢慢地从我们的生活中消失了。我已经很久没用过UML工具了，但我并不怀念它们。

迭代开发当然和瀑布开发一样古老。Royce 于 1970 年发表的关于瀑布开发管理的原始论文《大型软件系统开发管理》至今仍值得一读，并且很快又有关于螺旋开发和迭代开发的论文对其进行了补充。

反馈循环是个好东西；每个工程师都知道这一点。事实上，Royce 在那篇论文里提到了迭代！论文里引用了这样一句话：“尝试重复做两次——第一次的结果提供了最终产品的早期模拟。” Royce 在 1970 年尝试敏捷开发。当然，他的工作被简化为：先确定需求；把需求定下来，然后转化为设计和实现，或许再做一些测试/修复 bug，最后就把它扔到墙外走人了。有趣的是，“瀑布”这个词根本没有出现在 Royce 的论文里！关于瀑布的原始论文根本没有提到瀑布。不要因为瀑布而责怪 Royce。从第一天起，瀑布就不存在了。

敏捷宣言和运动的成果是，瀑布式泡沫破灭，迭代开发成为常态。大量的UML设计文档会减慢迭代速度，并使迭代变得困难。如果你的目标是迭代，就不能浪费时间。人们发现，这种通常不完整且过时的文档的附加价值值得怀疑。

结果是，UML 成了白板上的玩意儿，从此就成了完全可选的东西，如今在软件规划中根本不会提到它。需求文档也一样。这本来有点像黑魔法。敏捷开发的人发现，指定想要修改的内容与现有内容的细微差别要比预先指定所有内容更容易。毕竟，事先指定所有内容总是会出错。

摆脱这样的项目官僚主义，可以缩短周期、加快迭代速度，并将开发重点集中在可工作的原型上。极限编程就是将这一点发挥到极致，在当时，冲刺周期可以短至几周。在一个项目可能耗时数月甚至数年甚至无法生成可工作代码的行业中，这可是闻所未闻。

敏捷带来了工具的革命

问题跟踪器等工具增强了这一点。Bugzilla是第一个获得广泛关注的流行工具。这大约发生在敏捷开发兴起的时期。问题跟踪器将需求转化为一种新的工作方式。您无需编写规范，而是以要跟踪的问题的形式指定变更请求。最初，它仅用于跟踪错误，但很快扩展到跟踪几乎所有类型的变更。同样，维基百科取代了设计和产品文档。

敏捷催生了许多新工具的采用和开发；其中许多工具源自开源社区。如今，任何优秀的项目都配备了问题跟踪器、某种去中心化的版本控制系统（通常是 Git）、持续集成 (CI) 工具、wiki、IRC 或 Slack 等沟通工具。这些工具至关重要，它们正在持续改变人们的工作方式。其中一些工具由 Atlassian、Gitlab 和 Github 等公司在云端运行。微软最近收购 Github 也表明了这些工具的重要性。

开源世界始终是分布式的，永远无法依赖会议。因此，他们采用了支持其工作方式的工具和流程。早期项目使用邮件列表和新闻组等工具；以及 CVS、RCS 等版本控制系统，以及后来的 Subversion 和 Git 等版本控制系统。同样，Irc 比 Slack 早出现几十年，并且仍然是某些项目的首选沟通方式。如今在企业项目中普遍使用的 Github/Gitlab 上的拉取请求 (Pull Request) 实践，源于通过邮件列表和新闻组交换补丁的做法。最终，Git 的诞生是为了简化这一过程，Github 也为其创建了用户界面 (UI)。

在敏捷宣言签署时，许多工具并不常见（甚至不存在）。然而，敏捷人士欣然接受了这些工具，并催生了 DevOps 运动，将运维经验和职责整合到团队中。Devops 带来了更多工具，例如部署自动化、docker、kubernetes、PAAS、SAAS、chatops 等等。

所有这些工具及其相关实践正在慢慢形成一个后敏捷世界。

会议是同步瓶颈

敏捷开发用结构化流程取代了瀑布开发，从而以迭代的方式组织开发。上述工具大多是后来才出现的。敏捷开发的一个意想不到的副作用是带来了大量的新会议。和任何一位工程师谈论 Scrum 之类的事情，你几乎都能列出他们必须参加的会议：冲刺计划、估算、回顾、评审，当然还有站立会议。Scrum 的教科书式实施本质上就是无休止地循环进行此类会议。我认识的大多数工程师都讨厌会议，或者充其量将其视为必要之恶。

随着后敏捷时代的到来，人们发现会议的附加值值得怀疑，而且也存在一些有助于摆脱会议的工具。我最喜欢的.com时代幸存下来的公司之一，despair.com，至今仍在销售一张很棒的海报，上面写着：会议。我们之中没有人比我们所有人更愚蠢。我参加过不少与Scrum相关的会议，每次都会想起这张海报。

会议本质上是时间同步的，通常也包括空间同步。它们要求人们在特定时刻聚集在一个房间里。这非常容易造成干扰，因为人们必须停下手头的工作，前往会议现场，共同讨论、商议并最终做出决定。视频会议工具在这方面不太适用，远程与会者在这类会议中通常处于极大的劣势。

异步

在后敏捷时代，人们保留了从开源软件团队学习的工具和一些敏捷实践。然而，他们放弃了会议，并普遍消除了流程中的同步瓶颈。这就像告别繁琐过时的 UML 图、糟糕的需求规范以及缓慢的瀑布式开发节奏一样，令人感到自由。我有很多朋友和同事在遍布全球的分布式团队中工作。

后敏捷开发的关键在于一些实践。关键的推动因素是持续部署或持续发布。简而言之：如果内容准备就绪，就立即发布，以尽可能缩短反馈周期。开源软件社区率先发现了这一点。Mozilla 的夜间构建几乎自其开源产品问世以来就一直存在。频繁发布对于通过问题跟踪器收集反馈至关重要。你无需等到两周后的下一次回顾会议或其他任何里程碑之后才获得反馈。你可以使用工具和自动化流程来确保这一切以可控且可预测的方式进行。

持续部署需要高度自动化。它需要持续集成：也就是说，自动评估产品是否适合立即发布。每次变更都会触发持续集成构建。持续部署 (CD) 消除了发布管理的负担，而持续集成 (CI) 则让产品经理无需手动测试和批准发布。

持续集成则需要能够自动运行的测试，这些测试要覆盖足够多的产品内容，让人们确信产品能够按预期运行。自动化测试的目标是避免在任何软件发布的关键路径上进行手动测试。

持续部署还需要具备分支和合并变更的能力。为了保持生产分支的稳定性和可发布性，必须持续在分支上进行工作，直到达到足够好的状态。

Git 是实现这一目标的关键推动者，也是另一个从开源软件 (OSS) 领域涌现出来的工具。在 Git 出现之前，版本控制系统一直是组织机构面临的巨大瓶颈。分支操作极其繁琐，而且极其复杂，以至于后续的合并需要大量的规划。组织机构经常在合并方面遇到瓶颈。提交冻结和类似的做法可以缓解这种情况。Linus Torvalds近 25 年来一直负责世界上最大的开源软件项目 (Linux)，围绕分支和合并进行的所有规划和协调工作让他非常恼火，因此他发明了 Git。Git 规范并改进了 Linux 开发社区一直在实践的异步变更管理。

当然，Linux 仍然依赖邮件列表来使用 git。Linux 开发者通过电子邮件交换 git 补丁（即导出提交的文本，而不仅仅是差异）。然而，一家名为Github的公司出现了，它让 Git 对大众更加友好，并为我们带来了一个敏捷开发的关键工具：拉取请求 (Pull Request)。它本质上和 Git 是一样的，但审查和合并的流程由一个美观的 Web UI 来支持。

拉取请求 (Pull Request) 是一种异步管理软件变更的方式。敏捷开发刚起步时，版本控制是通过 CVS 完成的（Subversion 当时还处于 Beta 阶段），分支被认为是一种非常危险的做法，最好避免。当时，很多公司都没有版本控制系统或分支系统。

拉取请求、持续集成 (CI) 和持续交付 (CD) 都是强大的工具，可以消除软件开发中的许多同步瓶颈。您可以通过问题跟踪器启动某个主题的工作，在该工具、邮件列表或 Slack/Skype/IRC 等平台上进行讨论后，创建一个分支并开始工作。完成后，您可以创建一个拉取请求 (PR)。相关利益相关者提供反馈（在被分配或 @tagged 后）。同时，持续集成确认所有变更已准备好合并。PR 获得批准后，将被合并。这反过来会触发自动部署。软件变更的整个生命周期可以完全异步进行。人们会在问题跟踪器和拉取请求中同步工单，并通过异步通信工具进行升级。当出现问题时，系统会识别相关的 PR，并使用 git 历史记录和问题跟踪器来查明发生了什么，并在必要时创建一个新的 PR 来还原或修复问题。工具有助于决策、规划、审计和自动化，并影响传统瀑布模型的所有生命周期。

异步支持分布式团队

异步可以减少会议，消除Sprint作为必要或有意义的工作单元的必要性，并允许您以小时而不是数周进行迭代。异步还使您能够按地理位置分配工作。会议对此是一个障碍，因为它要求人们身处同一地点和时区。如果您的员工遍布各大洲，这两种方式都不切实际。通过异步，人们可以通过问题、拉取请求和Slack协调工作并同步，同时围绕发布、部署等的决策也将实现自动化。

这让你基本上可以摆脱所有与敏捷相关的会议。所有会议。这就是为什么我相信，有效地实现异步和分布式办公能将我们带入后敏捷时代。站立会议在分布式团队中并不实用，所以这些会议就此消失。通过视频电话进行冗长的冲刺计划和估算会议也不实用。冲刺本身也不再必要。等等。

您应该采用敏捷后方法吗？

现在每个人都应该跟风，开始后敏捷开发吗？我认为不应该，你应该只做适合自身情况的事情。就像你当初在敏捷开发中应该做的那样。然而，真正有帮助的是反思你在组织中处于什么位置，包括你在做什么、你想要实现什么、你拥有哪些工具和流程、你的瓶颈是什么，以及如何随着时间的推移改进你的流程和工具。你可能已经使用了很多上面提到的工具和实践。

我认为分布式团队和公司是后敏捷时代的关键驱动力。异步工具和实践是实现这一目标的关键因素。分布式部署拥有诸多经济优势，这可能会促使人们更加倾向于分布式部署，减少会议瓶颈。例如，当人们不必搬到总部办公室时，招聘会变得更加容易。您可以接触到全球人才库。无需在旧金山或伦敦等高成本城市设立昂贵的办公室也是一大优势。无需将两位数的研发预算百分比浪费在会议和相关的差旅上，也是一大优势。每两周让所有人待在会议室一整天，进行与Scrum相关的规划和仪式，将花费您开发预算的10%。在旧金山这样的地方，投资者会为此投入巨额资金，因为那里的工程师成本高昂。

如果您想利用这些优势，您需要思考如何将异步集成到您当前的流程中。继续执行 Scrum 并同时实践后敏捷实践完全没问题。许多公司都这样做。这并不是要跳槽，而是要反思您正在做什么、为什么这样做以及如何有效。就我个人而言，我一直更喜欢看板式流程，因为它们更容易与异步操作保持一致。无论您做什么，都请不要教条主义。