提高軟件開發(fā)項目成功率的十大影響因素

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

2、時候都要復雜。像WebSphere? Studio這樣的工具是很有用的，但在經(jīng)驗缺乏的員工手里結(jié)果往往最多不過得到普普通通的成效，大多 數(shù)時候還是失敗，這是因為他們不懂什么是好的工程管理以 及應(yīng)用新技術(shù)的最正確實踐。優(yōu)秀的工程經(jīng)理和工程架構(gòu)師或 技術(shù)指導將結(jié)成工程的領(lǐng)導力量。他們決定了這個工程將如 何開展，并且對工程最終是否成功有著巨大的影響。如果您 擁有這樣的人員，對待他們要好，而且要非常好。工程經(jīng)理 和技術(shù)指導有必要面試其他小組成員并決定誰可以加入這個 小組。小組的其余成員同樣需要具有平均水平以上的技能和 經(jīng)驗。表現(xiàn)不好的人需要不斷去關(guān)注，但他們通?？偸恰斑_ 不到要求“。最終，他們總是會拖

3、小組的后腿，使得工程進 展緩慢。然而，這并不意味著小組中不能有任何初級水平的人員。通常，這種成員如果獲得機會就會受到更大激勵，會 盡力把事情做到最好。例如，在一個20人的小組里，可能 有2個領(lǐng)導，6個高級人員，9個中級人員和3個初級人 員。這樣20人的小組可以再細分為4或5個小組，每個 組有一個組長。IBM Software Services 和 IBM Global Services (IGS)有經(jīng)驗豐富的工程經(jīng)理、工程架構(gòu)師、技術(shù) 指導和顧問，他們可以為您的工程提供幫助。.應(yīng)用前沿的、但非極端前沿的技術(shù)財富雜志500強中的許多公司已經(jīng)在軟件工程中成功地 應(yīng)用了成熟技術(shù)(如J2EE和WebS

4、phere產(chǎn)品系列)，這些 工程對公司的商業(yè)經(jīng)營模式產(chǎn)生了巨大的影響。在某些情況 下，應(yīng)用前沿技術(shù)是有必要的，這有助于幫助您在競爭中獲 得顯著的優(yōu)勢。但是，這樣一種策略是需要承當風險的，在 這種情況下更重要的是擁有優(yōu)秀的工程人員。由于幾乎沒有 人具有這類前沿技術(shù)方面的經(jīng)驗，所以獲取外部專家的幫助 同樣重要。工程假設(shè)采用極端前沿的技術(shù)或還未測試通過的技 術(shù)就必須自行考慮研究計劃。這也許對新興技術(shù)中的概念進 行早期驗證會有所幫助。然而，與使用更成熟技術(shù)的工程相 比，要用相同的方法或以相同的本錢來交付基于這樣一種技 術(shù)的工程是不現(xiàn)實的。.運用正確的開發(fā)流程-現(xiàn)代軟件工程的特性要求使用一種螺旋式的開發(fā)

5、流程(如 Rational 統(tǒng)一流程(Rational Unified Process,RUP)、某種反復式IGS方法甚或是靈活方法(如極端編 程 (eXtreme Programming)。螺漩式的開發(fā)流程具有多個開發(fā)階段，可以逐步地降低工程 風險。在每個階段結(jié)束時都需要決定繼續(xù)還是停止。在初期 階段，原型可以用來供小組研究新技術(shù)，也可以用來研究用 戶界面。舉例來說，RUP方法定義了每個階段的角色、任務(wù) 和構(gòu)件，這些在工程小組在考慮工程相關(guān)事宜時起到提示作 用。對任何工程而言，最重要的一點并不是用哪一個流程, 而是流程應(yīng)用得有多好。工程經(jīng)理和技術(shù)指導需要重視并懂 得如何根據(jù)碰到的問題調(diào)整流程

6、，以及如何應(yīng)用最正確實踐來 執(zhí)行流程。流程為需要做什么提供了指導和提示。另一方,偏離流程原那么太遠也會導致災難性的結(jié)果。相關(guān)文章軟 件開發(fā)工程的最正確實踐中有詳細的內(nèi)容。.提供適當?shù)墓ぞ?任何的軟件工程都需要有適合的工具來幫助小組提高生產(chǎn) 力。這些工具包括適當?shù)挠布O(shè)備以及設(shè)計、編程、和測試工 具。工具本錢的合理性解釋起來相比照擬簡單。例如，假設(shè) 像 WebSphere Studio Application Developer 這樣一個 IDE環(huán)境可以節(jié)約一個程序員一個星期5個小時的時間，平 均下來，這個程序員對公司而言本錢為50美元/小時。很容 易看出，這樣的投資回報（return on i

7、nvestment, ROD是 值得的。同樣的道理，要保證小組使用最新的和最快的PC 用于開發(fā)，還要為質(zhì)量保證、用戶確認和部署測試提供適當 的測試環(huán)境。進行應(yīng)用新工具或新技術(shù)的培訓對于完全發(fā)揮 這些工具或技術(shù)的優(yōu)勢是必需的。IBM擁有一個巨大的培訓 資源庫，包括在線及課堂課程。IBM Software Services和 IGS的顧問還可以提供專題討論、咨詢和現(xiàn)場培訓。.應(yīng)用源文檔控制管理在工程一開始就要應(yīng)用源文檔控制管理（SCM）系統(tǒng)。不僅是 源代碼，所有的文檔都要實施SCM系統(tǒng)的版本控制。這使得 小組可以回顧工程的歷史記錄，并獲取工程早期版本的所有 相關(guān)文檔，如用例、體系結(jié)構(gòu)和設(shè)計文檔、以

8、及測試腳本和測試計劃。我推薦您使用企業(yè)級的SCM產(chǎn)品，如RationalClearCase/ClearQuesto.應(yīng)用有效的評估方法多數(shù)工程在執(zhí)行時都會超出預期的時間的25%到100%,但 也有一些工程比擬準時，與進度相差的時間不到10%。如果 不能準確地估算進度，就沒有方法有效地進行計劃。但是， 在工程的初期階段所估算出的用時和工作量是非常模糊的。這些估算包含了許多偶然性并且可能使估算的值要翻上一 倍。軟件開發(fā)是一個逐步求精的過程，估算也是如此。隨著 工程的向前進展，估算也會更加精確。在工程結(jié)束時即可獲 知工程實際的用時和工作量。多數(shù)軟件工程師往往會估計不 足，工程的本錢自然就很可能有所增

9、加。當估算進度時，注 意不要過多地壓縮進度。小組如果不能按照緊湊的進度執(zhí) 行，最終很可能與預期進度相差很遠。.將工作細化為小的目標小目標就是大目標細化后的結(jié)果。主要的目標是一個階段或 一段增量的末尾。要到達那一點，工程需要在整個進程中都 設(shè)立細化的目標。小目標一到兩天的工夫就可以到達，以小 時為單位。它有這樣的好處：可以改善狀態(tài)報告；因為可以 知道一個小目標是否沒有完成所以能夠?qū)崿F(xiàn)細粒度控制；因 為大約每天都可以完成一個小目標所以會更好地激勵員工； 還有可以降低執(zhí)行進度超時的風險。為了防止工程中的各種 問題，建議小目標的設(shè)定從工程一開始時就著手實施。最好 的方法是用電子表格記錄和跟蹤小目標的執(zhí)

10、行進度。由工具(如Microsoft? Project)生成的工程計劃最好只用于更上 層的任務(wù)。當然，只當前的階段才劃分多個小目標任務(wù)。后 面的階段在需要時再進行劃分。盡管開發(fā)人員認為設(shè)定小目 標是個麻煩，但是這個問題補償了小組領(lǐng)導和單個開發(fā)人員定義他們自己的目標并分散工程管理和跟蹤工程的工作量的 能力。通常一個由技術(shù)指導定義的任務(wù)，一旦由開發(fā)人員將 其細化為多個小的目標，那么任務(wù)就會變得更大。有時技術(shù)指 導會提供備選的、更快、更易維護的方案，在其他一些場合 他也同意任務(wù)的分解并分配給任務(wù)更多的時間。盡早地實施 小目標計劃的工作可以防止?jié)撛诘臑碾y性結(jié)果的發(fā)生。.以小時為單位跟蹤所有的工程時間不

11、僅要跟蹤按小時計酬的顧問和承包商所花費的時間，而 且每個工程成員所花費的時間也很重要。這樣做的好處是能 夠比擬個人花費的時間和工程計劃的時間。如果個人已經(jīng)轉(zhuǎn) 移到其他任務(wù)，應(yīng)該采取一些步驟。同樣，實際時間也可以 與預計時間進行比擬，預計時間可以反過來為工程的下一階 段或下一個工程的時間估算方法提供反應(yīng)。對小目標總時間 的估計可以限定時限，所以這些時限是可以修正的。小目標 技術(shù)的應(yīng)用需要各方面的時間和努力，包括技術(shù)指導、團隊 領(lǐng)導和每一個開發(fā)者。至少每周一次，每個開發(fā)人員應(yīng)該以 電子表格的形式提交他的工作狀態(tài)，以便工程負責人可以更 新每個更高級任務(wù)的完成進度百分比。這將把工程管理的工 作量分散給

12、其他團隊成員。跟蹤工程時間將花費更多的時 間，但它可以實現(xiàn)非常有效的工程管理。.應(yīng)對不斷出現(xiàn)的變化對于大多數(shù)工程，每個月工程的需求變化不會大于5%o這 些變化的產(chǎn)生有多方面的原因，例如沒能在正確的時間提出 恰當?shù)膯栴}、正在處理的問題發(fā)生了變化、用戶改變了他們 的主意或觀念、商業(yè)環(huán)境發(fā)生了變化或者是市場發(fā)生了變 化。功能特性蠕變都會輕易使得本錢和執(zhí)行進度超出預先的 估計。在工程的初期階段，工程需求中有許多纏雜不清的地 方。當執(zhí)行到某個階段（通常在第二階段的末尾）時，工程需求就必需確定下來并鎖定其核心內(nèi)容。一個變化的管理過 程由一個所謂的“變化委員會(change board) ”來執(zhí)行， 變化委

13、員會由工程所涉及的每個領(lǐng)域的代表組成，例如業(yè) 務(wù)、市場、開發(fā)、質(zhì)量保證、用戶文檔、客戶支持和工程管 理等。變化委員會負責將所要做的改變交由適當?shù)娜巳ネ?產(chǎn)、對改變作出說明并測定來自各方的估算值的大小。在獲 得足夠的信息后，變化委員會就可以決定接受還是拒絕這項 變化。一旦接受一個變化，它將被加入到計劃當中并且執(zhí)行 進度也要做出改變。伴隨有變化的工程要比原先沒有變化的 工程提交得晚，但是它仍然是成功的，因為它仍然滿足修正 后的執(zhí)行進度和股東的期望。一個工程如果在啟用變化委員 會之后有超過5%的改變，那么說明工程制定得非常糟糕或者 已失去了控制，最終很可能會失敗。.工程領(lǐng)導對于公司的管理者來說，指定一個執(zhí)行者對軟件工程的結(jié) 果負責是非常重