克服下述難題是將敏捷用于ERP實施的關鍵。為此一切努力都是值得的。

[[347042]]

根據(jù)IT標準，敏捷方法已經存在了很長時間，事實證明，許多公司通過該方法取得了成效。隨著公司在敏捷方法的開拓階段不斷發(fā)展和進步，這方面的付出也呈現(xiàn)了與日俱增的趨勢。敏捷的應用甚至在支持ERP的部署方面也取得了進展(眾所周知，這些項目非常復雜，需要做大量集成工作)。但是，對敏捷方法小試牛刀所獲得的收益并沒有自然而然地轉移到大刀闊虎的敏捷項目中。

經過研究發(fā)現(xiàn)，我們必須克服六個難題才能高效地為ERP實施敏捷方法并解決這些難題。

1. 關鍵決策治理

實施成功的敏捷項目需要一個重要因素，那就是小而忠誠的團隊，這個團隊由技術嫻熟的成員組成，他們可以在整個項目中做出關鍵決策。隨著項目規(guī)模的擴大，跨團隊的決策量會增加，“難以定義且雜亂無章(wicked messy)”的決策的數(shù)量也會隨之增加。這些決定往往會涉及到成功的組織和失敗的組織。當有更多團隊參與且涉及到各種成果時，確保所有團隊意見一致則更為困難，更為耗時。

利益相關者的范圍也擴大了，這進一步延長了達成共識所需的時間。敏捷的心態(tài)不利于做出大型的，跨職能的決策，因此，隨著項目規(guī)模的擴大，這變得更為困難。

為了解決這一問題，發(fā)布管理工程師(Release Train Engineer)必須對關鍵決策，早期和頻繁的社交活動承擔充分的責任并制定決策策略，從而能及時作出關鍵決策。

2. 積壓事項管理

在規(guī)模化的敏捷項目中管理積壓事項比在小型開發(fā)項目中管理積壓事項要困難得多，因為積壓事項包括許多與軟件開發(fā)并不直接相關的活動(即數(shù)據(jù)團隊支持，培訓支持，部署活動等)。

管理集成測試也可能十分困難，因為許多ERP測試需要多個團隊的參與。積壓事項管理的復雜性還體現(xiàn)在另一方面，即其中的許多項目并不受某個人的影響(在ERP中尤其如此)，而且是其他團隊直接提出的要求。這兩個方面對產品負責人提出了更高的要求，他們必須了解整個程序的范圍，從而高效地整理輕重緩急得到妥善安排并與其他團隊同步進行的積壓事項。

為了解決此問題，必須在程序開發(fā)初期開發(fā)端到端的測試策略。一旦制定此策略，產品所有者就可以更好地了解必須優(yōu)先處理的積壓事項的依賴關系和先例。

3. 與Scrum團隊保持同步和一致

敏捷項目在很大程度上取決于跨Scrum團隊的速度校準。當所有團隊之間的溝通和績效都不一致時，你最終將導致資源團隊閑置。所有團隊都必須以相同的完成度同時完成任務。

為了實現(xiàn)這一目標，所有成員必須完全接受敏捷思想并在團隊之間明確定義“完成度”。以不同的完成度定義進行操作的團隊可能會延長端到端測試所需的時間。

為了實現(xiàn)這種一致性，發(fā)布管理工程師必須執(zhí)行兩項關鍵職能：

1. 確認人們已經發(fā)現(xiàn)跨團隊的依賴關系并將其記作單個團隊的積壓事項和沖刺計劃的一部分工作內容。

2. 監(jiān)控速度并根據(jù)需要調整沖刺團隊的能力，從而使團隊的交付與預期的交付日期保持一致。

4. 整合兼職和共享資源

盡管全職成員會全身性投入項目，但他們可能必須在多個團隊中分享其時間。是否能高效分配時間將取決于他們是否能與項目中其他團隊的進度保持一致。

Scrum團隊沒有參與的兼職資源也必須得到管理。例如，負責評估的人可能只將10%的時間用于整個敏捷項目。項目經理必須幫忙協(xié)調時間，從而確保他們在需要做評估時可以靈活地參與敏捷項目。

資源預測是解決這一問題的優(yōu)秀工具。發(fā)布管理工程師(Release Train Engineer)必須在整個計劃中維持完整的資源需求預測并定期更新所有供需領域。而產品負責人將受到外部資源提供商的青睞，其方法是管理積壓訂單，從而與需求預測保持一致。

5. 實施大型項目所需的作風

為了使項目不落后，高層通常會參與正式的階段關卡評估(Stage Gate Review)，他們還要支持審查的內容。大型項目通常需要更多的輸出和文檔工作才能獲得評估委員會成員的全面支持。實施敏捷方法將遇到一個困境，這就是在整個項目中加大對增量開發(fā)的關注并在總體上減少對文檔工作的關注。這使團隊難以在董事會級別上提供支出和風險管理方面的透明度。

為了解決這個問題，我們建議產品負責人制定初步的高管介紹，然后在每次沖刺結束時更新此材料，以此作為回顧的一部分內容。董事會和高管的演講不應該只是一個活動，而應該是實現(xiàn)當前狀態(tài)并預測未來狀態(tài)。

6.供應商的責任和績效

在敏捷項目中，定義公司與供應商之間的風險分擔是更加困難的工作。大型計劃的合同通常以瀑布式或可交付成果為基礎，而賞罰措施會驅動成本和進度的績效，這使公司可以要求供應商對全面交付承擔責任。相反，當范圍可變時，敏捷方法假定成本和時間是固定的。這種情況與標準的理念相悖，即ERP的大部分范圍都不靈活。這種情況將問題復雜化的其中一個方面是定義和解決保修支持的概念。這是項目中的所有人(無論他們在客戶端還是在供應商端)，每個沖刺都必須對“完成”持相同的定義。

近年來，新的合同組織形式紛紛出現(xiàn)，這種形式的重點是在實現(xiàn)特定定義時采用激勵和懲罰的定義。正在考慮用規(guī)模化敏捷方法解決ERP問題的團隊必須尋找該領域的專家來了解這些新形式。