當(dāng)項目不斷進(jìn)行時，需要詳細(xì)規(guī)劃即將實施的迭代活動。在當(dāng)今日新月異的環(huán)境中，提前幾個月甚至幾年做詳細(xì)規(guī)劃是毫無價值的，但您可以對下幾周（典型的迭代的時間跨度）進(jìn)行成功地詳細(xì)規(guī)劃。

項 目規(guī)劃的普遍且難以置信的有效方法是從粗略的項目規(guī)劃開始（請參閱“項目規(guī)則技巧”），即從項目開始時開發(fā)，然后在完成構(gòu)成項目的各種迭代時緩慢發(fā)展形 成。隨著項目不斷進(jìn)展，需要更新整個粗略的項目規(guī)劃，更新它以反映近來努力的實際成果以及您的團隊將繼續(xù)從事的下一個（或兩個）迭代的規(guī)劃細(xì)節(jié)。在為單一 迭代開發(fā)細(xì)致的規(guī)劃時，應(yīng)該執(zhí)行這些步驟。

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

標(biāo)識詳細(xì)的任務(wù)
在 項目開始時，體系結(jié)構(gòu)和轉(zhuǎn)移迭代只是列出需要實現(xiàn)的任務(wù)列表。然而，要規(guī)劃迭代，必須評估已為它指定的需求（請參閱“基于需求的規(guī)劃策略”）。隨著項目發(fā) 展，您將對于對個別需求有更好理解。您可能會發(fā)現(xiàn)，現(xiàn)在需要更改給迭代指定的原始需求，這些需求最初是有意義的?；蛟S已經(jīng)標(biāo)識并添加了新的需求；或許已經(jīng) 擴展或縮減了需求；或許已經(jīng)更改了優(yōu)先級。不管什么原因，您會發(fā)現(xiàn)您需要重新定義打算在該迭代中實現(xiàn)的內(nèi)容。根據(jù)需求，標(biāo)識需要實現(xiàn)的任務(wù)。

標(biāo)識任務(wù)相關(guān)性
某 些任務(wù)取決于其它任務(wù)。例如，在部署源代碼之前，必須先編寫它。測試案例的開發(fā)可以在編碼之前開始。實際代碼的測試必須等待，直到已經(jīng)編寫了某些代碼（盡 管或許不是所有代碼）為止。問題是某些任務(wù)必須在其它任務(wù)完成之后才能開始；某些任務(wù)必須等待，直到另一個任務(wù)開始了為止，它才可以開始；某些任務(wù)不能完 成，直到另一個任務(wù)完成為止；某些任務(wù)不能完成，直到另一個任務(wù)開始了為止。

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

保持迭代短小
迭 代周期應(yīng)該保持比較短。應(yīng)該將大于 8 周的迭代分割，以便讓您迅速將軟件交付給用戶。因為正在嘗試彌補在先前迭代中跳過的工作（如文檔編制），或者因為您的需求正在增加而沒有添加新的迭代來反 映這一事實，所以當(dāng)項目進(jìn)展時迭代長度增長是一種趨勢。執(zhí)行真實性檢查并按照它們的結(jié)果行動，將幫助您使迭代周期保持簡短。

考慮并行開發(fā)
分 幾個子團隊來同時進(jìn)行系統(tǒng)的不同部分始終是一種有效的辦法，尤其對于系統(tǒng)縱向片段的開發(fā)。并行開發(fā)可以大大地縮短產(chǎn)品的上市時間，這是當(dāng)今高度市場競爭性 的一個重要因素，盡管它以增加協(xié)調(diào)工作為代價。共同的體系結(jié)構(gòu)、共享知識視野、共同的開發(fā)實踐、定期團隊會議及共享工作場地使并行開發(fā)成為可能。

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html