敏捷RPA-如何提升自動化項目的靈活度與協作性（英文版）（29頁）.pdf

《敏捷RPA-如何提升自動化項目的靈活度與協作性（英文版）（29頁）.pdf》由會員分享，可在線閱讀，更多相關《敏捷RPA-如何提升自動化項目的靈活度與協作性（英文版）（29頁）.pdf（29頁珍藏版）》請在三個皮匠報告上搜索。

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的“三位一體”?？爝M。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倡議的所有者。