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