需求變更是因為需求發(fā)生變化。根據軟件工程思想，需求說明書一般要經過論證，如果在需求說明書經過論證以后，需要在原有需求基礎上追加和補充新的需求或對原有需求進行修改和削減，均屬于需求變更。
需求變更的出現主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。用戶常常以為自己清晰，但實際上他們提出的需求只是依據當前的工作所需，而采用的新設備、新技術通常會改動他們的工作方式;或要研發(fā)的系統(tǒng)對用戶來說也是個未知數，他們以前沒有過相關的使用經驗。隨著研發(fā)工作的不斷進展，系統(tǒng)開始展現功能的雛形，用戶對系統(tǒng)的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，或對以前提出的需求進行改動。他們了解得越多，新的需求也就越多，需求變更因此不可避免地一次又一次出現。
團隊包括一般軟體公司狀況是：
需求：定義模糊，我們一般是以客戶為導向，參差不齊的客戶，所以，很多團隊對需求變化的適應力差。
架構：幾乎一半的團隊沒喲架構師。我原來的公司沒有。現在的公司有，但是，我還沒有感覺到他的價值，感覺更像是需求分析師。
測試：這個就不說了。。。
評審：不知道大家對這個怎么理解，我覺得應該是很重要的，時發(fā)現、糾正問題的一個環(huán)節(jié)。
過程：在CMMI中，雖然只占30%，但是，我覺得很重要，開發(fā)文檔、注解、單元測試、項目進度跟蹤。
客戶：這一塊不熟，因為我一直面對公司內部客戶，所以比較好搞定。
在三者中，
CMMI是標準，他描述，量化了團隊的成熟度，和不足的地方，但是沒有告訴你怎么改進;
SPI是對目標的檢測和過程的優(yōu)化。
AP是過程，包括XP，RUP等等。
我們來看看Xp,應該是很多程序員喜歡的，但是，有多少團隊導入了XP開發(fā)。
XP：開發(fā)周期采用動態(tài)迭代式。
關鍵做法有：1.現場客戶;2.計劃博弈;3.系統(tǒng)隱喻;4.簡化設計;5，集體擁有代碼;6.結對編程;7.測試驅動;8.小型發(fā)布;9.重構;10.持續(xù)集成;11.每周40小時工作制;12.代碼規(guī)范
計劃博弈:
XP要求結合業(yè)務和技術情況，快速確定下一次發(fā)布的范圍。在項目計劃的4要素(費用、時間、質量和范圍)中，由客戶選擇3個，而程序員可以選擇剩下的1個。
通?？蛻魪臉I(yè)務角度確定項目范圍、需求優(yōu)先級和開發(fā)進度，開發(fā)人員則做出具體的成本和技術估計。
XP強調簡短和突發(fā)性的計劃，有時只用幾個小時甚至幾分鐘就能完成，而且可以隨時按需進行多次計劃。
系統(tǒng)隱喻:
XP通過一個簡單的關于整個系統(tǒng)如何運作的隱喻性描述(story)來指導全部開發(fā)。
隱喻可以看作是一種高層次的系統(tǒng)構想，通常包含了一些可以參照和比較的類和模式，它還給出了后續(xù)開發(fā)所使用的命名規(guī)則。
XP不需要事先進行詳細地架構設計。
重構：重構是指在不改變系統(tǒng)行為的前提下，重新調整、優(yōu)化系統(tǒng)的內部結構以減少復雜性、消除冗余、增加靈活性和提高性能。
測試驅動：先寫測試，后編碼
結對編程：
由兩名程序員在同一臺電腦上結成對子共同編寫解決同一問題的代碼。
通常一個人寫代碼，另一個人同時負責保證代碼的正確性和可讀性，比如編寫單元測試程序、進行代碼走查。
PP可以看作是一種非正式的持續(xù)進行的同行評審(peer review)。
哎呀，看到這些，我就有點感慨了，是不是這些東西太理論化了，和實際情況相差太多了。
實際情況，項目來了，馬上開需求會，分任務，然后需求評審，然后系統(tǒng)設計，數據建模，系統(tǒng)框架，