前面我們提到了需求變更。當客戶提出了需求變更，經過與我們的需求人員的詳細討論與分析，最後確定下來了變更內容和修改方案。但這時草率地開始進行設計和開發是不正確的，它將成為專案後期的乙個巨大的風險，一顆定時zhadan，為什麼呢？我們來詳細分析分析。
每當發生需求變更的時候，不管是大是小，專案的許多因素都會相應地發生變化。首先發生變化的是工作量。每次的變更必然造成工作量的增加，到底增加了多少呢？我們需要對其進行評估。同時，我們還要對增加的工作進行優先順序評估。一般來說，新增加的工作往往優先順序都是最高的，是客戶急切想看到結果的部分，那麼其它的工作的優先順序就會收到影響，優先順序就會有所下降。當工作量的增加與優先順序的調整完成後，隨後的工作就是專案計畫的調整。
前面我們說過，迭代式開發的專案計畫與傳統的專案計畫是存在巨大差異的。迭代式開發的專案計畫其核心，就是如何將各項任務合理分配到各個迭代期中去。任務就像乙個個大小不一的石子，迭代期就如同乙個個網格，專案計畫就是將石子分發到各個網格中，雖然有一些空隙，但大體是滿的。現在新任務來了，就如同要將新的石子放到已滿的網格中，有幾種可能：石子很小，利用網格的空隙就可以填滿了；石子太大了，如果要把這個石子放進這個網格中，就必須將裡面的某個石子取出來，放到別的網格裡。現在專案計畫的變更就是這樣。
如果新的工作量很小，往下乙個迭代期擠一擠，即使超了1、2天也能擠下，那就擠擠吧，但這個迭代期可能會延期，後面工作的時間節點也必然隨之調整；如果新的工作量還不小，優先順序還比較高，那麼只能將下乙個迭代期中已有的任務取出，調整到其它迭代期中，這可能會導致後面整個的工作計畫都將調整。不論怎樣調整，我們都應當將調整後的工作計畫告知客戶。
[b]不論業務需求怎樣變更，不論專案計畫怎樣調整，通知客戶，讓客戶理解，並與我們共同承擔專案延期的風險[/b]，這是從無數失敗的專案中總結出來的血的教訓。一定要讓客戶明白，你們可以改需求，可以提出修改意見，但必須與我們一同承擔風險。當客戶意識到這一點時，也許他們就會慎重考慮了，甚至一下變更需求就會被取消。
在變更專案計畫的同時，另一項重要的工作就是變更我們的產品需求說明書。在專案管理中，需求文件往往分為兩個：原始需求和產品需求說明書。原始需求是客戶編寫的，站在客戶角度描述的業務需求，而產品需求說明書是我們在對原始需求分析、理解、調研以後，剔除那些技術無法實現的內容，最後形成的文件，是我們的軟體最終做成什麼樣的依據性文件（需求文件其實很多，如需求規格說明書、產品規格說明書等等，但都大同小異）。產品需求說明書是程式開發的依據，軟體測試的依據，使用者驗收的依據，貫穿整個軟體開發的核心。因此，當業務需求發生變更之後，產品需求說明書一定要進行相應的變更，並做好變更的記錄，與客戶簽字確認。這樣做的另乙個好處就是防止客戶隨意變更需求，使客戶對變更的提出更加慎重。
另外乙個需求變更中常常出現的尷尬局面就是，當所有情況都清楚告訴客戶以後，客戶提出需求必須要變更，但最終交付時間卻不能改變。這著實是乙個相當矛盾的問題，變更必然造成工作量增加，工作量增加必然影響最終交付時間，但交付時間又不能變，這聽起來既不合情又不合理，但在現實的專案中經常發生，而且各有個的充分理由，我們這怎麼辦呢？其實解決這種情況的辦法就是在制訂專案計畫之初就提前考慮到。記得我們前面提到，我們在制訂專案計畫時應當在時間上留有一定的富餘。如何制訂專案計畫，《越獄》這部電影給了我們很多的啟示。如何成功越獄，主人公在越獄過程中的每個風險點都制訂了風險規避和補救的辦法，專案計畫也是這樣。專案需求變更就是乙個風險點，因此專案經理應當在制訂計畫之初就應當做好準備，並提前預留出相應的時間，當專案進行過程中風險出現時才能從容應對。
總之，需求變更不是什麼洪水猛獸，也不是乙個專案可以完全規避得了的。我們提前準備好，從容應對之，就不是什麼大不了的事情。
[url=一次迭代式開發的研究：軟體開發的風險[/url]
[url=一次迭代式開發的研究：什麼是迭代式開發[/url]
[url=一次迭代式開發的研究：怎樣進行迭代式開發[/url]
[url=一次迭代式開發的研究：迭代開發從這裡開始[/url]
[url=一次迭代式開發的研究：準確的工作量評估[/url]
[url=一次迭代式開發的研究：功能的優先順序評估[/url]
[url=一次迭代式開發的研究：乙個迭代式專案計畫[/url]
[url=一次迭代式開發的研究：開始真正的工作[/url]
[url=一次迭代式開發的研究：從容應對需求變更[/url]
[url=一次迭代式開發的研究：需求變更的關鍵步驟[/url]
[url=一次迭代式開發的研究：where you are[/url]
[b]（續）[/b]
一次迭代式開發的研究10 需求變更的關鍵步驟
前面我們提到了需求變更。當客戶提出了需求變更，經過與我們的需求人員的詳細討論與分析，最後確定下來了變更內容和修改方案。但這時草率地開始進行設計和開發是不正確的，它將成為專案後期的乙個巨大的風險，一顆定時zhadan，為什麼呢？我們來詳細分析分析。每當發生需求變更的時候，不管是大是小，專案的許多因素都...
一次迭代式開發的研究 Where you are
其實做乙個專案經理真不是乙個好的職業，它需要太多的千錘百鍊才能修煉出來。這不僅需要反覆經歷 失敗 總結 再失敗 的輪迴，而且需要有一顆無比堅強的心，能夠在無數次經歷無比艱難並且令人沮喪的時刻而能堅持不懈 毫不氣餒。乙個專案經理就像一位將軍。將軍百戰死，而專案經理呢，經歷無數專案以後沉澱下來的，更多的...
一次迭代式開發的研究 怎樣進行迭代式開發
前面我們提到了迭代式開發的巨大優勢，它可以降低我們軟體開發的巨大風險，它可以使我們把握使用者的真正需求，它可以使我們從錯誤與偏差中及時糾正過來，那麼我們應該如何進行迭代式開發呢？要回答這個問題，我們首先要弄清迭代式開發與傳統的瀑布式開發的差別在 b 1.需求分析的差別 b 與傳統的軟體開發一樣，迭代...