目錄 11.1AI軟件項目需求管理的過程分析 11.1.1傳統(tǒng)瀑布方式的需求管理過程分析 11.1.2敏捷方法的需求管理過程分析 21.2AI軟件項目需求管理的關(guān)鍵因素分析 21.3AI軟件項目需求管理的Pm-Scrum模型構(gòu)建 31.1.1Pm-Scrum的整體框架搭建 31.1.2Pm-Scrum的人員組織形式 61.1.3Pm-Scrum下的需求管理模型 61.1.4Pm-Scrum下的需求變更管理模型 121.4Pm-Scrum的評價方法 151.1AI軟件項目需求管理的過程分析AI軟件項目需求的管理過程，根據(jù)不同企業(yè)不同行業(yè)采用不同的管理模型有關(guān)，傳統(tǒng)的大型軟件企業(yè)，偏重于傳統(tǒng)的瀑布式的管理模式，流程上安排順序方式執(zhí)行，每一步都輸出相應的文檔資料?？焖夙憫偷能浖荆缁ヂ?lián)網(wǎng)公司，則更傾向于敏捷方法下的需求管理模式，這種模式可以快速響應，擁抱變化，提高發(fā)布效率，同時快速響應客戶或市場的變化，進行迭代增量交付。1.1.1傳統(tǒng)瀑布方式的需求管理過程分析傳統(tǒng)項目管理理論PMBOK的核心是過程規(guī)范化和標準化管理，側(cè)重過程管理和文檔，更適合一些規(guī)模比較大、意義重大和需要盡量規(guī)避風險的項目，是一個重量方法。傳統(tǒng)瀑布式的需求管理過程，通常是按照既定的順序，先從市場或合同導入客戶的需求。根據(jù)需求內(nèi)容做進一步的分析，形成需求說明書，然后轉(zhuǎn)給開發(fā)團隊，在需求說明書的基礎(chǔ)上，進行理解和計劃，形成產(chǎn)品規(guī)格書。產(chǎn)品規(guī)格書，作為團隊開發(fā)的重要指導資料，指導團隊進行開發(fā)和測試。如圖3-1所示：圖3-1傳統(tǒng)瀑布方式的需求管理過程該模式下的需求管理過程，遵循循序漸進，對導入的需求要求是必須是明確的，準備的，否則在后續(xù)需求的實現(xiàn)環(huán)節(jié)，會出現(xiàn)因需求變更而導致的返工，延誤等情況。為避免出現(xiàn)這種情況，企業(yè)會比較重視需求導入的評審，和需求文檔的完備性，這從另外個角度將，又增加了項目的時間，同時會導致開發(fā)和測試人員無法盡可能早的進行開發(fā)和測試工作。1.1.2敏捷方法的需求管理過程分析敏捷方法的核心是軟件開發(fā)的敏捷，側(cè)重技術(shù)方法和實踐而非管理和計劃，更適合團隊規(guī)模比較小的中小型項目和需求變化快的項目，是一個輕量方法，其需求管理過程，如圖3-2所示。圖3-2敏捷方法的需求管理過程簡單是敏捷的第一個特點，從需求管理過程中就可以看出。敏捷設(shè)置了一個需求池，所有需求導入后首先匯集在需求池中，然后由產(chǎn)品經(jīng)理根據(jù)情況，從需求池篩選優(yōu)先級較高的需求一部分需求出來，形成第一次迭代。第一次迭代從篩選需求、需求理解、需求開發(fā)測試和需求發(fā)布，形成一個閉環(huán)。第一迭代發(fā)布后，再從需求池篩選第二個迭代需要的需求，重復上一個閉環(huán)的步驟。以此實現(xiàn)循環(huán)迭代，增量交付的目的。如果說簡單、持續(xù)迭代、擁抱變化和增量交付是敏捷的優(yōu)點，那它也同時存在一些不足，那就是這種模式針對輕量小型的軟件開發(fā)，效果較好。但是對復雜AI軟件開發(fā)就稍顯不足。AI軟件的一些需求過大，可能無法放入任何一個迭代中進行，例如算法模型，就需要單獨的組建算法團隊來進行模型設(shè)計和訓練。1.2AI軟件項目需求管理的關(guān)鍵因素分析根據(jù)上一節(jié)的過程分析，結(jié)合實際項目，可以分析出影響需求管理的幾個關(guān)鍵因素，分別是合適的需求管理模型，需求分類分層級設(shè)置，人員組織結(jié)構(gòu)和閉環(huán)的需求管理。（1）合適的需求管理模型。在不同企業(yè)，不同的項目采用不同的管理模型，所帶來的需求管理水平和能力是截然不同的。輕量型快速交付的企業(yè)，選擇瀑布模式，則會因為瀑布模式的循序漸進，而導致項目延期交付，無法快速響應客戶需求變更。同理，復雜軟件的項目管理如果選擇敏捷模型，則會出現(xiàn)需求理解膚淺、提交的交付物的穩(wěn)定性較差。所以，合適的軟件項目選用合適的管理模型就比較重要。（2）需求分類分層級設(shè)置。在需求管理中，尤其是復雜AI軟件的需求管理中，需求的形態(tài)各種各樣，有功能性需求，業(yè)務性需求，性能性需求，也有算法性需求。不同的需求，如果放在一個需求文檔或需求池中，必須要根據(jù)需求的屬性和特點，進行分類和分層，做結(jié)構(gòu)化的分析，才有助于需求的理解和實現(xiàn)。（3）人員組織結(jié)構(gòu)。人員組織結(jié)構(gòu)，對需求管理的影響也較為重要。不同崗位的人員對需求的認知也是不一樣的，相同工作內(nèi)容不同經(jīng)驗的人員對需求的理解也同樣存在偏差。采用傳統(tǒng)瀑布模式的項目，如果團隊人員組織架構(gòu)是傳統(tǒng)職能型架構(gòu)，則會阻礙模型中部分流程的有效進行。采用敏捷方式的項目管理，如果人員是矩陣式架構(gòu)，同樣也會造成模型無法有效運轉(zhuǎn)的情況。所以不同模型下對應有不同的人員組織架構(gòu)是保證不同管理模型有效運轉(zhuǎn)的基礎(chǔ)。（4）閉環(huán)的需求管理。閉環(huán)的需求管理在敏捷開發(fā)過程中，得到比較好的體現(xiàn)，因為敏捷單個迭代時間較短，需求最終的實現(xiàn)和初期的需求可以很好的匹配對應。傳統(tǒng)復雜的軟件，因開發(fā)周期較長，需求繁多，經(jīng)常會在需求實現(xiàn)過程中，出現(xiàn)需求掛起或需求丟失的現(xiàn)象。所以，閉環(huán)的需求管理，也是較為重要的關(guān)鍵因素。1.3AI軟件項目需求管理的Pm-Scrum模型構(gòu)建1.1.1Pm-Scrum的整體框架搭建瀑布型的軟件開發(fā)流程如圖3-3所示，由需求分析，合計，實現(xiàn)，測試和運行幾個部分組成。圖3-3瀑布軟件開發(fā)流程目前常用的敏捷模型有極限編程、Scrum、水晶等，這些敏捷方法基本都基于如圖3-4中所示的敏捷開發(fā)模型流程。圖3-4敏捷軟件開發(fā)流程敏捷過程強調(diào)的是迭代增量交付，迭代周期內(nèi)包括需求分析、設(shè)計、編碼與交付，且周期較短，充分反映了敏捷的特性。對于基本的敏捷過程來說，起迭代交付，可以很好的快速響應客戶，但過于強調(diào)快速滿足市場要求，會造成系統(tǒng)的不穩(wěn)定。因為在短時間內(nèi)交付，所以在頂層設(shè)計的時候，沒有過多的考慮系統(tǒng)的可擴展性，從而導致擴展性較差。作者在G公司擔任項目經(jīng)理，在做AI軟件項目時候，經(jīng)常為用傳統(tǒng)瀑布式開發(fā)模式還是敏捷開發(fā)模式而產(chǎn)生疑慮，因為兩種模式都不能單一高效的解決AI類項目的遇到的問題，提升管理水平。AI軟件是面向客戶研發(fā)的平臺類項目，復雜度高、實現(xiàn)難度大、周期長、投入成本較高，通過傳統(tǒng)的項目管理方法PMBOK缺乏靈活性，難以適應需求快速變更、快速迭代交付的要求。又因為軟件復雜度高、難度大周期長，很難對整個項目實施全部敏捷。兩種方式不管敏捷還是傳統(tǒng)的PMBOK都為提高軟件項目成功率、降低風險提供了一些方法和手段，項目中不應該局限于某一種形式進行，而是更應該選擇或改進為更適合當下項目所使用的方法。針對上述兩種流程的不足，結(jié)合前兩節(jié)的過程分析和關(guān)鍵因素，本文做進一步改進結(jié)合，得到Pm-Scrum流程框架，如圖3-5。圖3-5Pm-Scrum流程該流程重點部分在于需求分析階段，通過對需求范圍進行分析劃分為兩大類，一類需求為通用需求，這類需求是屬于基礎(chǔ)性、通用性、平臺性質(zhì)等重量級需求；另外一類是非通用需求，例如定制需求、應用類需求、輕量需求。對上述流程圖進行變形得到下圖3-6，Pm-Scrum的需求管理模型。圖3-6Pm-Scrum的需求管理模型在該模型中，需求池可處于動態(tài)過程，通過需求分析是篩選，提取出來通用需求，進入瀑布開發(fā)模式，其他為非通用需求，進入Scrum迭代開發(fā)模式。具體說明如下：需求池：前期和客戶溝通，盡可能收集更多的需求，形成需求池。通用需求：基礎(chǔ)性、通用性、平臺性質(zhì)等重量級需求，通常在短期內(nèi)無法完成的需求。由項目經(jīng)理及需求分析人員，和客戶溝通后，從需求池中篩選，并通過評審后形成。非通用需求：定制需求、應用類需求、輕量需求，實現(xiàn)簡單，后期變更可能性大。由項目經(jīng)理及需求分析人員，和客戶溝通后，從需求池中篩選，并通過評審后形成。開發(fā)管理：瀑布模式下的開發(fā)管理，嚴格遵守線性開發(fā)節(jié)奏，并嚴格每一環(huán)節(jié)評審，充分思考設(shè)計方案，通過多輪評審，在導入開發(fā)編碼并最終進行測試發(fā)布。同時，處于Scrum下的這部分需求的開發(fā)管理，則通過迭代增量的開發(fā)加快新特征、新功能、新產(chǎn)品的開發(fā)速度來適應業(yè)務復雜性和市場的快速變化。以Sprint為開發(fā)節(jié)奏進行增量交付。每個Sprint的時間是一個月，每個Sprint分成四個迭代，每個迭代的時間一周。開發(fā)團隊每周一上午確定當前迭代的基于用戶故事的需求范圍和開發(fā)任務的安排。經(jīng)過詳細設(shè)計、編碼和測試后完成用戶故事的開發(fā)。開發(fā)人員完成用戶故事后向測試人員和業(yè)務分析人員(產(chǎn)品負責人)演示完成的用戶故事、聽取他們的反饋并做相應的調(diào)整。當每個迭代所有用戶故事完成并完成演示后，周五下午開發(fā)團隊向測試團隊提交可測試的用戶故事列表。如圖3-7所示，基于Sprint的迭代開發(fā)過程。 圖3-7基于Sprint的迭代開發(fā)過程 測試管理：和開發(fā)過程一樣。在瀑布模式下的部分，采用正常的測試流程；Scrum模式下的部分采用迭代增量方式。在需求規(guī)格確定后，測試經(jīng)理根據(jù)需求規(guī)格書來設(shè)計項目中相應的測試所用的方案和用例，并通過上會評審的方式進行審查。在每個迭代中，則是有開發(fā)人員針對需求開發(fā)為對應的用戶故事，測試人員根據(jù)開發(fā)人員的用戶故事編寫測試用例。在迭代的最后一周，進行自動化回歸測試。部署和發(fā)布管理：為了向產(chǎn)品負責人和測試人員能夠及時提交可使用的軟件，引入敏捷的技術(shù)方法如持續(xù)集成、每日構(gòu)建、自動化部署。當開發(fā)人員向源代碼庫中提交新的代碼時，就會觸發(fā)持續(xù)集成工具進行系統(tǒng)的集成和自動化的單元測試、集成測試，當失敗時持續(xù)集成工具就會通過郵件通知相關(guān)的開發(fā)人員，從而保證每次提交代碼之后軟件的可用性和質(zhì)量。1.1.2Pm-Scrum的人員組織形式在公司原有矩陣架構(gòu)下的人員組建成的項目團隊成員，包含多種角色。傳統(tǒng)瀑布式的項目人力架構(gòu)通常是扁平式的架構(gòu)，設(shè)置一名項目經(jīng)理，每個項目成員向項目經(jīng)理匯報。人數(shù)較多的項目，采用樹形人力架構(gòu)，在項目內(nèi)部會劃分功能小組，設(shè)置組長，組員向組長匯報，組長向項目經(jīng)理匯報。這種傳統(tǒng)的人力架構(gòu)通常用來適用于傳統(tǒng)瀑布式的項目管理。Scrum團隊，通常規(guī)模較小，5~7人。猶豫規(guī)模較小，通常對團隊如何組織不做過多的約定，每個Scum團隊有一個ScrumMaster負責推動項目進展或解決爭端，有一個ProductOwner負責對產(chǎn)品的待實現(xiàn)功能進行解釋，并最終確認。這樣簡單的組織結(jié)構(gòu)普遍被認為可以用來實現(xiàn)高靈活性的小軟件開發(fā)項目，但是對于稍大或稍復雜的項目，就難免會有些不太適合。在Pm-Scrum框架下，項目成員中的一部分人員，例如軟件成員需要按不同功能模塊劃分納入不同的Scrum成員，不同功能模塊劃分為不同Scrum小組，在項目內(nèi)部組建成ScrumofScums小團隊，每個Scrum成員人數(shù)不超過5人，根據(jù)所負責模塊，命名為xx小組。未納入Scrum的成員還在項目團隊中按原定的角色和崗位進行。1.1.3Pm-Scrum下的需求管理模型軟件需求是軟件的特征、功能和產(chǎn)品的基本，軟件需求的管理貫穿整個AI軟件項目生命周期?？煽俊⒏咝Ш挽`活的需求管理流程對項目的成功提供保證。AI軟件項目通過結(jié)合項目范圍管理和敏捷方法Scrum相關(guān)知識，使用工具對需求管理流程進行改進，實現(xiàn)需求管理流程的可靠、高效和靈活。在Pm-Scrum需求管理中，引入Scrum中的PO(ProductOwner)一產(chǎn)品負責人的角色，負責需求管理相關(guān)的工作。Pm-Scrum要求任何導入項目的需求必須在前期經(jīng)過項目評審，評審通過后，才能在合同里約定。針對客戶提出的合同外需求，如果不重新擬定附加合同則可能會導致范圍蔓延，導致項目成本增加，進度延長。這部分額外的需求則應該正式和客戶確認后，轉(zhuǎn)達到項目團隊，由項目團隊啟動額外需求的評審，并評估需求工作量和完成時間，以及可以放在哪個版本中進行迭代，形成評審報告由商務經(jīng)理整理成報價方案，提供給客戶，客戶簽署后作為附加合同納入項目需求池進行管理。Pm-Scrum在項目立項后的一個重要工作是把立項時定義的產(chǎn)品規(guī)格細化為需求，形成需求池，并為各個需求排定優(yōu)先級，根據(jù)優(yōu)先級劃分不同的Sprint進行迭代，用來指導后續(xù)工作。在標準Scrum方法中，對需求的分配管理很簡略，只包含Sprint計劃會議一項工作內(nèi)容。Sprint會議全員參加，用來定義在接下來的迭代周期內(nèi)需要包含哪些內(nèi)容，以及要如何完成這些內(nèi)容。但是在AI類項目中，面對復雜的項目，這種簡單的處理方法會對后面的工作造成麻煩。所以，Pm-Scrum對這部分工作也做了一些優(yōu)化。首先，Pm-Scrum要求在立項后所有定義的規(guī)格細化為需求，形成需求池。針對一些標準化、平臺類、基本功能類等較為清晰的規(guī)格，必須映射到需求，這部分需求需要形成詳盡的需求文檔，在迭代發(fā)版前交給外部測試團隊時，必須提交該文檔。針對不清晰或者不確定的部分，允許在下輪迭代過程啟動時進行修正。此類清晰的規(guī)格所形成的需求，可以理解為整個產(chǎn)品的基礎(chǔ)，在開發(fā)前予以重點闡述。整個需求管理流程，如圖3-8所示，包括：需求范圍階段、需求分析和定義篩選階段、需求理解和計劃階段、需求開發(fā)階段、需求測試階段。圖3-8需求管理流程（1）需求范圍階段。不管是在通用需求模式下還是非通用需求模式下，需求范圍階段主要工作都是確定當下版本的主要目標，規(guī)定在迭代結(jié)束時提交給客戶或用戶那些新特征、功能或產(chǎn)品。采用需求跟蹤矩陣來對需求進行統(tǒng)一集中的管理和控制。圖3-9需求范圍階段流程（2）需求分析和篩選階段。需求分析時，PO和客戶進行需求溝通討論，對初始需求范圍進行業(yè)務和商業(yè)價值的評估，根據(jù)其業(yè)務和商業(yè)價值對每項需求設(shè)定唯一的優(yōu)先級。設(shè)定優(yōu)先級后，產(chǎn)品負責人和系統(tǒng)分析人員通過需求分析會議對每個需求項進行業(yè)務和系統(tǒng)的分析，把每個需求項的需求劃分成基于用戶需求故事的更小的需求，并根據(jù)需求故事在需求項中的重要程度設(shè)定第二層的優(yōu)先級，最后形成基于用戶故事的需求文檔。開發(fā)人員和測試人員對每個用戶故事開發(fā)和測試的工作量的進行大概的估計并更新到用戶故事的需求文檔中。所有的用戶故事需求文檔需放入版本控制工具中進行版本控制。同時根據(jù)需求屬性，劃分通用需求和非通用需求。圖3-10需求分析和篩選階段流程（3）需求理解和計劃。為了便于需求計劃，在項目團隊成員對所有用戶故事進行理解的基礎(chǔ)上，所有的用戶故事需要通過篩選，把通用需求部分放入瀑布計劃，非通用需求部分用戶故事將添加到待辦事項(Backlog)中，產(chǎn)品的待辦事項就相當于用戶故事需求池。整個開發(fā)過程中，如果發(fā)現(xiàn)新的用戶故事可以隨時增加進來。每個Sprint開始時舉行Sprint計劃會議，產(chǎn)品負責人和項目經(jīng)理根據(jù)整個團隊人力資源和交付能力的情況，從產(chǎn)品的待辦事項(Backlog)中根據(jù)優(yōu)先級別選取適當?shù)挠脩艄适伦鳛镾print的待辦事項(Backlog)，并制定相應的Sprint開發(fā)初步計劃和任務安排。需求分析和計劃階段是一個迭代持續(xù)的過程。通常情況我們在新版本開發(fā)的前期對該版本做一個初步的整體需求分析和計劃，時間限定在一周以內(nèi)。由于在每個Sprint甚至每個迭代都可能加入新的需求或者需求變更，需求分析和計劃也需要進行相應的調(diào)整，所以不會在前期花費大量的時間和人力對所有的需求進行分析和計劃，這樣保證需求管理的靈活、高效。圖3-11需求理解和計劃階段流程（4）需求開發(fā)階段。在瀑布模式下，通用需求需要進一步的分析和拆解，形成詳盡的需求說明文檔，在文檔的指導下形成詳細的設(shè)計方案，由瀑布小組成員對詳細方案在劃分為分系統(tǒng)方案，并通過會議討論方式，由項目開發(fā)人員完成開發(fā)工作。在Scrum模式下的部分，需求分析和計劃階段制定的Sprint初步計劃在需求開發(fā)階段會進一步的細化，開發(fā)團隊根據(jù)用戶故事需求的優(yōu)先級別細化分為三個迭代，每個迭代時間為一周，原則上用戶故事需求的優(yōu)先級越高迭代開發(fā)的時問越早，目的是為了確保最早交付最有商業(yè)價值和業(yè)務價值的特征、功能和產(chǎn)品。每個迭代周一的站立會議(StandupMeeting)后，產(chǎn)品負責人會向開發(fā)人員和測試人員詳細講解這個迭代計劃要完成的用戶故事需求，并回答開發(fā)人員和測試人員的問題，確保大家對用戶故事需求的理解一致。需求開發(fā)過程中，如果有新的需求項要增加到這個Sprint中，產(chǎn)品負責人和系統(tǒng)分析人員對新的需求項進行需求分析，并把相應的用戶故事放入Sprint的待辦事項(Backlog)中。產(chǎn)品負責人和項目經(jīng)理檢查當前的需求開發(fā)狀態(tài)，把沒有開始開發(fā)的用戶故事和新加入到Sprint的待辦事項(Backlog)中用戶故事根據(jù)優(yōu)先級別從新排列，并根據(jù)團隊的交付能力和人力資源情況，重新調(diào)整Sprint的待辦事項(Backlog)中用戶故事列表，確保團隊在不增加額外資源和不改變交付日期的情況下開發(fā)商業(yè)和業(yè)務價值高的需求。需求開發(fā)過程中，如果Sprint的待辦事項(Backlog)中用戶故事需求發(fā)生變化，這個變化影響到用戶故事對應的需求項的相關(guān)特征、功能或產(chǎn)品整體設(shè)計和最終的交付日期，這類需求變更需要經(jīng)過變更控制流程。反之，只是用戶故事的實現(xiàn)細節(jié)上的變化，產(chǎn)品負責人可以和開發(fā)團隊和測試團隊協(xié)商更改相關(guān)的需求，而不需要經(jīng)過變更控制流程。需求開發(fā)完成后，開發(fā)人員可以邀請產(chǎn)品負責人和測試人員一起對完成的用戶故事需求進行Mini．ShowCase，并聽取他們的反饋。圖3-12需求開發(fā)階段流程（5）需求測試階段。測試人員根據(jù)用戶故事需求設(shè)計這個迭代將要完成用戶故事測試用例。在測試用例評審會議上，如果發(fā)現(xiàn)需求中存在爭論的地方，產(chǎn)品負責人需要澄清和對需求進行補充完善并更新到相應的需求文檔中。測試人員在QA測試環(huán)境根據(jù)測試用例對開發(fā)人員完成的特征、功能或產(chǎn)品進行測試，并在每個Sprint的最后一次迭代在PP環(huán)境對這個Sprint完成的所有需求進行自動化的回歸測試。為了確保開發(fā)人員實現(xiàn)的特征、功能或產(chǎn)品和需求的提出者是一致的，產(chǎn)品Owner、客戶將進行用戶接受測試(UAT)，對測試中發(fā)現(xiàn)的問題及時的反饋，開發(fā)團隊根據(jù)影響的程度、優(yōu)先級別和工作量決定問題的修復時問并做相應的安排。圖3-13需求測試階段流程1.1.4Pm-Scrum下的需求變更管理模型Pm-Scrum對需求變更也是持開發(fā)擁抱態(tài)度，Pm-Scrum認為變更是再算難免的事情，變化總比計劃快。要保持一顆平常心去看待，積極主動的應對，采取合適的管理模型，對需求變更進行有效管理才是重要。根據(jù)對歷史項目總結(jié)，發(fā)現(xiàn)導致項目需求變更，通常有以下幾個原因[34]：（1）不同成員因為經(jīng)驗閱歷和認知不同在需求理解上存在偏差。（2）一開始客戶無法準確的描述需求。（3）隨著項目的推進，客戶的改變了原始需求或者提出了新看法。（4）客戶方基于客觀的原因，如硬件、業(yè)務環(huán)境變化而提出的變更。（5）技術(shù)瓶頸導致的變更。（6）新方法的出現(xiàn)，或者公司管理變革導致的變更。需求的變化會對項目整個過程都造成影響[35]，因此包括客戶等所有干系人在內(nèi)的人員都會受到需求變更的影響[36]。需求變更會帶來很多不穩(wěn)定情況，加大項目管理的難度。變更控制過程并不是為限制或抵制變更，也并不是無用的工作，是通過統(tǒng)一的流程標準對其進行過濾，采用合適的變更，降低需求變更的負面影響和風險。PMBOK變更控制流程如圖3-14，一般要經(jīng)過變更申請、影響評估、變更委員會決策、反饋等，同時變更可能拒絕也可能接受，接受后就執(zhí)行需求變更，在變更完成后進行測試或驗證。圖3-14傳統(tǒng)變更控制流程其具體實施過程中遵循以下原則：1)成立項目的變更控制委員會(CCB)，負責對需求變更進行評估和決定是否執(zhí)行需求變更。CCB由項目相關(guān)的多方組成，應該包括干系人和項目相關(guān)團隊的負責人。2)建立需求基準版本，為需求變更的提供參照。每次變更并通過評審后，需求基準版本做相應的更新3)制定變更控制流程，形成文檔并發(fā)給項目相關(guān)團隊和干系人。4)需求變更申請評審通過后，就要隨即更新相關(guān)信息，包括計劃、成本、活動等。它強調(diào)流程，注重管理和過程，而對效率方面考慮的比較少。歸納起來就是傳統(tǒng)的PMBOK對軟件開發(fā)項目過程提供可靠性，敏捷開發(fā)提供敏捷性。對AI類大型軟件系統(tǒng)項目即需要可靠性又要不缺少靈活性。根據(jù)具體情況和實踐，結(jié)合敏捷和傳統(tǒng)項目變更控制流程，設(shè)計和提出了基于Pm-Scrum的變更控制管理，具體包含以下幾個方面：（1）成立變更控制委員會（CCB）。該委員會通過定期選舉方式進行，通常由項目經(jīng)理、開發(fā)團隊負責人、測試團隊負責人、業(yè)務團隊負責人及項目顧問、技術(shù)專家等組成。CCB主要是針對變更申請，通過分析評審進行把關(guān)決定是否允許變更。（2）根據(jù)需求的劃分，通用性需求和非通用性需求的變更控制流程分別如下：通用性需求的變更，主要涉及系統(tǒng)的底層和平臺層的設(shè)計，這