大多數(shù)的軟件項(xiàng)目都是失敗的。實(shí)際上，Standish group 報(bào)告表明，80% 以上的項(xiàng)目都是不成功的，或者是因?yàn)槌^預(yù)算或延期未完或缺失功能，或者幾種因素都有。此外，30% 的軟件項(xiàng)目執(zhí)行得十分糟糕以至于在完成之前就被取消了。根據(jù)我們的經(jīng)驗(yàn)，即便使用了諸如 Java、J2EE、XML 及 Web 服務(wù)的現(xiàn)代技術(shù)，軟件項(xiàng)目都無一例外的應(yīng)驗(yàn)了這條規(guī)律。本文概述了有助于提高軟件開發(fā)項(xiàng)目成功率的最重要的十點(diǎn)因素。Standish Group 等業(yè)界領(lǐng)頭羊也為軟件項(xiàng)目提供了重要的成功因素文檔。

項(xiàng)目成功的因素

1. 招募技術(shù)熟練、經(jīng)驗(yàn)豐富的人員 — 現(xiàn)在的環(huán)境要比以往的任何時(shí)候都要復(fù)雜。

像WebSphere? Studio 這樣的工具是很有用的，但在經(jīng)驗(yàn)不足的員工手里結(jié)果往往最多不過得到普普通通的成效，大多數(shù)時(shí)候還是失敗，這是因?yàn)樗麄儾欢裁词呛玫捻?xiàng)目管理以及應(yīng)用新技術(shù)的最佳實(shí)踐。優(yōu)秀的項(xiàng)目經(jīng)理和項(xiàng)目架構(gòu)師或技術(shù)指導(dǎo)將結(jié)成項(xiàng)目的領(lǐng)導(dǎo)力量。他們決定了這個(gè)項(xiàng)目將如何開展，并且對項(xiàng)目最終是否成功有著巨大的影響。如果您擁有這樣的人員，對待他們要好，而且要非常好。項(xiàng)目經(jīng)理和技術(shù)指導(dǎo)有必要面試其他小組成員并決定誰可以加入這個(gè)小組。小組的其余成員同樣需要具有平均水平以上的技能和經(jīng)驗(yàn)。表現(xiàn)不好的人需要不斷去關(guān)注，但他們通?？偸恰斑_(dá)不到要求”。最終，他們總是會(huì)拖小組的后腿，使得項(xiàng)目進(jìn)展緩慢。然而，這并不意味著小組中不能有任何初級(jí)水平的人員。通常，這種成員如果獲得機(jī)會(huì)就會(huì)受到更大激勵(lì)，會(huì)盡力把事情做到最好。例如，在一個(gè) 20 人的小組里，可能有 2 個(gè)領(lǐng)導(dǎo)，6 個(gè)高級(jí)人員，9 個(gè)中級(jí)人員和 3 個(gè)初級(jí)人員。這樣 20 人的小組可以再細(xì)分為 4 或 5 個(gè)小組，每個(gè)組有一個(gè)組長。IBM Software Services 和 IBM Global Services（IGS）有經(jīng)驗(yàn)豐富的項(xiàng)目經(jīng)理、項(xiàng)目架構(gòu)師、技術(shù)指導(dǎo)和顧問，他們可以為您的項(xiàng)目提供幫助。

2. 應(yīng)用前沿的、但非極端前沿的技術(shù)

《財(cái)富》雜志 500 強(qiáng)中的許多公司已經(jīng)在軟件項(xiàng)目中成功地應(yīng)用了成熟技術(shù)（如 J2EE 和 WebSphere 產(chǎn)品系列），這些項(xiàng)目對公司的商業(yè)經(jīng)營模式產(chǎn)生了巨大的影響。在某些情況下，應(yīng)用前沿技術(shù)是有必要的，這有助于幫助您在競爭中獲得顯著的優(yōu)勢。但是，這樣一種策略是需要承擔(dān)風(fēng)險(xiǎn)的，在這種情況下更重要的是擁有優(yōu)秀的項(xiàng)目人員。由于幾乎沒有人具有這類前沿技術(shù)方面的經(jīng)驗(yàn)，所以獲取外部專家的幫助同樣重要。項(xiàng)目若采用極端前沿的技術(shù)或還未測試通過的技術(shù)就必須自行考慮研究計(jì)劃。這也許對新興技術(shù)中的概念進(jìn)行早期驗(yàn)證會(huì)有所幫助。然而，與使用更成熟技術(shù)的項(xiàng)目相比，要用相同的方法或以相同的成本來交付基于這樣一種技術(shù)的項(xiàng)目是不現(xiàn)實(shí)的。

3. 運(yùn)用正確的開發(fā)流程 — 現(xiàn)代軟件項(xiàng)目的特性要求使用一種螺旋式的開發(fā)流程（如 Rational 統(tǒng)一流程（Rational Unified Process，RUP）、某種反復(fù)式 IGS 方法甚或是靈活方法（如極端編程（eXtreme Programming）。

螺旋式的開發(fā)流程具有多個(gè)開發(fā)階段，可以逐步地降低項(xiàng)目風(fēng)險(xiǎn)。在每個(gè)階段結(jié)束時(shí)都需要決定繼續(xù)還是停止。在初期階段，原型可以用來供小組研究新技術(shù)，也可以用來研究用戶界面。舉例來說，RUP 方法定義了每個(gè)階段的角色、任務(wù)和構(gòu)件，這些在項(xiàng)目小組在考慮項(xiàng)目相關(guān)事宜時(shí)起到提示作用。對任何項(xiàng)目而言，最重要的一點(diǎn)并不是用哪一個(gè)流程，而是流程應(yīng)用得有多好。項(xiàng)目經(jīng)理和技術(shù)指導(dǎo)需要重視并懂得如何根據(jù)碰到的問題調(diào)整流程，以及如何應(yīng)用最佳實(shí)踐來執(zhí)行流程。流程為需要做什么提供了指導(dǎo)和提示。另一方面，偏離流程原則太遠(yuǎn)也會(huì)導(dǎo)致災(zāi)難性的結(jié)果。相關(guān)文章軟件開發(fā)項(xiàng)目的最佳實(shí)踐中有詳細(xì)的內(nèi)容。

4. 提供適當(dāng)?shù)墓ぞ?— 任何的軟件項(xiàng)目都需要有適合的工具來幫助小組提高生產(chǎn)力。

這些工具包括適當(dāng)?shù)挠布O(shè)備以及設(shè)計(jì)、編程、和測試工具。工具成本的合理性解釋起來相對比較簡單。例如，假設(shè)像 WebSphere Studio Application Developer 這樣一個(gè) IDE 環(huán)境可以節(jié)約一個(gè)程序員一個(gè)星期 5 個(gè)小時(shí)的時(shí)間，平均下來，這個(gè)程序員對公司而言成本為 50美元／小時(shí)。很容易看出，這樣的投資回報(bào)（return on investment，ROI）是值得的。同樣的道理，要保證小組使用最新的和最快的 PC 用于開發(fā)，還要為質(zhì)量保證、用戶確認(rèn)和部署測試提供適當(dāng)?shù)臏y試環(huán)境。進(jìn)行應(yīng)用新工具或新技術(shù)的培訓(xùn)對于完全發(fā)揮這些工具或技術(shù)的優(yōu)勢是必需的。IBM 擁有一個(gè)巨大的培訓(xùn)資源庫，包括在線及課堂課程。IBM Software Services 和 IGS 的顧問還可以提供專題討論、咨詢和現(xiàn)場培訓(xùn)。

5. 應(yīng)用源文檔控制管理

在項(xiàng)目一開始就要應(yīng)用源文檔控制管理（SCM）系統(tǒng)。不僅是源代碼，所有的文檔都要實(shí)施 SCM 系統(tǒng)的版本控制。這使得小組可以回顧項(xiàng)目的歷史記錄，并獲取項(xiàng)目早期版本的所有相關(guān)文檔，如用例、體系結(jié)構(gòu)和設(shè)計(jì)文檔、以及測試腳本和測試計(jì)劃。我推薦您使用企業(yè)級(jí)的 SCM 產(chǎn)品，如 Rational ClearCase/ClearQuest。

6. 應(yīng)用有效的評估方法

多數(shù)項(xiàng)目在執(zhí)行時(shí)都會(huì)超出預(yù)期的時(shí)間的 25% 到 100%，但也有一些項(xiàng)目比較準(zhǔn)時(shí)，與進(jìn)度相差的時(shí)間不到 10%。如果不能準(zhǔn)確地估算進(jìn)度，就沒有辦法有效地進(jìn)行計(jì)劃。但是，在項(xiàng)目的初期階段所估算出的用時(shí)和工作量是非常模糊的。這些估算包含了許多偶然性并且可能使估算的值要翻上一倍。軟件開發(fā)是一個(gè)逐步求精的過程，估算也是如此。隨著項(xiàng)目的向前進(jìn)展，估算也會(huì)更加精確。在項(xiàng)目結(jié)束時(shí)即可獲知項(xiàng)目實(shí)際的用時(shí)和工作量。多數(shù)軟件工程師往往會(huì)估計(jì)不足，項(xiàng)目的成本自然就很可能有所增加。當(dāng)估算進(jìn)度時(shí)，注意不要過多地壓縮進(jìn)度。小組如果不能按照緊湊的進(jìn)度執(zhí)行，最終很可能與預(yù)期進(jìn)度相差很遠(yuǎn)。

7. 將工作細(xì)化為小的目標(biāo)

小目標(biāo)就是大目標(biāo)細(xì)化后的結(jié)果。主要的目標(biāo)是一個(gè)階段或一段增量的末尾。要達(dá)到那一點(diǎn)，項(xiàng)目需要在整個(gè)進(jìn)程中都設(shè)立細(xì)化的目標(biāo)。小目標(biāo)一到兩天的工夫就可以達(dá)到，以小時(shí)為單位。它有這樣的好處：可以改善狀態(tài)報(bào)告；因?yàn)榭梢灾酪粋€(gè)小目標(biāo)是否沒有完成所以能夠?qū)崿F(xiàn)細(xì)粒度控制；因?yàn)榇蠹s每天都可以完成一個(gè)小目標(biāo)所以會(huì)更好地激勵(lì)員工；還有可以降低執(zhí)行進(jìn)度超時(shí)的風(fēng)險(xiǎn)。為了避免項(xiàng)目中的各種問題，建議小目標(biāo)的設(shè)定從項(xiàng)目一開始時(shí)就著手實(shí)施。最好的辦法是用電子表格記錄和跟蹤小目標(biāo)的執(zhí)行進(jìn)度。由工具（如 MicroSoft? Project）生成的項(xiàng)目計(jì)劃最好只用于更上層的任務(wù)。當(dāng)然，只當(dāng)前的階段才劃分多個(gè)小目標(biāo)任務(wù)。后面的階段在需要時(shí)再進(jìn)行劃分。盡管開發(fā)人員認(rèn)為設(shè)定小目標(biāo)是個(gè)麻煩，但是這個(gè)問題補(bǔ)償了小組領(lǐng)導(dǎo)和單個(gè)開發(fā)人員定義他們自己的目標(biāo)并分散項(xiàng)目管理和跟蹤項(xiàng)目的工作量的能力。通常一個(gè)由技術(shù)指導(dǎo)定義的任務(wù)，一旦由開發(fā)人員將其細(xì)化為多個(gè)小的目標(biāo)，則任務(wù)就會(huì)變得更大。有時(shí)技術(shù)指導(dǎo)會(huì)提供備選的、更快、更易維護(hù)的方案，在其他一些場合他也同意任務(wù)的分解并分配給任務(wù)更多的時(shí)間。盡早地實(shí)施小目標(biāo)計(jì)劃的工作可以避免潛在的災(zāi)難性結(jié)果的發(fā)生。

8. 以小時(shí)為單位跟蹤所有的項(xiàng)目時(shí)間

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

9. 應(yīng)對不斷出現(xiàn)的變化

對于大多數(shù)項(xiàng)目，每個(gè)月項(xiàng)目的需求變化不會(huì)大于 5%。這些變化的產(chǎn)生有多方面的原因，例如沒能在正確的時(shí)間提出恰當(dāng)?shù)膯栴}、正在處理的問題發(fā)生了變化、用戶改變了他們的主意或觀念、商業(yè)環(huán)境發(fā)生了變化或者是市場發(fā)生了變化。功能特性蠕變都會(huì)輕易使得成本和執(zhí)行進(jìn)度超出預(yù)先的估計(jì)。在項(xiàng)目的初期階段，項(xiàng)目需求中有許多纏雜不清的地方。當(dāng)執(zhí)行到某個(gè)階段（通常在第二階段的末尾）時(shí)，項(xiàng)目需求就必需確定下來并鎖定其核心內(nèi)容。一個(gè)變化的管理過程由一個(gè)所謂的“變化委員會(huì)（change board）”來執(zhí)行，變化委員會(huì)由項(xiàng)目所涉及的每個(gè)領(lǐng)域的代表組成，例如業(yè)務(wù)、市場、開發(fā)、質(zhì)量保證、用戶文檔、客戶支持和項(xiàng)目管理等。變化委員會(huì)負(fù)責(zé)將所要做的改變交由適當(dāng)?shù)娜巳ネ瓿伞Ω淖冏鞒稣f明并測定來自各方的估算值的大小。在獲得足夠的信息后，變化委員會(huì)就可以決定接受還是拒絕這項(xiàng)變化。一旦接受一個(gè)變化，它將被加入到計(jì)劃當(dāng)中并且執(zhí)行進(jìn)度也要做出改變。伴隨有變化的項(xiàng)目要比原先沒有變化的項(xiàng)目提交得晚，但是它仍然是成功的，因?yàn)樗匀粷M足修正后的執(zhí)行進(jìn)度和股東的期望。一個(gè)項(xiàng)目如果在啟用變化委員會(huì)之后有超過 5% 的改變，則表明項(xiàng)目制定得非常糟糕或者已失去了控制，最終很可能會(huì)失敗。

10. 項(xiàng)目領(lǐng)導(dǎo)

公司的管理者委任一個(gè)執(zhí)行者承擔(dān)軟件項(xiàng)目成果的責(zé)任是至關(guān)重要的。這個(gè)關(guān)鍵的執(zhí)行者不僅要總覽全局，還要獲得和控制項(xiàng)目所需的資源來幫助和支持這個(gè)小組。同樣重要的是，執(zhí)行者不需要去干涉、管理小組中的一些瑣碎的事。執(zhí)行者要相信小組是可以委以重任的。

結(jié)束語

本文列出了幫助提高軟件開發(fā)項(xiàng)目成功率的十點(diǎn)因素。遵從這些指導(dǎo)原則，您可以在預(yù)算和預(yù)定時(shí)間范圍內(nèi)更好地完成項(xiàng)目、保持一個(gè)高效率的小組并盡量不改變功能特性。您可以參考 Mike 的另一篇關(guān)于最佳實(shí)踐的文章軟件開發(fā)項(xiàng)目的最佳實(shí)踐。

【?發(fā)表評論?0條?】