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