項目需求的變化是項目管理中最令人頭疼的事情了，而且如果變更的管理和控制不好的話，往往還會導致項目組內部的開發管理的混亂，降低了軟件開發的效率，增加項目的成本，甚至會導致項目的失敗。
以變更為核心的項目開發管理適合以下類型的項目：
生命周期劃分不是很明顯的;
需求和范圍不清晰，可能會頻繁變化的;
大型的應用項目;
產品化持續開發的項目。
這些項目的特點是都不能按照基本的軟件開發的生命周期模型按部就班地實施開發，即便是按照生命周期模型劃分為各個里程碑或者階段，往往由于客戶方或者外界頻繁的變化，導致項目組疲于應付這些外界的變化，而內部項目組在任務分配、工作檢查或角色分工上會不同程度地陷于混亂狀態。項目管理也往往會比較被動。
當然這種情況一般比較適合項目或者產品研發的中后期，前期的工作一般還都是比較整塊的任務。
那么如何解決這個問題呢?實際上很多模型已經給出了答案，比如RUP、XP等，但是大家在學習和使用這些模型的時候，往往覺得這些模型提出的概念和實施比較難以操作和實施，另外就是不管是RUP還是XP，既然是一個方法模型，就不可避免要描述為一個完整的、系統化的理論模型，否則就體現不出理論的完整和邏輯的嚴謹。下面我們只是把以變更為核心的開發管理流程化，避免在頻繁發生外界變化的情況下便被動為主動。
項目到了后期，這時候客戶參與的也比較多，因此客戶的需求變化也會比較多。另外隨著測試的深入，測試發現的問題都需要項目組來處理和解決。因此我們把項目的某一個版本作為一個基線，后續的任務，不管是新的需求、變更的需求、缺陷修改還是其他的對系統的完善、升級、優化等等，都統一為一個Update，這兒只所以不叫CR(Change request)或者MR(Modify Request)是因為大家習慣把變更請求是作為被動的任務，甚至是當作項目范圍的變化，而很少把變更看做項目任務的管理模式。因此我們把Update就定義為任何對現有系統的修改的工作。
每個變更類似一次小的瀑布的迭代開發，不同的迭代可以并行，關于配置的版本要管理好各個版本的分支。這個是非常重要的，不然版本的問題將會成為項目的定時炸彈。
文章來源于領測軟件測試網 http://www.kjueaiud.com/