軟體專案超出計劃的目標，通常被稱為範圍蔓延，是IT開發過程固有的矛盾。範圍蔓延由幾個原因引起而且如果處理不當將成為專案失敗的主要原因。你必須採取一些步驟來控制對專案的改進並確保你和你的開發團隊不會受到這些改進所造成的負面影響的損害--完工時間的拖延和工程預算的超支。

幸運的是，你可以遵循一些規則來防止專案範圍蔓延造成出軌。我們馬上就會學習這些方法。但是首先，讓我們先來看一個警示性的例子，它能夠幫助我們明白如果沒有合適的計劃和控制，事情會變得多麼壞。

可怕的故事

當我在一家顧問公司工作的時候，我親眼見證了我們的姐妹公司在一次公司內部為使用者開發以Web中心的桌面環境的時候在專案範圍上所做的掙扎。這個專案在五年前迫不及待的展開，沒有專案計劃而且只有一個主要開發者指導它的進度。開始的時候這個專案有許多很有天賦的Java 程式設計師而他們所有的指導來自於他們的並非技術專家的上司。

這聽起來象是一場惡夢，它確實是一場惡夢而且現在還是這樣。今天這家公司有了一個不值得的客戶和一個其競爭對手在兩年以前就已經超越的產品。隨著這個專案繼續進行，這家公司自身已經無法為它的員工發工資了，這對投資者看起來象一個無底洞，而且在它的管理層看來還只是剛剛開始。由於在開始工作的時候沒有簽定正式的專案意向書，這個專案的範圍不斷的改變，甚至每天都在改變，而所有的工作，從開發到銷售和質量保證都因為不斷改變的專案範圍所帶來的繁重工作而停滯。

好的一面

專案範圍改變的效果並不一定是負面的，這得看你的實際情況。如果你是擔當顧問或者是為一家顧問公司工作，那麼軟體功能改進對於你的業務來說是非常好的--只要能夠很專業的處理這個問題。對於公司內部的軟體開發過程，額外的功能能夠讓你的產品比你的競爭對手更勝一籌。但是，如果你釋出軟體的時間推遲一兩個月，那麼這個優勢就會被丟失。透過控制你開發過程的費用並按時釋出軟體，你的專案就會取得成功，而不需要損失在軟體製作過程中的靈活性。

從第一天開始就進行軟體專案範圍控制

控制專案範圍在編寫第一行程式碼以前就已經開始了。不論實際情況如何，每一次開發工作都應該有相應的專案計劃或者專案協議書。即使你只是一個希望讓老闆高興的程式設計師，你也能夠因為在開始工作以前制定計劃書而得到很多的好處。你可以使用下面的步驟來使自己成功的控制專案的範圍：

1. 確保自己明白專案的範圍。與專案主管會談併發布整個專案的概覽交與他們檢視和評論。

2. 瞭解你自己認為重要的東西和專案主管認為重要的東西。在專案進行的整個過程裡把你得到的資訊按順序列成一張表。這些資訊應該包括預算，專案截止時間，功能釋出，客戶滿意度，以及員工的滿意度。一旦專案開始，你將使用這個表來調整你的時間安排。

3. 定義你的專案釋出目標並讓專案主管同意它們。專案釋出目標應該是在專案過程中應該完成的功能的大概描述。

4. 把經過同意的專案釋出目標細化成具體的工作要求。這些要求應該儘可能的詳細並使用一個簡單的電子表格來完成它。你的專案越大，那麼你就應該包括更多的細節。如果你的專案持續的時間不止一兩個月的話，不要忘記包括開發過程中軟體升級的時間，你還應該總是為編寫充足的文件而留下時間。

5. 將專案分解成大的和小的里程碑並編寫一個大概的專案時間表以獲得專案主管的同意。小的里程碑應該不持續一個月以上。不論你用什麼方法確定任務的持續時間，你都應該為修正錯誤留下時間。在與不熟悉的員工一起工作的時候，我通常把時間定為預計工作時間的140％到160％。如果你的時間比較緊，那麼你應該重新評估你的專案釋出目標。在預算的範圍內和截止的時間以前完成專案能夠為額外的改進留下空間。

6. 一旦時間表已經創立，那麼你就需要使用一個PERT圖表或者任務分配表來分配資源和確定專案的關鍵路徑。微軟Project軟體能夠自動為你建立這些東西。你專案的關鍵路徑會在專案進行的過程中發生改變。遵循這個圖表來確定什麼釋出目標必須在規定的時間裡完成。在非常大的專案裡，我儘量做到不把我的開發階段標準定義得太早，但是即使一個大概的計劃也能夠為你提供成功釋出軟體的依據。

7. 意識到會出現專案範圍蔓延。儘早填寫“專案範圍改變要求”表格並在開發的過程中說服專案主管。一個“專案範圍改變要求”表格能夠讓你在按專案主管的要求進行時間表改變以前對這些改變進行收益投入比的分析。

如果你能夠立刻開始所有這些步驟，那很好。但是，即使你只能開始遵循其中的一些步驟，那麼你所遵循的任何步驟都能夠讓你儘可能的避免和控制專案範圍蔓延。用那種方式，你就能夠更好的控制你的專案，而不是讓你的專案控制你。
[@more@]

防止軟體工程專案範圍蔓延的七個步驟(轉)

相關文章