，就會導致必須對代碼的其他部分作出必要變更的漣漪效應。同樣，漣漪效應超出了代碼范圍，擴大到了項目團隊的其他領域。比如，如果沒有將變更有效地通知測試人員，那么他們可能就不能構(gòu)建出必要的驗證腳本來測試變更，從而帶來了影響軟件質(zhì)量的風險。此外，即使變更只需要開發(fā)人員的一點點努力就能實現(xiàn)，但是對 QA/QE 或文檔的影響可能延誤整個項目進度。由于漣漪效應的存在，整個項目團隊為出現(xiàn)的變更召開會議就很有必要。
由于這些依賴關(guān)系，開發(fā)人員將接受變更的權(quán)利委派給項目團隊中對項目交付有著高度和完整預見性的人就變得很重要。為了降低破壞項目穩(wěn)定性的風險，您只希望接受被項目團隊批準的變更，這樣您就知道您正在實現(xiàn)的是一個商定的功能，并且每個人都有義務測試和記錄該功能。
解決辦法：通過評估變更的影響控制需求變更
良好的 RM 實踐可以避免未經(jīng)評估就隨意做出變更。他們將變更請求視為"頭等公民"，以保證所有潛在的變更都經(jīng)過檢查，并且接受變更的影響能在影響開發(fā)人員的工作之前得到評估。
需求規(guī)格說明書應該經(jīng)過由客戶、開發(fā)團隊和測試團隊三方代表組成的小組批準之后才能進行變更。這個小組通常被稱為 CCB。該組的職責是從客戶的角度、開發(fā)的角度、測試和文檔化的角度評估每一個被請求的變更。根據(jù)應用程序類型的不同，培訓和支持人員可能也需要參與進來。
為什么需要所有這些人參與呢？因為每個代表都在分析實施給定變更請求的潛在影響或成本時具有不同的視角：
開發(fā)代表負責評估變更請求影響的所有軟件設計區(qū)域，以及實施變更所需的后續(xù)努力。通常需要個別開發(fā)人員作為這樣的代表參與分析變更請求的影響。
QA 代表必需評估與接受提議變更相關(guān)的測試工作的可行性和程度。我們應該時刻記住變更可能很容易加入到代碼中，但是很難（有時候甚至不可能）測試。
客戶代表提供了業(yè)務視角，并保證變更不會使項目偏離最初的業(yè)務目標，以及提供有關(guān)變更的任何信息來幫助 CCB 理解客戶需要。
最后，為了安全起見，包含來自 CCB 的培訓、支持和文檔化代表也是我們推薦的，因為變更請求通常也對這些領域有影響。
為了保證評估過程的有效性，CCB 的每個成員應該負責查找一個適當?shù)奶娲?，以防萬一，從而保證對變更請求的評估絕沒有偏見。對于所有方面都沒有代表的罕見情況，應該將變更請求推遲到以后再評估。
好的 RM 實踐應該防止開發(fā)人員匆忙地對事情做出變更。需求的變更方面，從您編寫它們開始直到交付軟件，都是項目中最難應付的事情。Standish Group 在它 2001 Extreme Chaos 報告中指出："變更需求就像死亡和稅收一樣確定無疑"。掌握管理變更需求的技巧對于項目的成功很重要，并且它還是一種直接影響開發(fā)人員生活的實踐。
迭代開發(fā)取代傳統(tǒng)的瀑布型方法對管理需求變更是一種很大的幫助。在傳統(tǒng)方法中，需求規(guī)格說明書在項目一開始就被凍結(jié)了，并且直到軟件發(fā)布之后變更還不能加入進入。讓變更進入版本中的唯一方法就是直接找開發(fā)人員，請求他們變更代碼。這也正是我們前面看到的由于不能評估變更對項目真正的總體影響而導致項目不穩(wěn)定的方法。迭代開發(fā)允許軟件團隊將工作分割成小的部分，其中需求是穩(wěn)定的并且在迭代過程中保持不變。在下一次迭代開始時，團隊就有機會更新需求規(guī)格說明書，以加入上一次迭代中提交和接受的變更。在迭代開發(fā)中，規(guī)格說明書只在迭代開始時發(fā)生變更，而不能在迭代過程中進行變更。這使得我們可以在迭代期間把注意力集中在一組需求上。當下一次迭代來臨時，您就會被分配一組缺陷和新的或更新過的需求。
問題2：處在影響您工作的變更的盲區(qū)
當需求發(fā)生變更時，如何通知您？您的經(jīng)理被