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

[[347042]]

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

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

1. 關(guān)鍵決策治理

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

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

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

2. 積壓事項管理

在規(guī)?；拿艚蓓椖恐泄芾矸e壓事項比在小型開發(fā)項目中管理積壓事項要困難得多，因為積壓事項包括許多與軟件開發(fā)并不直接相關(guān)的活動(即數(shù)據(jù)團隊支持，培訓(xùn)支持，部署活動等)。

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

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

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

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

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

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

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

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

4. 整合兼職和共享資源

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

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

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

5. 實施大型項目所需的作風(fēng)

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

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

6.供應(yīng)商的責(zé)任和績效

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

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