同一領域的類似項目，這樣才有較強的可比性。由于這些計劃安排是預估粗略的，所以還必須在以后的項目各階段完成后進行合理的變更，反應項目的實際需求。微軟的辦法是把進度估計的權限交給開發(fā)人員，由開發(fā)人員根據(jù)自己的經(jīng)驗進行估計，由于一般開發(fā)人員往往會高估自己的能力，估計的進度也會相應偏短，最后再做適當?shù)难娱L[2]。這種辦法有它合理的地方，在中國還需進行實踐摸索。
對于進度的估計，我們有個經(jīng)驗公式，即您最初預估的時間再乘以2.5，可能是最后的完成時間。因為許多人在估計進度的時候，往往忽略了很多非開發(fā)時間，如與客戶溝通的時間、項目組溝通時間、公司培訓時間、假期等，所以我們在估計進度的時候，一定要全方位周全考慮，在盡可能的情況下寧愿把進度估計的長一點，免得在項目后期導致非常被動的局面。后面我們將具體講到我們采取的階段性的開發(fā)方法，這種方法的運用反映在進度估計時必須在各階段間預留緩沖時間，以解決那些我們事先沒有預料到的活動。如果進度表和要求的出貨時間有沖突，寧愿砍掉一些不重要的功能，也不要盲目增加人手，這種做法可能會導致產(chǎn)品質量下降，最終得不償失，詳細說明請參考[4]。
風險管理是項目管理中非常重要的部分，并且要貫穿項目的始終。一些軟件企業(yè)往往不是很重視風險管理，導致在項目的后期出現(xiàn)了很多預料之外的事情，使項目進度一拖再拖，往往質量也達不到預期要求。因此我們要特別重視風險的管理，具體方法留待后面專門詳述。
3.2.4開發(fā)過程
在項目的開發(fā)過程中，我們采用了階段式的開發(fā)過程，這也是微軟公司所推薦的開發(fā)過程。在開發(fā)過程的初期，首要的活動是概要設計。概要設計的目標是簡單、適用、能夠覆蓋所有的需求并能支持后面的階段式開發(fā)。微軟的應用方案解決模型是基于服務的三層(多層)架構，包括用戶層，業(yè)務層和數(shù)據(jù)層，各層之間采用標準的接口進行通訊，至于該方法的具體使用，請參看相關書籍，在此就不在贅述了。
階段開發(fā)過程不是傳統(tǒng)的根據(jù)模塊劃分來依次完成各模塊，最后再進行項目的整合，而是在每個階段完成后，項目都可以推出產(chǎn)品，只不過該產(chǎn)品的功能比最終產(chǎn)品的功能弱一些。
階段性完成項目比傳統(tǒng)的開發(fā)方法最明顯的優(yōu)點是不必到項目的末期才開始整合產(chǎn)品，使產(chǎn)品模塊之間協(xié)作產(chǎn)生的問題及早產(chǎn)生，也及早修正，從而項目的風險也大大減小。傳統(tǒng)的開發(fā)總是在項目的后期才開始整合各模塊，使產(chǎn)生的問題改正起來極為困難，成本也大大增加;前面累計的所有問題全部都拖到了后面來解決，也使后面剩下的工作量大大增加。項目往往看起來已完成了90%——大部分的功能模塊都已完成，但剩下的10%總是完不成，項目進度一拖再拖，很可能還要再花90%的時間來完成剩下的10%。當然采用階段性開發(fā)方法也有相應的代價，最大的代價可能是反復的整合、測試已經(jīng)完成的模塊，但采用相應的一些自動化工具可以減小這個代價。
一般在開始的階段進行的是系統(tǒng)架構和最重要的功能，后面的階段是相對不怎么重要的功能。這樣的分配有利于最終用戶在早期就能看到系統(tǒng)的大致模樣，便于他們及早的對產(chǎn)品提出意見，并對相應的錯誤進行修改;也有利于項目組在項目后期時間很緊的情況下，去掉一些不重要的功能，把它們納入下一個版本處理，確保產(chǎn)品的推出時間。迭代的順利進行依賴于良好的架構設計，前面階段的設計應該給后面要加入的功能預留出各種接口，并能使后面的工作在前面的基礎上繼續(xù)進行下去。
這種在開發(fā)階段的迭代方式不同于整個項目的完全迭代開發(fā)，后者是項目的需求、概要設計、開發(fā)等全部是迭代進行，一次迭代要進行所有的項目活動。至于誰優(yōu)誰劣可能在不