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

項目成功的因素

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

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

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

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

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

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

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

這些工具包括適當(dāng)?shù)挠布O(shè)備以及設(shè)計、編程、和測試工具。工具成本的合理性解釋起來相對比較簡單。例如，假設(shè)像 WebSphere Studio Application Developer 這樣一個 IDE 環(huán)境可以節(jié)約一個程序員一個星期 5 個小時的時間，平均下來，這個程序員對公司而言成本為 50美元／小時。很容易看出，這樣的投資回報（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 擁有一個巨大的培訓(xùn)資源庫，包括在線及課堂課程。IBM Software Services 和 IGS 的顧問還可以提供專題討論、咨詢和現(xiàn)場培訓(xùn)。

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

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

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

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

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

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

8. 以小時為單位跟蹤所有的項目時間

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

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

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

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

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

結(jié)束語

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

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