我們經過以上一系列的分析，工作量評估與優先順序評估，制訂出乙個迭代式的專案計畫，再經過一系統使用者確認與公司評審以後，終於可以開始我們真正的開發工作。
其實，迭代式開發的執行過程，也就是製作和不斷去關注與評估專案進度表的過程。因此，當專案進入執行開發過程時，專案經理應當首先製作專案進度表。現在我們看看專案進度表長得啥樣兒。
在乙個專案進度表中，首先被縱向劃分為三個區域：未開始任務區、正在進行任務區和已完成任務區，當然還可以增加其它區域，如下階段完成任務區，以及工作進度、費用成本的統計圖等。
同時，專案進度表又被橫向地劃分為數個區域，每個區域就是乙個迭代期。在專案初始的狀態下，所有的功能以及從中分解出來的工作，按照專案計畫被分配到了對應的迭代期、未開始任務的區域。
另外，另乙個統計表對整個開發進度的監控比較重要，它被稱作burn-down table（暫時翻譯為剩餘工作量統計表吧）。這個統計表的橫軸是專案進行的時間，縱軸是剩餘的工作量。專案開始時，橫軸應當是0，而縱軸，按照專案計畫，應當是該項目的總工作量。每完成一項工作，就減去該項工作的工作量，直到所有工作完成，縱軸為0。如果專案是正常而平穩地進行的，整個統計表就應當是乙個平滑下降的直線，直到最後在計畫交付時間（deadline）結束，這跟直線被稱作基準線，但它是理想的、實際情況往往不會是這樣的。在整個專案的每天都記錄下當天的剩餘工作量，那麼這個表就呈現出一副實際工作進度曲線圖。當專案因各方面原因被延後時，該曲線就會高於基準線；當專案因進展順利而超前時，該曲線就會低於基準線。所以burn-down table可以為專案經理及其成員隨時掌握專案進度，及時調整專案偏差，提供方便。
當專案進入第乙個迭代期時，專案經理將第乙個迭代期的功能及其任務描述清楚，填入到正在進行任務區，同時不要忘記填寫各項任務的負責人。眾所周知，迭代開發的每個迭代期分為需求分析、設計、開發、測試幾個部分，但在這個表中監控的內容可詳可簡。如果希望更精細化管理，可以將每個任務再分解為需求分析、設計、開發、測試幾個部分分別進行監控；如果專案不是非常複雜則不用劃分如此精細，可以劃分為開發與測試，或者不劃分開。每天早上，專案成員召開乙個簡短的例會，或者通過其它方式，向專案經理匯報各項任務的工作進度。專案經理收集各項任務的工作進度，在這張表中詳細記錄下來。如果一項任務全部完成，則將其放置到已完成任務區域，再將其它剛剛開始的任務放置到正在進行任務區。最後，專案經理計算專案剩餘工作量，並將其填寫到burn-down table中。
記得極限程式設計（xp）的其中一項重要的思想就是及時發現專案進行過程中的進度偏差，並及時進行糾正，而burn-down table的使用正是體現了這種思想。通過整理和繪製burn-down table，為專案經理及其成員提供了乙個清晰的視覺化圖表，表明專案當前的進度是超前還是延後。如果是超前，專案組可以進行更多的檢查與測試，進一步保證專案質量；如果是延後，則不得不通過趕工、加班等方式，加快進度。
一次迭代式開發的研究 怎樣進行迭代式開發
前面我們提到了迭代式開發的巨大優勢，它可以降低我們軟體開發的巨大風險，它可以使我們把握使用者的真正需求，它可以使我們從錯誤與偏差中及時糾正過來，那麼我們應該如何進行迭代式開發呢？要回答這個問題，我們首先要弄清迭代式開發與傳統的瀑布式開發的差別在 b 1.需求分析的差別 b 與傳統的軟體開發一樣，迭代...
一次迭代式開發的研究 Where you are
其實做乙個專案經理真不是乙個好的職業，它需要太多的千錘百鍊才能修煉出來。這不僅需要反覆經歷 失敗 總結 再失敗 的輪迴，而且需要有一顆無比堅強的心，能夠在無數次經歷無比艱難並且令人沮喪的時刻而能堅持不懈 毫不氣餒。乙個專案經理就像一位將軍。將軍百戰死，而專案經理呢，經歷無數專案以後沉澱下來的，更多的...
一次迭代式開發的研究10 需求變更的關鍵步驟
前面我們提到了需求變更。當客戶提出了需求變更，經過與我們的需求人員的詳細討論與分析，最後確定下來了變更內容和修改方案。但這時草率地開始進行設計和開發是不正確的，它將成為專案後期的乙個巨大的風險，一顆定時zhadan，為什麼呢？我們來詳細分析分析。每當發生需求變更的時候，不管是大是小，專案的許多因素都...