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

[[347042]]

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

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

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

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

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

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

2. 積壓事項(xiàng)管理

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

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

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

3. 與Scrum團(tuán)隊(duì)保持同步和一致

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

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

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

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

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

4. 整合兼職和共享資源

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

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

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

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

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

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

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

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

近年來，新的合同組織形式紛紛出現(xiàn)，這種形式的重點(diǎn)是在實(shí)現(xiàn)特定定義時采用激勵和懲罰的定義。正在考慮用規(guī)?；艚莘椒ń鉀QERP問題的團(tuán)隊(duì)必須尋找該領(lǐng)域的專家來了解這些新形式。