項目進度計劃時的系統(tǒng)觀

1、培養(yǎng)做項目進度計劃時的系統(tǒng)觀客戶最關(guān)注什么 產(chǎn)品質(zhì)量往往是基本，這是一個默認屬性。但是做到哪個度仍然可以談，所以首先要清楚用戶對質(zhì)量要求的優(yōu)先級，一般來言可能是可用-易用-性能-安全。這一般叫測試類型，另外就是測試的等級表明測試要達到何種覆蓋率或程度。這些都影響到項目周期。 除了默認質(zhì)量要求，項目周期往往是客戶最為關(guān)注的。這個往往并不是經(jīng)過詳細的估算，排完進度了再確定下來的，而是項目一開始往往就由客戶敲定，而項目范圍往往也是在合同就會明確下來。所以跟用戶敲項目周期就顯得很重要了，根據(jù)軟件工程和經(jīng)濟學得出結(jié)論是：對于一個軟件項目我們可以考慮投入更多資源來縮短項目周期，但當項目周期縮短到一定度以后

2、，投入再多的資源也沒有用。因此項目經(jīng)理談判的底線為在不考慮人力資源情況下項目能夠達到的最短周期，如果這個最短周期還達不到客戶要求，必須縮減項目范圍而不是犧牲產(chǎn)品質(zhì)量。 項目計劃重點就是通過調(diào)整各個要素，保證項目能夠有8,9成以上的勝算，對于影響到項目成功的全部列入風險和關(guān)鍵問題進行跟蹤。項目經(jīng)理在計劃完成后一大半的時間都應該花費在消除不確定性上。項目失敗往往并不是進展過程出現(xiàn)太多異常，而是一開始項目經(jīng)理就不清楚自己有幾層把握，一開始也沒有分析清楚有哪些不確定性和關(guān)鍵要素。 項目周期敲定了再排進度 如果簡單的認為項目周期確定了再排進度就只能是倒排進度，那說明還沒有真正理解各要素的平衡和進度安排的

3、實際含義。項目經(jīng)理往往根據(jù)項目周期倒排不切實際的進度計劃，那導致項目進度延期就是必然的事情了。 制定進度前最重要的仍然是根據(jù)人力資源情況和項目周期來綜合考慮生命周期模型的選擇，是瀑布還是增量迭代，這個直接影響到WBS的分解。而WBS中我們又最關(guān)心工作包或任務的粒度問題，這個需要和可用的人力資源配合起來，一個功能模塊分解細后可以更多的人力資源參與進來，使更多的任務能夠并行，但無疑會增加前面接口設計和后期集成的工作量。當接口設計和集成工作所花費時間大于開發(fā)任務并行所縮短的時間時候，這個時候就到了分解的最小粒度。在這個粗細粒度間就是可以通過調(diào)配人力資源能夠獲取的最大進度壓縮。 在IT項目中由于崗位角

4、色劃分，往往并不適合采用關(guān)鍵路徑的方法來預計進度。進度安排關(guān)鍵在讓所有人都盡可能早的動起來，在這里可以考慮的思考方式是: 1.關(guān)注項目關(guān)鍵資源，關(guān)鍵資源必須優(yōu)先安排來執(zhí)行關(guān)鍵任務 2.通過組件細分和迭代，增加后期集成時間，但縮短前期關(guān)鍵路徑等待時間 3.通過每日構(gòu)造將測試也迭代起來 4.進度緊往往更不該跳過需求和總體設計評審而直接編碼，后期返工往往是災難性的 最有效的方法論和過程 在裁剪過程的時候，必須清楚的認識到哪些過程元素是保證項目成功的核心要素，哪些是可以省略的。XP方法論對于任何一個功能的開發(fā)仍然是遵循小瀑布，而不是跳過程。一個設計思路可以在紙面設計草圖后就可以開始編碼，后期再形成規(guī)范

5、的文檔，但決定不是說不經(jīng)過設計就開始編碼。需求，DEMO原型，總體架構(gòu)，數(shù)據(jù)庫設計，評審，項目開發(fā)模式和規(guī)范都是重要的元素，都應該最有效的去發(fā)揮作用。因此以下是可以考慮的關(guān)鍵點 1.DEMO原型必須和用戶溝通確認，但需求階段技術(shù)架構(gòu)工作可以并行 2.需求和架構(gòu)，數(shù)據(jù)庫必須經(jīng)過評審 3.架構(gòu)或總體設計完成后必須進行培訓，強調(diào)后續(xù)的開發(fā)模式和規(guī)范 4.架構(gòu)開發(fā)不一定要全部完成才能開始后續(xù)工作，但事先要定義清楚接口 4.詳設可以出紙面草圖，面對面溝通后即可開始編碼，后期再補規(guī)范文檔 5.對于100%要做的不涉及業(yè)務規(guī)則功能可提前編碼，如一些基礎表的維護項目計劃技巧對于現(xiàn)今的軟件開發(fā)人員來說是必需的。

6、這里有一些幫助您有效地計劃下一個項目的建議。認識到信心來自規(guī)劃的過程，而不是計劃本身。創(chuàng)建項目計劃會迫使您早在編寫代碼之前就考慮如何構(gòu)建您的系統(tǒng)?減少項目的風險，因為您已經(jīng)考慮了各種策略和方法并且已經(jīng)選擇了最有意義的一項。您的目的不應該只是不花氣力產(chǎn)生一個計劃；它應該是一個實際可行的計劃，您可以根據(jù)它來成功管理您的項目。軟件過程推動計劃的開發(fā)每個軟件過程都有一個不同的集合，它包括組織團隊的活動方法以及規(guī)劃項目常用的技術(shù)。由于這個原因，基于RationalUnifiedProcess(RUP)的項目規(guī)劃不同于OOSP項目的規(guī)劃，而OOSP項目的規(guī)劃也不同于eXtremeProgramming(X

7、P)項目的規(guī)劃。不同的過程有不同的計劃。從粗粒度的計劃開始在項目將要開始時，應該制定一個粗粒度的、確定項目高級活動和預期里程碑的計劃。粗粒度的計劃將組織成迭代?根據(jù)項目的大小和性質(zhì)，每次迭代通常在三周到八周之間發(fā)生（四周到六周為更佳）。其中一些迭代將集中在項目初期，而很多迭代將集中在整個應用的功能部分開發(fā)，還有一些迭代集中在將您的系統(tǒng)轉(zhuǎn)變成產(chǎn)品。實施者應該是計劃人員創(chuàng)建項目計劃的最佳人員是負責實施該計劃的人員。當規(guī)劃由一個人創(chuàng)建而由另一個人實施時，如果項目不能按時完成或超出預算，他們不太會相信計劃，而很有可能會責備它。也就是說，參與項目的每個人都應該投入到項目計劃的開發(fā)和進展中。不要忘記“不該

8、忘記的事”計劃不僅要反映需求設計、建模、編程和測試的“真實”工作，而且還應該反映輔助活動（然而仍是重要的），它包括：休假和法定假日、培訓和教育、項目管理活動（如規(guī)劃和人員管理）、開銷（如系統(tǒng)當機時間、會議和回復電子郵件）、體系結(jié)構(gòu)定義、測試之后的系統(tǒng)返工、系統(tǒng)交付、與重用相關(guān)的活動（如普遍化）。將任何設想和約束編入文檔規(guī)劃時您總要作一些假設，如能夠及時獲得應用程序服務器的新發(fā)行版，或可以得到熟悉您正在應用的技術(shù)和技巧的開發(fā)人員。同時，您將在一些約束下工作，如影響計劃的強制截止期限或資源限制。將這些假設和約束編入文檔，這樣，當您實施項目的任何時候更新計劃時，都可以記起您先前做出的一些“不尋?！睕Q

9、定。認識到不同的資源意味著不同的計劃十名有經(jīng)驗的開發(fā)人員組成的團隊創(chuàng)造出的成效要遠遠多于十名初學者組成的團隊所創(chuàng)造的成效。要想更加實際的話，您的計劃必須反映項目可使用的資源的真實情況。創(chuàng)建現(xiàn)實的計劃項目組必須相信其項目的目的、估價和時間表。要做到這點，您必須真實地規(guī)劃，避免規(guī)劃超出您能理解的范圍。僅當您打算研究未知事項時，才能容忍無知。只規(guī)劃有價值的事IBMDeveloperWorks網(wǎng)站提供了許多可應用于您項目的最佳實踐。然而，根據(jù)項目的性質(zhì)，不是所有這些技術(shù)都將適合于您的獨特情況。要將這些最佳實踐簡單地看作是您放置在“項目管理工具箱”中的工具，您可以根據(jù)需要適當使用這些工具。適當使用項目管理工具一些項目管理工具，如MicrosoftProject，提供了重要功能如Gantt圖表（活動時間表）的開發(fā)、規(guī)劃與實際結(jié)果的比較、PERT圖表（網(wǎng)絡圖表）的開發(fā)、任務的定義、任務之間相關(guān)性的定義、對任務的資源分配和資源平衡。所有這些事情似乎象是一個好主意