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

 

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

 

 

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

 

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

 

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

 

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

 

 

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

 

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

 

 

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

 

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

 

版權(quán)聲明：本文為企業(yè)網(wǎng)D1Net編譯，轉(zhuǎn)載需注明出處為：企業(yè)網(wǎng)D1Net，如果不注明出處，企業(yè)網(wǎng)D1Net將保留追究其法律責(zé)任的權(quán)利。