敏捷RPA-如何提升自动化项目的灵活度与协作性（英文版）（29页）.pdf

1、Scrum不包括工程实践。根据Jeff Sutherland(2013)的说法，这是故意的。Scrum的设计初衷是让团队在两三天内启动，而工程实践往往需要数月才能实现。因此，当特定的工程实践不是强制性的时候，Scrum更容易采用。这就把何时以及是否实现某些工程实践的问题留给了每个团队。Scrum创建者Jeff Sutherland和Ken Schwaber建议Scrum团队立即开始，并创建障碍列表和过程改进计划。由于工程实践被识别为障碍，团队应该将极限编程(XP)的实践作为一种改进方法。最好的团队运行Scrum和XP实践。Scrum帮助XP扩展，XP帮助Scrum更好地工作。”所以，即使Scr

2、um没有提到任何关于工程实践的内容，它还是建议你使用XP。CoE决定用极限编程(XP)的工程实践来补充他们的管理实践(Scrum和看板)。目标是提高XP实践自动化的质量。这些实践包括结对编程、测试驱动开发、编码标准、设计原则、代码审查、重构、集体代码所有权和持续集成。讨论所有这些实践超出了本文的范围。Ron Jeffries(2011)对XP做了一个简短而伟大的概述。对于那些想要更深入地研究XP的人，Susan推荐Kent Beck(2004)的书。例如，在编码标准和设计原则方面，CoE编写了基于UiPath自动化最佳实践和UiPath设计最佳实践指南的质量指南，以持续将质量融入机器人过程自动

3、化。这解决了前一章讨论的自动化问题。最重要的是，Susan认识到RPA开发和软件开发之间有许多相似之处。请注意，我们指的是开发，而不是交付。Susan甚至推测RPA开发是软件开发的一种特殊情况。简单地说，RPA开发是在软件开发的内部。Susan认为，应用程序(如web应用程序、移动应用程序)和自动化业务流程都是软件。使用什么工具(如UiPath Studio、Visual Studio)来开发软件并不重要。软件是软件。你可以这样想:你可以在会议演讲中使用挂图，也可以在会议演讲中使用PowerPoint演示文稿。在这两种情况下，你都是在做会议演讲。因此，Susan总结道:“为什么不采用那些被证明

4、对快速、持续地改进软件有价值的工程实践，并将它们应用到RPA中呢?”如果它适用于软件开发，那么它也适用于RPA开发。苏珊的成功证明她是对的。CoE最终应用了敏捷RPA交付的框架，它是Scrum、看板和XP的良好结合。苏珊将其称为XrumBan，即敏捷RPA的“三位一体”。快进。RPA倡议取得了巨大成功。员工们对RPA越来越感兴趣。对RPA的需求开始飙升。因此，CoE不仅需要增加人员，还必须调整其交付流程，以满足日益增长的需求。CoE从2018年的一个团队发展到2020年的一个小部门。首先，让我们谈谈角色。Susan根据BizDevOps组合词将角色按业务、开发和运营进行了分类。Susan承担了

5、所谓的RPA变更经理的角色。在这个角色中，她的职责是双重的。首先，Susan负责确保RPA在组织中易于采用，监督来自业务、IT Ops和软件开发的涉众的入职，并通过一个清晰、开放和鼓舞人心的沟通和倡导计划来宣传RPA。她的任务是让涉众充分了解RPA的采用情况，并轻松地调整所发生的变化。在内部，苏珊被称为RPA首席传教士。她有一种罕见的天赋，可以找到并把人(比如部门领导)变成热情的PRA冠军。这些RPA冠军帮助传播关于RPA的消息，并鼓励其他部门的领导效仿。这确保了一个健康的自动化管道。苏珊还确定了执行层面的RPA赞助商，并让他们积极参与。RPA发起者是将RPA计划作为企业范围的战略优先级建立起来的关键，他们为企业资源提供担保，获得对等方的合作，清除障碍，并维持组织中由于RPA而发生的变化。我们将在第3.11章详细阐述这个福音和协作方面。其次，苏珊是RPA倡议的所有者。