原則 1 質量第一?

QUALITY IS #1?

無論如何定義質量，客戶都不會容忍低質量的產品。質量必須被量化，并建立可落地實施的機制，以促進和激勵質量目標的達成。即使質量沒達到要求，也要按時交付產品，這似乎是政治正確的行為， 但這是短視的。從中長期來看，這樣做是自殺。質量必須被放在首位，沒有可商量的余地。Edward Yourdon 建議，當你被要求加快測試、 忽視剩余的少量 bug、在設計或需求達成一致前就開始編碼時，要直接說“不”。

原則 2 質量在每個人眼中都不同

QUALITY IS IN THE EYES OF THE BEHOLDER?

軟件質量沒有唯一的定義。對開發者來說，質量可能是優雅的設 計或優雅的代碼。對在緊張環境中工作的客戶來說，質量可能是響應 時間或高吞吐量。對成本敏感的項目來說，質量可能是低開發成本。對一些客戶來說，質量可能是滿足他們所有已知和未知的需求。這里 的難題是，以上要求可能無法完全兼顧。當優化某人關注的質量時， 可能會影響其他人關注的質量（這就是溫伯格的“政治困境”原則）。項目必須確定各因素的優先級，并清晰地傳達給所有相關方。

原則 4 高質量軟件是可以實現的?

HIGH-QUALITY SOFTWARE IS POSSIBLE?

盡管我們的行業中有一些表現不佳、包含 bug，或者根本無法滿 足客戶需求的軟件系統的例子，但仍然有一些成功的例子。大型軟件 系統可以以非常高的質量構建，但價格昂貴：每行代碼高達 1000 美 元。例如，IBM 為美國宇航局的航天飛機開發的機載飛行軟件，總共 約 300 萬行代碼，源于嚴謹的軟件開發過程，產品發布后每萬行代碼中發現的錯誤少于一個。作為軟件開發人員，應該學習和了解已被驗證、可以極大提高軟件質量的方法。這些方法包括：讓客戶參與（見原則 8）、原型設計 （在全面開發之前驗證需求；見原則 11～13）、保持設計簡單（見原 則 67）、審查代碼（見原則 98）和雇用最優秀的人（見原則 130 和 131）。作為客戶，在追求卓越的同時，要意識到隨之而來的高額成本。

原則 5 不要試圖通過改進軟件實現高質量

DON’T TRY TO RETROFIT QUALITY?

質量無法通過軟件的改進來獲得。這適用于質量的任何定義：可 維護性、可靠性、適應性、可測試性、安全性等。即使我們在開發過 程中十分努力，使軟件具備高質量也是十分不易的。如果我們不努力， 又怎么可能期望獲得高質量呢？這就是絕不能將“一次性原型”轉換 成產品的主要原因（見原則 11）。

原則 7 盡早把產品交給客戶

GIVE PRODUCTS TO CUSTOMERS EARLY?

在需求階段，無論你多么努力地試圖去了解客戶的需求，都不如 給他們一個產品，讓他們使用它，這是確定他們真實需求的最有效方 法。如果遵循傳統的瀑布式開發模型，那么在 99% 的開發資源已經 耗盡之后，才會第一次向客戶交付產品。如此一來，大部分的客戶需 求反饋將發生在資源耗盡之后。和以上方法相反，可在開發過程的早期構建一個快速而粗糙的原 型。將這個原型交付給客戶，收集反饋，然后編寫需求規格說明并進 行正規的開發。使用這種方法，當客戶體驗到產品的第一個版本時， 只消耗了 5%～20% 的開發資源。如果原型包含合適的功能，就可以 更好地理解和把握最有風險的客戶需求，最終產品也就更有可能讓客 戶滿意。這有助于確保將剩余的資源用于開發正確的系統。

原則 9 促使開發者與客戶的目標一致?

ALIGN INCENTIVES FOR DEVELOPER AND CUSTOMER?

項目經常會因為客戶和開發人員的目標不同（或不兼容）而失敗。一個簡單的案例是，客戶希望在特定日期前獲得特性 1、2、3，而開 發人員希望最大化營收或利潤。為了最大化營收，開發人員可能會嘗 試完整地開發這三個特性，即使會導致項目延期。與此同時，客戶可 能寧愿放棄其中一個特性的一部分功能，只要能按時交付其他特性。為使雙方的目標達成一致，有如下方法：（1） 按優先級對需求排序（見原則 50），以便開發人員了解它 們的相對重要性。（2） 根據需求的優先級獎勵開發人員（例如，所有高優先級的 需求必須完成；每完成一個中優先級的需求，開發人員可 獲得一些額外的小獎勵；每完成一個低優先級的需求，可 獲得的獎勵非常小）。（3） 對逾期交付實行嚴厲的處罰。

原則 13 要快速地開發一次性原型?

BUILD THROWAWAY PROTOTYPES QUICKLY?

如果你已經決定開發一次性原型，那么就要用最快的方式。不用擔心質量。可使用“一頁紙”的需求規格說明。不用擔心設計或編碼中的文檔。可以使用任何工具。可以使用任何編程語言，只要能夠方 便程序的快速開發。不用擔心編程語言的可維護性。

原則 15 看到越多，需要越多?

THE MORE SEEN, THE MORE NEEDED?

在軟件行業，一次次見證了：提供給用戶的功能（或性能）越多， 用戶想要的功能（或性能）就越多。當然，這與原則 7（盡早把產品 交給客戶）、原則 14（漸進地擴展系統）、原則 185（軟件會持續變化）?以及原則 201（系統的存在促進了演變）互相支持。但更重要的是， 你必須為不可避免的情況做好準備。在管理和工程處理流程的每個方 面都應該做好準備，一旦用戶看到產品，他們就會想要更多的東西。這意味著，所產生的每個文檔都應該以有利于更改的方式進行存 儲和組織。這意味著，配置管理流程（見原則 174）必須在距離交付很長時間之前就就位。這也意味著，在軟件部署后不久，你就應該準備好，以應對用戶口頭或書面請求的沖擊。這還意味著，你選擇的設計方案應使容量、輸入速率和功能都很容易變更。

原則 17 只要可能，購買而非開發

IF POSSIBLE, BUY INSTEAD OF BUILD?

要降低不斷上漲的軟件開發成本和風險，最有效的方法就是，購買現成的軟件，而不是自己從頭開發。確實，現成的軟件也許只能解 決 75% 的問題。但考慮一下從頭開發的選擇吧：支付至少 10 倍于購買軟件的費用，且要冒著超出預算 100% 且延期的風險（如果最后能 夠完成！），并且最終發現，它只能滿足 75% 的預期。對一個客戶來說，新的軟件開發項目似乎最初總是令人興奮的。開發團隊也是“樂觀的”，對“最終”解決方案充滿了希望。但幾乎 很少有軟件開發項目能夠順利運行。不斷增加的成本通常會導致需求 被縮減，最終研發出的軟件可以滿足的需求也許跟現成的軟件差不多。作為一個開發者，應該復用盡可能多的軟件。復用是“購買而非開發” 原則在較小范圍內的體現。可參考原則 84。

原則 22 技術優先于工具?

TECHNIQUE BEFORE TOOLS?

一個沒規矩的木匠使用了強大的工具，會變成一個危險的沒規矩 的木匠。一個沒規矩的軟件工程師使用了工具，會變成一個危險的沒 規矩的軟件工程師。在使用工具前，你應該先要“有規矩”（即理解 并遵循適當的軟件開發方法）。當然，你也要了解如何使用工具，但 這和“有規矩”相比是第二位的。我強烈建議，在投資于工具以對某項技術“自動化”之前，先 手工驗證這項技術，并說服自己和管理層：這項技術是可行的。在 大多數情況下，如果一項技術在手工操作時不靈，那么在自動操作 時也不靈。

原則 30 跟風要小心?

FOLLOW THE LEMMINGS WITH CARE?

即使有五千萬人說傻話，那仍然是傻話。?

安那托爾·佛朗士（Anatole France）?

總結

以上是生活随笔為你收集整理的软件研发中的N条原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。