与传统自动化相比，RPA（Robotic Process Automation）不仅易于使用且实施成本更低，成效明显。据数据显示，RPA可以将运营成本平均降低25-50%。随着RPA与AI、流程挖掘等技术的融合，应用场景不断增多，使得RPA成为企业追捧的自动化技术。然而，RPA存在脆弱性挑战业务流程稳定性的问题。为防止拓展RPA带来的挑战和失败，一些有想法的杰出人士采用敏捷方法来实施和推动自动化计划。实践证明，敏捷方法使RPA在业务中获得更好的治理、更灵活的扩展能力、效率和降低成本，减轻实施风险和返工。因此，敏捷方法实话的RPA成为一种更高效的RPA应用与实施方法结合架构。
从敏捷开发说起
在软件开发领域，传统的瀑布模型需要很长时间才能完成整个流程，而且风险高、难以应对变化。于是，2001年17位知名开发人员聚集在一起讨论替代瀑布模型的新方法，最终形成了敏捷宣言和敏捷联盟。
敏捷开发是一种“轻量级”的迭代模型，强调协作和即时性，增加客户参与度，并将软件开发从面向过程转变为面向对象。它与瀑布模型有着明显的区别。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。它将一个大项目分为多个相互联系的小项目（冲刺），并在整个项目生命周期中不断评估需求、计划和结果，使变更成为流程的有机组成部分。
总之，敏捷开发旨在解决瀑布模型存在的问题，用一种轻量、敏捷的方法来改善或替代传统的重型软件开发方法。
敏捷开发的核心价值观强调个体和互动优于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。这些价值观重视协作和即时性，增加客户参与度，并将软件开发从面向过程转变为面向对象。
在敏捷开发中，软件项目被切分成多个子项目，每个子项目都经过测试，具备可视、可集成和可运行使用的特征。这意味着一个大项目被分为可独立运行的小项目，并且在整个项目生命周期中不断评估需求、计划和结果，使变更成为流程的有机组成部分。
与传统的瀑布模型相比，敏捷开发更加灵活和适应变化。它侧重于快速交付有价值的软件，通过持续反馈和迭代改进来满足客户需求。敏捷开发能够更好地应对市场和技术的变化，提高项目的成功率和效率。
总而言之，敏捷开发是一种注重协作、适应性和客户参与的软件开发方法。它通过迭代和循序渐进的方式，将大型项目分解为小而可行的增量，以提供更快速、高质量且符合客户需求的软件产品。
敏捷RPA与敏捷交付
虽然很多RPA开发者没有编程基础，但他们也参与了软件开发过程，所以仍然需要遵守一定的开发逻辑。与传统软件开发不同，RPA和技术简化了程序开发过程，因此更加注重交付。由于对自动化和开发平台的理解不同，不同业务线开发的自动化程序在逻辑上会有一些差异，可能会降低稳定性并增加脆弱性。
大量的业务人员并行开发会导致大量的自动化程序。这些程序能否高质量交付，或者如何保障高效交付，成为自动化程序交付的主要问题。现在敏捷开发已成为主流，受到主流RPA厂商的影响，RPA也在摒弃传统的瀑布式开发模式，向敏捷开发靠拢。这诞生了敏捷RPA（Agile RPA）。
敏捷RPA不是一个过程，而是一种价值观。它通过一些轻量级流程框架和操作技术的支持，帮助RPA团队将这种价值观付诸实践。执行敏捷开发和成为敏捷组织是有区别的：前者关注过程和技术，后者则由敏捷原则和价值观指导行为。
敏捷交付是迭代式和增量式交付的组合。为实现某个业务流程的自动化进行的增量交付可能意味着一个接一个地自动化一些流程组件。而迭代交付则意味着以低保真度自动化所有流程组件，然后逐渐提高其自动化保真度，并自动化其他流程组件和下一个版本。
在敏捷RPA交付中，关键是经常生产“工作机器人”，为利益相关者创造价值的最终自动化业务流程的子集。需要注意的是，在敏捷RPA交付中，没有什么是真正被认为是最终的，因为可以在功能、性能、可靠性、稳定性、安全性、可用性等方面不断拓展自动化。因此，敏捷RPA交付的目标不是要完美，而是要逐渐减少无意义的开发行为。
为什么RPA需要敏捷方法?
根据调查数据，78%的实施了RPA的公司预计在未来3年内增加投资。但是只有很少的公司能够将RPA扩展到初始试点之外。维护工作是阻止公司扩展RPA的主要原因之一。导致机器人中断运行并持续投入维护的三个主要原因是自动化本身的问题、应用程序问题和环境问题。
在当前的技术环境中，机器人流程自动化（RPA）已经成为了许多企业日常运营的重要部分。然而，有时候我们可能会遇到RPA机器人中断运行并需要持续投入维护的情况。这种情况的出现可能由多种原因引起，以下将详细解析其中的三个主要原因：
1. 自动化本身的问题
首先，自动化本身的问题也是导致RPA机器人中断运行的一个重要原因。这可能包括程序设计错误、算法问题、或者是系统内部的错误。例如，如果一个RPA机器人被编程为在特定的条件下执行某个任务，但是这个条件在某些情况下并不满足，那么机器人就可能会中断运行。此外，如果RPA机器人的算法存在缺陷或者设计不合理，也可能导致其无法正常运行。这些问题通常需要开发者对RPA机器人进行详细的检查和修复。2. 应用程序问题
其次，应用程序问题也是导致RPA机器人中断运行的一个重要因素。这可能涉及到应用程序的稳定性、兼容性以及与RPA机器人的交互性等问题。例如，如果RPA机器人正在运行的应用程序发生了严重的错误或者崩溃，那么RPA机器人可能也会因此中断运行。此外，如果应用程序与RPA机器人的接口设计不合理，或者存在难以预料的交互问题，也可能使RPA机器人无法正常工作。解决这类问题通常需要对应用程序进行深入的分析和调试。3. 环境问题
最后，环境问题也可能是导致RPA机器人中断运行的一个重要原因。这可能包括硬件故障、网络问题、或者是系统资源不足等。例如，如果RPA机器人所在的服务器发生故障，或者网络连接不稳定，那么RPA机器人可能就无法正常运行。此外，如果系统资源（如内存、CPU或磁盘空间）不足，也可能导致RPA机器人无法正常运行。解决这类问题通常需要对环境进行全面的检查和优化。
如果忽视这些问题，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项目上，不要将敏捷实践和原则强加给那些不愿采用敏捷的人，只需要给人们正确的信息让他们说服自己。
也不要试图说服别人，只需要告诉并解释敏捷能够带来了什么就可以了。
剩下的，全部交给决策者。