从敏捷方法到敏捷RPA，敏捷开发原则如何助力RPA高效实施应用？

从敏捷方法到敏捷RPA，敏捷开发原则如何助力RPA高效实施应用？

30%到50%的RPA项目以失败告终，敏捷方法如何助力RPA高效实施？

当敏捷开发遇到RPA，敏捷RPA缘何成为RPA高效开发实施的护航舰？

文/王吉伟

与传统自动化相比，RPA 不仅易于使用且实施成本更低，且成效明显。相关数据表明，RPA可以稳定地将运营成本平均降低 25-50%。

Gartner数据显示，RPA市场价值在2020年便已激增至13亿美元。Forrester则预测，到2025年，全球RPA市场规模将达到225亿美元，其中RPA软件市场规模65亿美元，RPA服务市场更是高达160亿美元。

随着RPA与AI、流程挖掘等技术的深度融合，其应用场景也越来越多。更大的优势，让RPA成为十年以来最吸引企业想象力以及钱包的自动化技术。这也使得RPA的普及度进一步加速，正在被越来越多的组织采用。

但，RPA 并非没有缺点。RPA的脆弱性对业务流程稳定性造成的极大挑战，也在一些组织中的规模化应用中表现得越发明显。安永在2020年的一项数据调查中就曾指出，30% 到 50% 的RPA项目以失败告终。

尽管 RPA 和智能自动化项目失败的原因不止一个，但流程选择不当、缺乏治理以及最终不符合标准的项目管理实践往往是主要促成因素。

这就引出了一个问题，RPA 相关项目管理和软件开发的敏捷方法能否帮助确保成功?事实上，为了防止拓展RPA的挑战和失败，一些大型组织已经采用敏捷方法来实施和推动其自动化计划。

实践证明，这些组织采用敏捷原则开发、应用和维护RPA，可以让RPA在业务中获得更好的治理、更灵活的扩展能力、效率和大大降低的成本，进而减轻各种实施风险和频繁返工。

当RPA的开发与应用引入敏捷方法之后，一种更高效的RPA应用与实施方法论也就出现了，UiPath等厂商及组织将其称为敏捷RPA。

什么是敏捷RPA？为什么RPA需要敏捷方法？敏捷开发原则如何助力RPA成功？本文，王吉伟频道就跟大家聊聊这些。

从敏捷开发说起

在软件开发领域，大多数软件开发和技术实施一直都是按顺序、逐步的过程部署的，长期以来主流开发模式都是瀑布模型。这是一种“重型”的开发模式，整个流程走完通常周期很长，少则数月，多则数年。长周期导致风险增加、难以响应变化。

直到2001年，17 位知名软件开发人员齐聚一堂，讨论替代瀑布模型这种重量级软件开发过程的新方法。把大家都认同的理念整理出来，这就是后来的敏捷宣言，并成立了敏捷联盟。

自此，软件开发诞生了新的“轻量级”迭代模型，后来大家将其统称为敏捷。

敏捷宣言指出：敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则。

如果说各种敏捷框架、方法论和工具是“术”，告诉大家敏捷开发的方式，那么敏捷就是“道”，以一套价值观和原则指导大家在软件项目开发中做决策。

敏捷宣言基于12条原则，主要有4个核心价值观，如下图。

4个核心价值观，强调了协作与即时性的作用，增加了客户参与度，并进一步将软件开发从面向过程转变为面向对象。这种转变，也使得它与瀑布模型有了明显的区别。

正如敏捷联盟所解释的那样，“将敏捷与其他软件开发方法区分开来的一点是，关注工作的人以及他们如何一起工作。解决方案通过自组织跨职能团队之间的协作而发展，利用适合其背景的适当实践。”

敏捷开发要做的，就是解决瀑布模型这样的重型软件开发方法存在的问题，用一种轻量的、敏捷的方法来改善甚至是替代它。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

因此，它与传统开发模式的另一个不同之处就体现在，它将项目分解为小的、可消化的增量，称为“冲刺” (Sprint)。在整个项目全生命周期中不断评估需求、计划和结果，使变更成为流程的有机组成部分。

敏捷RPA与敏捷交付

虽然更多的RPA开发者是没有编程基础的一线业务人员，但这些平民开发者也参与了软件开发过程，所以还要遵守一定的软件开发逻辑。比如，采用某种软件开发方法论或者某种开发模型。

扩展阅读：一线业务人员即将成为RPA开发大军，距离RPA人人可用还有多远?

与传统软件开发的区别是，RPA、低代码等技术简化了软件程序的开发过程，因此更加注重交付环节。出于对于自动化、程序及开发平台等的理解不同，不同业务线的工作人员开发出的自动化程序在逻辑上也会有一些不同，会使得这些自动化程序的稳定性降低，脆弱性也会不同程度的增加。

大量业务人员的并行开发，会带来大量的自动化程序。而这些程序能不能高质量交付，或者如何保障这些程序的高效交付，也成了自动化程序交付的主要问题。

敏捷开发已成主流的现在，在主流RPA厂商的影响之下，RPA在开发与交付方面同样正在摒弃传统的瀑布式开发等模式，而是尽力向敏捷开发靠拢。由此，诞生了敏捷RPA（Agile RPA）。

前文我们讲过，敏捷不是一个过程，而是一组价值观。敏捷RPA也不是单纯指某种技术，而是指RPA交付的哲学。

在实践中，这种交付理念得到了一组轻量级流程框架（例如Scrum、看板、SAFe、Nexus、LeSS）和操作技术（例如CI/CD）的支持，帮助RPA团队将这些价值付诸实践。

所以，执行敏捷开发和成为敏捷组织是有区别的：前者的重点是过程和技术，后者的重点则是由敏捷原则和价值观指导的行为。

敏捷交付，是迭代式交付和增量式交付的组合。为实现某个业务流程的自动化而进行的增量交付，可能意味着一个接一个地自动化一些流程组件，以更好的效果发布它们，并在下一个版本中自动化其他流程组件。

迭代交付可能意味着以低保真度自动化所有流程组件，发布它们，然后在下一个版本中提高流程组件的自动化保真度。

在自动化程序开发中，增量是添加流程组件到自动化中，迭代则是转化为自动化中的“优化流程组件”。因此，以敏捷的方式交付自动化业务流程，意味着以低保真度逐个自动化一些业务流程组件，然后发布它们，然后逐渐提高其自动化保真度，并自动化其他流程组件和下一个版本。

一般而言，经典交付意味着一次为整个自动化业务流程执行一项活动（例如，设计、开发、测试、部署），而敏捷交付意味着同时为整个自动化的业务流程的一个子集执行所有活动。

因此，敏捷RPA交付的关键是经常生产“工作机器人”（又名机器人增量），以实现频繁反馈。对于工作机器人，大家可以理解为为利益相关者创造价值的最终自动化业务流程的子集。

需要说明的是，在敏捷RPA交付中，没有什么是真正被认为是最终的，因为您总是可以在功能、性能、可靠性、稳定性、安全性、可用性（例如，有人值守的机器人）和许多其他属性方面拓展自动化。

因此，从某种意义上说，敏捷RPA交付的目标不是要完美，而是要逐渐减少无意义的开发行为。

为什么RPA需要敏捷方法?

根据德勤（2018）的数据，78%的实施了RPA的组织预计在未来3年内会大幅增加投资。然而，其中只有3%的人能够将RPA扩展到初始试点之外。与自动化相关的维护工作，是阻止公司扩展RPA的决定性因素。

维护是一个总括术语，它封装了与RPA相关的各种问题。高维护RPA主要是由脆弱的RPA引起的，脆弱的RPA便意味着不稳定的RPA，会导致机器人程序中断生产。

导致机器人中断运行并持续投入维护的三个主要原因如下：

1、自动化本身的问题。由于机器人和软件应用程序之间的同步问题，由于对象识别能力差，或者由于没有或缺少恢复、异常或错误处理，机器人正在中断生产。

2、应用程序问题。这些问题，是因为对机器人使用的软件应用程序所做的更改造成的。这些更改由软件开发团队进行，包括技术更改(例如，更改UI控件、API定义)或软件应用程序的业务逻辑更改。

3、环境问题。这些问题通常由IT运营团队造成，包括性能问题、依赖第三方服务引起的问题、数据相关问题、系统更改引起的问题(例如，防病毒更新、安全修补程序、浏览器更新)，或对打包的CRM/ERP应用程序(例如，SAP、ServiceNow、Salesforce)进行自定义以考虑法规更改而引起的问题。

如果不够重视这些上述问题，你的RPA项目很可能会以失败告终，或者无法通过拓展更多的业务场景实现更高的ROI。

事实证明，已经上线几个月又需要重新设计的RPA项目并不少见，因为不可预见的问题引发了RPA实施的复杂性。如果这些项目在立项之初就能遵循一些敏捷原则，则可以避免很多问题而不至于重新设计。

对于RPA项目而言，敏捷方法能够带来的好处大概有以下几点：

首先，敏捷方法要求创建跨职能团队，打破孤岛并促进业务/IT 协调，这是 RPA 成功的必要条件。

其次，如前文所述，RPA相当脆弱，对变化反应不佳。与传统方法不同，敏捷方法为实施后的持续、迭代更改和升级留出了更多空间。

第三，也是最最重要的，敏捷提供了在整个企业中扩展 RPA 和智能自动化所需的治理框架。在这些场景中，组织可以采用类似工厂的方法来实施由可重用组件、工作流、标准和指南、工具和参考实施组成的 RPA。这种方法不仅成本高、劳动效率高，而且还能带来更高质量和更安全的 RPA 应用程序。

RPA的目标是通过消除重复的、低价值的任务以增强人类工作体验，因此它必须与最终用户共同实施。这个逻辑，与敏捷方法鼓励的尽早并经常与利益相关者密切合作不谋而合。

并且，RPA正在不断降低使用门槛与开发难度，这本身就是敏捷开发的一部分。

敏捷开发原则如何助力RPA 成功?

RPA与纯软件和产品开发有很大不同，但是可以借鉴和应用基本的敏捷原则来产生相同的结果：更快地交付价值，同时降低成本和风险。

流程不是产品，不能与纯软件开发相同的方式开发和部署，因此敏捷RPA不能遵循敏捷Scrum框架（迭代式增量软件开发过程，敏捷方法论中的重要框架之一）的每一条原则。

但是，敏捷Scrum方法的各种元素可以为有远见的组织提供更多红利，大家可以借鉴敏捷开发的方法与逻辑，加速规模并建立RPA卓越中心（CoE）以及相似的组织，以保障自动化能够更高效的助力企业提质增效降本。

敏捷方法，至少可以让组织在RPA实施过程中做到以下几点：

更懂协作的团队。RPA 的敏捷方法包含一个由不同利益相关者组成的专门团队，他们紧密合作，包括开发人员、测试人员和业务角色。这不仅增强了识别 RPA 机会的有效性，而且还促进了大规模治理，因为专门的团队可以更好地管理和协调影响业务和运营不同部分的自动化流程。

更优质的设计和定义。在机器人流程自动化的敏捷方法中，业务流程在任何开发开始之前就被设计和优化。这使大型组织能够完全标准化和优化端到端、复杂和多层的业务流程，成为真正的自动化投资回报率所在。

它还为他们提供了宝贵的机会来考虑这些流程并将其与更大的业务目标和企业或监管约束、政策和控制联系起来。

自动化基本的战术流程要简单得多，但从长远来看，其价值回报率也会显着降低。大规模阻碍 RPA 的主要障碍是自动化更复杂的流程并确保透明有效地遵守法规。促进预先定义和设计以确保优化和法规遵从性的方法极大地使有意愿的企业能够克服这一挑战。

更高效的积压维护。要扩展 RPA，机器人必须变得更大、更复杂。积压工作能够让组织将复杂的端到端流程分割成多个工作项或故事，并将它们作为积压工作独立地确定优先级。

积压也是有效管理机器人维护的关键。随着许多机器人和不断发生的变化，维护工作可能会消耗积压并扼杀提供价值和创新的新项目。因此，有组织的优先排序方法至关重要。

冲刺计划和回顾。与在项目开始时定义的时间表不同，计划短暂的工作突增或冲刺使团队能够在出现需要解决的问题时重新确定工作的优先级。而不是在项目结束时意识到不对劲，导致返工并因此增加成本。

Sprint回顾还可以使团队能够随着工作的进展吸取经验教训，并将其融入整个 RPA 工作中，进而避免在下游犯下相同的错误并及时实施良好实践。

后记：因人而异择优而选

看到这里，大家应该对敏捷RPA有了一定的了解。关于敏捷RPA，很多人看完可能会感觉非常复杂。其实想要实现敏捷RPA也很简单，就是建立RPA卓越中心，然后告诉RPA CoE管理者要引入敏捷方法，并坚定不移的支持其工作就可以了。

但说起来容易做起来难，因为要改变大型组织固有的IT组织架构及开发逻辑，着实是一个难上加难的问题。

所以，这篇文章的用意，并不是告诉大家在RPA建设与应用上一定要严格遵守敏捷方法，而是说在RPA引入时可以适当参考敏捷方法，以避免在后面的RPA应用中出现太多问题而导致项目搁浅，同时也为基于自动化获得更高的ROI打下更好的基础。

同时大家也应该知道，每个组织的信息化程度不同，IT建设情况不同，程序开发的理念也不同，这就决定了不是每个组织都适合采用敏捷方法进行各种项目开发。

敏捷RPA交付有许多好处，但它也带有敏捷方法固有的某些风险。因此敏捷方法并不适合每个组织，这取决于组织的情况以及如何下定决心克服困难去采用敏捷。如果参与RPA交付的人员不愿意紧密协作，很可能以敏捷的方式工作会成为一场IT与流程变革的灾难。

所以，在敏捷方法与RPA项目上，不要将敏捷实践和原则强加给那些不愿采用敏捷的人，只需要给人们正确的信息让他们说服自己。

也不要试图说服别人，只需要告诉并解释敏捷能够带来了什么就可以了。

剩下的，全部交给决策者。

【王吉伟频道，关注TMT与IoT，专注数字化转型、业务流程自动化与RPA。】