2017年軟件開發基本原則「錦集」

軟件開發，是根據用户要求建造出軟件系統或者系統中軟件部分的一個產品開發的過程。下面是小編整理的關於軟件開發基本原則，歡迎大家參考!

大多數典型錯誤其表面都具有誘惑性，給人們一種誘人的前景，但通常卻不能產生期望的結果。

“想挽救進度已經落後的項目嗎?---- 給項目補充更多人員!”

下面分別按照人員、過程、產品和技術四個維度列出36個典型錯誤。

人 員

典型錯誤1：挫傷積極性

對人員不夠關心和重視;過度的進度壓力;缺乏激勵;過分誇張的激勵等。

典型錯誤2：人員素質低

人員能力欠佳，工作效率低，甚至做多錯多。

典型錯誤3：對有問題的員工失控

不對有問題的人員採取措施是項目組成員對領導最常見的抱怨。

典型錯誤4：英雄主義

強調個人英雄主義會導致發生額外的風險，也會削弱在軟件開發過程中多個角色的合作。

典型錯誤5：項目後期加入人員

盲目地在項目後期加入人手等於火上澆油。

典型錯誤6：辦公室環境擁擠嘈雜

擁有安靜、隱蔽辦公環境的人員比工作在嘈雜、擁擠環境中的人員往往會有更好的工作業績表現。

典型錯誤7：開發人員與客户之間發生摩擦

主要原因是缺乏溝通。這種摩擦耗費時間，它會轉移客户和開發人員雙方對項目工作的注意力。

典型錯誤8：不現實的預期

過高的期望值和主觀的不切實際的設想。是導致開發人員和客户或項目經理之間的摩擦常見原因之一。

典型錯誤9：缺乏有效的項目支持

軟件開發項目的許都方面都需要高層的支持，包括實際的計劃、變更控制以及新型開發方法的採用等。缺乏有效的高層支持事實上註定了項目的失敗。

典型錯誤10：缺乏各種角色的齊心協力

軟件開發中所有主要人員必須齊心協力專注於項目，包括高層支持者、項目領導、項目成員、市場人員、最終用户、客户和任何項目介入者。

典型錯誤11：缺乏用户介入

沒有用户早期介入的項目充滿需求誤解的風險，易受項目後期功能蔓延的威脅。

典型錯誤12：政治高於物質

“政治家”型項目強調“管理至上”，主要精力集中在他們與經理的關係上。將政治凌駕於結果之上對軟件項目會造成極大傷害。

典型錯誤13：充滿想象

閉上眼睛毫無理由地希望某事將像想象那樣運作。很多軟件開發問題都是由於充滿想象造成的。

想象示例：

項目組不知道他們能不能按時完成項目，但他們認為如果每個人能更努力工作，並且不出現問題，他們應該能完成項目。

我們無需向客户演示最新的修改，我們確信這個效果是客户想要的。

項目組錯過了一個里程碑好幾天了，他們説會更努力工作趕上下一個里程碑，我想他們能夠及時趕上的。

過 程

典型錯誤14：過於樂觀的計劃

定製過於樂觀的項目計劃相當於自己為項目失敗畫出了底線，導致縮短分析、設計等關鍵性前期開發活動;同時也向開發人員施加了額外壓力，會長期對開發人員的自信心和生產率造成巨大傷害。

典型錯誤15：缺乏足夠的風險管理

如果你不主動管理風險，風險隨時會來找你，打亂你的開發計劃。

典型錯誤16：承包人導致的失敗

如果不對承包商加以認真管理，交付可能延期，並且質量難以保證。

典型錯誤17：缺乏計劃

沒有計劃的項目就像飄蕩在海洋中的小船，沒人知道會飄到哪裏。

典型錯誤18：在壓力下放棄計劃

很多項目組定製了計劃，但遇到了麻煩時就放棄計劃。項目失敗的原因不是在於放棄計劃本身，而是不能及時修訂計劃制定替代計劃，並一頭栽進編碼和問題處理中。

典型錯誤19：在模糊的項目前期浪費時間

由於花在審批、預算等前期工作的時間過長，或需求無限循環等原因，導致壓縮開發計劃。項目前期節省幾周或幾個月時間比將開發計劃壓縮同樣時間來得更容易、更廉價，風險也更少。

典型錯誤20：前期活動不符合要求

研究數據：

前期被跳過的活動或工作通常在後期會以10倍到100倍的代價來完成。如果一項工作在項目初期需要5小時完成，那麼在項目後期你至少需要50小時才能完成它。　　(Fagan 1976，Boehm and Papaccio 1988)

典型錯誤21：設計低劣

前期活動不符合要求的一個特殊情況就是設計低劣。高壓環境導致設計缺乏周密思考往往導致設計低劣。

典型錯誤22：缺少質量保證措施

研究數據：

項目前期砍掉1天的質量保證活動，到項目後期就需要3到10天的處理代價。(Jones 1994)

典型錯誤23：缺少管理控制

缺少管理控制點就難以對項目的階段和狀態進行跟蹤，因此不能知道項目是否按正常軌道前進。

典型錯誤24：太早或過於頻繁的集成

在構建未完全鎖定時，進行過早的集成或額外的'集成不利於產品，它僅僅是在浪費時間，延長進度。

典型錯誤25：項目估算時遺漏必要的任務

訓、公司和部門會議，技術評審會議等活動在項目估算時通常被遺漏。

典型錯誤26：追趕計劃

當進度落後時不重新檢查任務和調整計劃，而是簡單地決定把進度趕上來。

另一種情況是，當產品出現變更卻沒有做相應的計劃調整

典型錯誤27：魯莽編碼

沒有足夠的需求基礎和清晰的架構設計而進行“邊編碼邊修改”造成太多重複工作和返工，這樣的做法使項目大多以失敗告終

產 品

典型錯誤28：需求的鍍金

項目的產品要求要求比實際需求多得多的產品特性或複雜功能，卻又不給進度計劃分配足夠的時間。

典型錯誤29：功能蔓延

在整個開發過程中，項目平均會有25%的需求變更，對軟件計劃至少有25%的影響。如果任由客户不斷提出新需求，項目就會一直都做不完

典型錯誤30：開發人員的鍍金

開發人員着迷於新技術，有時渴望在自己的產品中使用這些技術，而不管那些技術是否適合或是否會對系統整體造成破壞。

典型錯誤31：又推又拉的交易

管理者批准進度落後的項目順延，但同時又給這個項目加入新任務。

典型錯誤32：研究導向的開發

軟件開發進度是完全有理由可以預測的，而軟件研究進度甚至理論上都是不可預知的，不能採用像軟件研究一樣的工作方式引導項目開發。

技 術

典型錯誤33：銀彈綜合症

過於相信某些技術宣傳(某種開發過程、某種程序設計方法、某種開發語言)，缺少在特定環境下使用這些工具的必要信息。當團隊寄望利用他們來解決進度問題時，不可避免會失敗的。

典型錯誤34：過高估計了新技術或方法帶來的節省量

無論採用多少新工具或方法，以及這些工具或方法有多好，他們很少能夠大幅度提高生產率。軟件開發由多個任務組成，特定的工具或方法只會可能提高特定任務的生產效率。同時，它們所帶來的效率常常被學習它們所花費的時間抵消了。

典型錯誤35：項目中間切換工具

在項目中間更換工具時，伴隨使用新工具而帶來的人員學習和掌握的過程、重複的工作、不可避免的錯誤等會徹底抵消它所帶來的益處。

典型錯誤36：缺乏自動的源代碼控制手段

缺乏自動的源代碼控制容易造成版本衝突、歷時版本丟失、更新丟失等一系列問題，並浪費大量的時間處理這些問題。