當專案不斷進行時，需要詳細規劃即將實施的迭代活動。在當今日新月異的環境中，提前幾個月甚至幾年做詳細規劃是毫無價值的，但您可以對下幾周（典型的迭代的時間跨度）進行成功地詳細規劃。

項目規劃的普遍且難以置信的有效方法是從粗略的專案規劃開始（請參閱“專案規則技巧”），即從專案開始時開發，然後在完成構成專案的各種迭代時緩慢發展形成。隨著專案不斷進展，需要更新整個粗略的專案規劃，更新它以反映近來努力的實際成果以及您的團隊將繼續從事的下一個（或兩個）迭代的規劃細節。在為單一迭代開發細緻的規劃時，應該執行這些步驟。

實行真實性檢查
透過詢問並且回答一些難題來開始詳細的規劃工作：專案是否仍在按計劃進行？您的方法是否仍有意義？您的團隊是否由合適的人員組成？您是否仍有資金管理者支援？如果其中任何一個問題的答案是否，則需要解決問題，這可能意味著新（且非常短）迭代使您的團隊回到正常軌道上。對處於困境的專案進行大計劃是毫無價值的。

標識詳細的任務
在專案開始時，體系結構和轉移迭代只是列出需要實現的任務列表。然而，要規劃迭代，必須評估已為它指定的需求（請參閱“基於需求的規劃策略”）。隨著專案發展，您將對於對個別需求有更好理解。您可能會發現，現在需要更改給迭代指定的原始需求，這些需求最初是有意義的。或許已經標識並新增了新的需求；或許已經擴充套件或縮減了需求；或許已經更改了優先順序。不管什麼原因，您會發現您需要重新定義打算在該迭代中實現的內容。根據需求，標識需要實現的任務。

標識任務相關性
某些任務取決於其它任務。例如，在部署原始碼之前，必須先編寫它。測試案例的開發可以在編碼之前開始。實際程式碼的測試必須等待，直到已經編寫了某些程式碼（盡管或許不是所有程式碼）為止。問題是某些任務必須在其它任務完成之後才能開始；某些任務必須等待，直到另一個任務開始了為止，它才可以開始；某些任務不能完成，直到另一個任務完成為止；某些任務不能完成，直到另一個任務開始了為止。

均衡資源
需要緊記的重要事情是，每個人一次只可處理那麼多工，並且在工作的那一天只有那麼多時間。這個概念稱為資源均衡，確保任務分派是合理的。指定用 10% 的時間完成 10 項任務很可能無法完成任何任務，而且指定用 50% 的時間完成 5 項任務的人員也不可能完成這些任務。確保現實的規劃的最好方法是，讓執行計劃的人員參與計劃開發。

保持迭代短小
迭代週期應該保持比較短。應該將大於 8 周的迭代分割，以便讓您迅速將軟體交付給使用者。因為正在嘗試彌補在先前迭代中跳過的工作（如文件編制），或者因為您的需求正在增加而沒有新增新的迭代來反映這一事實，所以當專案進展時迭代長度增長是一種趨勢。執行真實性檢查並按照它們的結果行動，將幫助您使迭代週期保持簡短。

考慮並行開發
分幾個子團隊來同時進行系統的不同部分始終是一種有效的辦法，尤其對於系統縱向片段的開發。並行開發可以大大地縮短產品的上市時間，這是當今高度市場競爭性的一個重要因素，儘管它以增加協調工作為代價。共同的體系結構、共享知識視野、共同的開發實踐、定期團隊會議及共享工作場地使並行開發成為可能。[@more@]

規劃迭代--及時開發詳細計劃（轉）

相關文章