為什麼要把這個甘特圖拿出來呢？因為這個甘特圖是基於可以添加資源，來迎合項目交付日期的假設的。現在思考一個問題，如果資源不能增加，又不能更改項目交付日期，該怎麼辦呢？

這就需要我們從項目的開發模式上入手思考了。

項目的開發模式，一般分為三種，瀑布式，迭代式和現在如火如荼的敏捷開發。

瀑布式：是最典型的預見性的方法，嚴格遵循預先計劃的需求分析，設計，編碼，集成，測試，維護的步驟，並按照順序進行。每一步驟結束之後才能開始下一步驟。而前一步的成果物會作為後一步驟的輸入物。如我們的例子中就是使用的瀑布模型。

優點： 對於每一階段的產出有嚴格的要求。對於項目質量的追蹤非常密切。

缺點： 不夠靈活，嚴格的分階段導致自由度降低。對於項目後期需求的變化難以調整，或者說調整的代價過於高昂。

對於一個項目來說，越早期的調整對於項目的影響越少。而瀑布式的開發模式，客戶在最後階段交付的時候才能看到成果物。一旦成果物有偏差，調整起來的代價勢必相當巨大。也鑒於此，使用瀑布模式開發，對於早期需求的提煉，分析和把控相當的重要。而需求不明或者項目需求經常變化的情況是不建議使用瀑布模型的。

迭代式：是一種與瀑布式開發相反的開發過程，他彌補了傳統開發方式中的一些弱點，具有更高的成功率。

所謂的迭代開發，就是每次只設計和實現一個產品的一部分，逐步完成整個產品。說白了，就像畫畫一樣，先畫輪廓，然後得到客戶反饋後在畫細節。每一次迭代都會經歷瀑布模型的需求分析，設計，編碼，集成，測試，維護的步驟。即我先做到從沒有到有，然後再精益求精，慢慢優化。

優點：每一次的迭代，客戶都可以看到成果物，然後做出反饋。相比瀑布模型在整個項目最後看到結果，每一次迭代的完成都可以看到相關的結果和得到客戶的反饋。同時，每一次跌代里，都是小的瀑布模型，從而保證了每次產出的準確性。

缺點：明知道項目中的不足之處，但是不馬上修復。將主要精力優先放在從無到有的過程中。

所以對於迭代模型，即保持了瀑布模型成果物的高質量，也降低了項目在實施過程中需求頻繁變化造成的負面影響。但是在短期內，無法整體到達客戶質量要求。

敏捷開發：是一種應對快速變化需求的一種軟體開發模型。更加強調面對面的溝通。和非敏捷類模型不同，敏捷開發，強調：

人和交互終於過程和工具

可以工作的軟體終於求全而完備的文檔

客戶協作終於合同談判

隨時應對變化終於循規蹈矩。

於是對於敏捷的模型，可以歸納為，整個團隊是一個整體來工作的；有迭代周期，每次迭代交付一些成果物。這些和迭代很像。但是不同於迭代的是，敏捷的周期更短，適用於項目初期需求不明確的情況。

因為敏捷開發的模型，並不注重整體的項目進度。相反的敏捷強調的是業務優先順序，檢查和調整。於是即使在項目初期需求不明的情況下，使用敏捷的方式開發，可以做到每個迭代周期都能夠得到基於該迭代周期的成果物。而客戶可以根據當前迭代周期的成果，確定後一周期的目標。所以，敏捷強調的不是預見性，而是適應性。

優點：適用於項目初期需求不明的情況。

缺點：適合與小團隊，不適合與大團隊實行敏捷。對於團隊成員要求比較高。對於項目整體的目標沒有清晰的設定。

最後簡單對於幾個開發模型的區別做一個總結：

瀑布式開發模型，對於需求，設計，編碼，測試，交付各個階段，每一個階段都要求做到最好。前期階段也好，後期成本損失也少。即，做的慢， 但是完美。前提是需求不能變。

迭代式開發模型，不要求每一個階段的任務做的是最完美的，知道有不足，但是不去完善它。即用最短的時間，搭建一個不完美的成果物。然後在通過客戶反饋信息，逐步完善。

敏捷開發模型：強調團隊高協作。開發周期比迭代更短，常用於項目初期需求不明的情況下。通過適應性彌補預見性不足。即當需求發生變化時，快速反應，產出成果。但是具體項目將來要做成什麼樣，並不知曉。

現實場景中的項目其實並不僅僅使用一個開發模型的。項目經理需要根據當前項目階段的特點，來選擇合適的項目模型。

如果當前項目初期需求經常變化，那麼敏捷會是一個不錯的選擇。而一旦需求確定了，可以使用迭代的方式，進行開發。並且將瀑布模型植入迭代的每一個周期。這樣既保證了迭代的每一個周期的產出質量。有可以適應客戶經常變化需求的客觀事實。

當然，項目有特殊性，所以具體問題還需要具體分析。切記照搬經驗。