實際上，採用何種方法開發軟體取決於很多因素，同時受到環境的制約軟體工程開發方法編輯國外大的軟體公司和機構一直在研究軟體開發方法這個概念性的東西，而且也提出了很多實際的開發方法，比如：生命週期法、原型化方法、面向物件方法等等。

大多數的軟體專案都是失敗的。實際上，Standish group 報告表明，80% 以上的專案都是不成功的，或者是因為超過預算或延期未完或缺失功能，或者幾種因素都有。此外，30% 的軟體專案執行得十分糟糕以至於在完成之前就被取消了。根據我們的經驗，即便使用了諸如 Java、J2EE、XML 及 Web 服務的現代技術，軟體專案都無一例外的應驗了這條規律。本文概述了有助於提高軟體開發專案成功率的最重要的十點因素。Standish Group 等業界領頭羊也為軟體專案提供了重要的成功因素文件。 

　　 專案成功的因素 

　　 1. 招募技術熟練、經驗豐富的人員 — 現在的環境要比以往的任何時候都要複雜。 

　　 像WebSphere? Studio 這樣的工具是很有用的，但在經驗不足的員工手裡結果往往最多不過得到普普通通的成效，大多數時候還是失敗，這是因為他們不懂什麼是好的專案管理以及應用新技術的最佳實踐。優秀的專案經理和專案架構師或技術指導將結成專案的領導力量。他們決定了這個專案將如何開展，並且對專案最終是否成功有著巨大的影響。如果您擁有這樣的人員，對待他們要好，而且要非常好。專案經理和技術指導有必要面試其他小組成員並決定誰可以加入這個小組。小組的其餘成員同樣需要具有平均水平以上的技能和經驗。表現不好的人需要不斷去關注，但他們通常總是“達不到要求”。最終，他們總是會拖小組的後腿，使得專案進展緩慢。然而，這並不意味著小組中不能有任何初級水平的人員。通常，這種成員如果獲得機會就會受到更大激勵，會盡力把事情做到最好。例如，在一個 20 人的小組裡，可能有 2 個領導，6 個高階人員，9 箇中級人員和 3 個初級人員。這樣 20 人的小組可以再細分為 4 或 5 個小組，每個組有一個組長。IBM Software Services 和 IBM Global Services（IGS）有經驗豐富的專案經理、專案架構師、技術指導和顧問，他們可以為您的專案提供幫助。 

　　 2. 應用前沿的、但非極端前沿的技術 

　　 《財富》雜誌 500 強中的許多公司已經在軟體專案中成功地應用了成熟技術（如 J2EE 和 WebSphere 產品系列），這些專案對公司的商業經營模式產生了巨大的影響。在某些情況下，應用前沿技術是有必要的，這有助於幫助您在競爭中獲得顯著的優勢。但是，這樣一種策略是需要承擔風險的，在這種情況下更重要的是擁有優秀的專案人員。由於幾乎沒有人具有這類前沿技術方面的經驗，所以獲取外部專家的幫助同樣重要。專案若採用極端前沿的技術或還未測試透過的技術就必須自行考慮研究計劃。這也許對新興技術中的概念進行早期驗證會有所幫助。然而，與使用更成熟技術的專案相比，要用相同的方法或以相同的成本來交付基於這樣一種技術的專案是不現實的。 

　　 3. 運用正確的開發流程 — 現代軟體專案的特性要求使用一種螺旋式的開發流程（如 Rational 統一流程（Rational Unified Process，RUP））、某種反覆式 IGS 方法甚或是靈活方法（如極端程式設計（eXtreme Programming））。 

　　 螺旋式的開發流程具有多個開發階段，可以逐步地降低專案風險。在每個階段結束時都需要決定繼續還是停止。在初期階段，原型可以用來供小組研究新技術，也可以用來研究使用者介面。舉例來說，RUP 方法定義了每個階段的角色、任務和構件，這些在專案小組在考慮專案相關事宜時起到提示作用。對任何專案而言，最重要的一點並不是用哪一個流程，而是流程應用得有多好。專案經理和技術指導需要重視並懂得如何根據碰到的問題調整流程，以及如何應用最佳實踐來執行流程。流程為需要做什麼提供了指導和提示。另一方面，偏離流程原則太遠也會導致災難性的結果。相關文章軟體開發專案的最佳實踐中有詳細的內容。 

　　 4. 提供適當的工具 — 任何的軟體專案都需要有適合的工具來幫助小組提高生產力。 

　　 這些工具包括適當的硬體裝置以及設計、程式設計、和測試工具。工具成本的合理性解釋起來相對比較簡單。例如，假設像 WebSphere Studio Application Developer 這樣一個 IDE 環境可以節約一個程式設計師一個星期 5 個小時的時間，平均下來，這個程式設計師對公司而言成本為 50美元／小時。很容易看出，這樣的投資回報（return on investment，ROI）是值得的。同樣的道理，要保證小組使用最新的和最快的 PC 用於開發，還要為質量保證、使用者確認和部署測試提供適當的測試環境。進行應用新工具或新技術的培訓對於完全發揮這些工具或技術的優勢是必需的。IBM 擁有一個巨大的培訓資源庫，包括線上及課堂課程。IBM Software Services 和 IGS 的顧問還可以提供專題討論、諮詢和現場培訓。 

　　 5. 應用源文件控制管理 

　　 在專案一開始就要應用源文件控制管理（SCM）系統。不僅是原始碼，所有的文件都要實施 SCM 系統的版本控制。這使得小組可以回顧專案的歷史記錄，並獲取專案早期版本的所有相關文件，如用例、體系結構和設計文件、以及測試指令碼和測試計劃。我推薦您使用企業級的 SCM 產品，如 Rational ClearCase/ClearQuest。 

　　 6. 應用有效的評估方法 

　　 多數專案在執行時都會超出預期的時間的 25% 到 100%，但也有一些專案比較準時，與進度相差的時間不到 10%。如果不能準確地估算進度，就沒有辦法有效地進行計劃。但是，在專案的初期階段所估算出的用時和工作量是非常模糊的。這些估算包含了許多偶然性並且可能使估算的值要翻上一倍。軟體開發是一個逐步求精的過程，估算也是如此。隨著專案的向前進展，估算也會更加精確。在專案結束時即可獲知專案實際的用時和工作量。多數軟體工程師往往會估計不足，專案的成本自然就很可能有所增加。當估算進度時，注意不要過多地壓縮排度。小組如果不能按照緊湊的進度執行，最終很可能與預期進度相差很遠。 

　　 7. 將工作細化為小的目標 

　　 小目標就是大目標細化後的結果。主要的目標是一個階段或一段增量的末尾。要達到那一點，專案需要在整個程序中都設立細化的目標。小目標一到兩天的工夫就可以達到，以小時為單位。它有這樣的好處：可以改善狀態報告；因為可以知道一個小目標是否沒有完成所以能夠實現細粒度控制；因為大約每天都可以完成一個小目標所以會更好地激勵員工；還有可以降低執行進度超時的風險。為了避免專案中的各種問題，建議小目標的設定從專案一開始時就著手實施。最好的辦法是用電子表格記錄和跟蹤小目標的執行進度。由工具（如 MicroSoft? Project）生成的專案計劃最好只用於更上層的任務。當然，只當前的階段才劃分多個小目標任務。後面的階段在需要時再進行劃分。儘管開發人員認為設定小目標是個麻煩，但是這個問題補償了小組領導和單個開發人員定義他們自己的目標並分散專案管理和跟蹤專案的工作量的能力。通常一個由技術指導定義的任務，一旦由開發人員將其細化為多個小的目標，則任務就會變得更大。有時技術指導會提供備選的、更快、更易維護的方案，在其他一些場合他也同意任務的分解並分配給任務更多的時間。儘早地實施小目標計劃的工作可以避免潛在的災難性結果的發生。 

　　 8. 以小時為單位跟蹤所有的專案時間 

　　 不僅要跟蹤以小時付薪的顧問和立約人所花的時間，每個專案成員所花費的時間同樣很重要。這樣做的好處是可以對照個人所用的時間與專案計劃的時間。如果個人已經轉向其他任務就要採取一些步驟。同樣，實際的時間也可以對照估算的時間，估算的時間可以依次地為專案的下一個階段或下一個專案的時間估算方法提供反饋。對小目標的全部時間的估算可以限制時限的超出，因而這些時限是可以修正的。應用小目標技術要求來自各方面的包括技術指導、小組領導和每個開發人員的時間和努力。至少每個星期，每個開發人員要以電子表格的方式提交他的工作狀況，讓專案主管可以在每個更上層的任務中更新完成進度的百分比。這樣將使專案管理的工作量分散到其他的小組成員身上。跟蹤專案時間會耗費更多的時間，但這能實現非常有效的專案管理。 

　　 9. 應對不斷出現的變化 

　　 對於大多數專案，每個月專案的需求變化不會大於 5%。這些變化的產生有多方面的原因，例如沒能在正確的時間提出恰當的問題、正在處理的問題發生了變化、使用者改變了他們的主意或觀念、商業環境發生了變化或者是市場發生了變化。功能特性蠕變都會輕易使得成本和執行進度超出預先的估計。在專案的初期階段，專案需求中有許多纏雜不清的地方。當執行到某個階段（通常在第二階段的末尾）時，專案需求就必需確定下來並鎖定其核心內容。一個變化的管理過程由一個所謂的“變化委員會（change board）”來執行，變化委員會由專案所涉及的每個領域的代表組成，例如業務、市場、開發、質量保證、使用者文件、客戶支援和專案管理等。變化委員會負責將所要做的改變交由適當的人去完成、對改變作出說明並測定來自各方的估算值的大小。在獲得足夠的資訊後，變化委員會就可以決定接受還是拒絕這項變化。一旦接受一個變化，它將被加入到計劃當中並且執行進度也要做出改變。伴隨有變化的專案要比原先沒有變化的專案提交得晚，但是它仍然是成功的，因為它仍然滿足修正後的執行進度和股東的期望。一個專案如果在啟用變化委員會之後有超過 5% 的改變，則表明專案制定得非常糟糕或者已失去了控制，最終很可能會失敗。 

　　 10. 專案領導 

　　 公司的管理者委任一個執行者承擔軟體專案成果的責任是至關重要的。這個關鍵的執行者不僅要總覽全域性，還要獲得和控制專案所需的資源來幫助和支援這個小組。同樣重要的是，執行者不需要去幹涉、管理小組中的一些瑣碎的事。執行者要相信小組是可以委以重任的。 

　　 結束語 

　　 本文列出了幫助提高軟體開發專案成功率的十點因素。遵從這些指導原則，您可以在預算和預定時間範圍內更好地完成專案、保持一個高效率的小組並儘量不改變功能特性。