能、可用性和產品質量。

5、開發(fā)環(huán)境的保護與基礎設施的維護。

兵家云：天時、地利、人和。沒有一個好的開發(fā)環(huán)境，很難想象開發(fā)人員能夠高效率的工作。開發(fā)環(huán)境必須是相對獨立，又利于交流與溝通的工作室。具體的說，項目組的工作環(huán)境必須拒絕項目無關人員的干擾與破壞，但卻無阻于項目成員，特別是同一小組成員的交流。此外，會議室的數(shù)量非常重要。我在管理一個項目時，竟然常常為尋找會議室而東奔西走，將大量的時間浪費在會議準備上。此外，服務器、客戶機、網絡、打印機、白板、卡片，以及開發(fā)工具和軟件，例如IDE開發(fā)環(huán)境、版本控制工具、Bug管理工具等，都需要在團隊建立之初就要準備好。對于計算機、網絡和相關工具，則必須保證在項目開發(fā)期間的穩(wěn)定性、暢通性。我曾經在項目開發(fā)中，因為網絡中斷、病毒侵襲以及服務器壞掉從而破壞了SVN的版本管理等諸多突發(fā)事件，讓我在本來就緊張的開發(fā)時間里，犧牲了不低于三天的時間，真是讓我抓狂不已！所以說，一個好的網絡管理中心、一個好的配置管理員，在關鍵時刻，可以抵得上半打高效的開發(fā)人員呢。如果你在項目開發(fā)過程中，頻繁遭遇這樣的問題，我的忠告是，趕緊準備換一家公司吧。

6、合理控制需求變更。

需求變更是軟件開發(fā)必然遭遇的暴風雪，也是導致“沒有銀彈”的淵藪。傳統(tǒng)的瀑布開發(fā)模型在項目后期遭遇需求變更時，只能束手無策，但RUP與敏捷方法卻能夠坦然面對需求的變更，Kent Beck甚至在敏捷開發(fā)中提出了擁抱變化，真是足夠勇敢與足夠信心的宣言??！在軟件開發(fā)中，若要應對軟件開發(fā)，一般的做法是合理設計，以求系統(tǒng)與架構具有足夠的可擴展性；其次則是采用迭代的開發(fā)方式，通過定期甚至是短周期地交付可工作的產品，以印證需求與實現(xiàn)是否一致。同時，在項目中通過引入客戶的積極參與，使得項目組與客戶的交流能夠暢通無阻，從而避免因為隔閡而導致需求分析產生的誤差，以及需求變更無法及時提出。此外，利用原型快速開發(fā)方式，可以盡快地交付一個無具體實現(xiàn)的產品框架或原型，以驗證業(yè)務規(guī)則、業(yè)務流程以及客戶對GUI的要求。然而，需求變更絕對不能無休止地進行，這會導致迭代的永無眠日。即使是敏捷開發(fā)，我們仍然要設定客戶委托事項的基本線，一旦超出這一基本線，變更委員會（CCB）或其他擔負這一職責的角色就必須提出異議，與客戶協(xié)商或探討這種變更是否是必須的?？刂菩枨笞兏囊粋€實踐是，獲得客戶對分析出來的功能點的書面確認。雖然在發(fā)生變更時，客戶的意見甚至可以無視這種書面文章，但至少可以在與客戶的談判中搶得先機。根據(jù)Mark Lines所說，通過變更控制的增強還可以降低項目風險。確實如此，在與客戶談判中，我們要學會說出“拒絕”兩個字。當然，在對需求變更做出決定性意見之前，必須分析判斷這樣的變更是否合理，是否必要，或者優(yōu)先級高。一種折中的辦法則是，欣然承諾此次變更，但需要延遲最后期限，或者放在下一次版本迭代之后。

7、預先評估風險。

風險無處不在。Cockburn將軟件開發(fā)形容為攀巖或者穿越沼澤，已經充分說明了軟件開發(fā)過程中的風險。孫子兵法云：夫未戰(zhàn)而廟算勝者，得算多也；未戰(zhàn)而廟算不勝者，得算少也。先預先著失敗的可能，方能夠謹慎地做好各種準備，考慮各種風險以及驅避措施，方能夠最大可能地取得勝利。軟件開發(fā)的風險有很多，其中至關重要的是進度風險、技術風險、需求變更風險、成員變動風險。

軟件是可以度量的嗎？看起來是，因為已經有了很多方法來完成軟件的度量。從控制學的理論來看，你無法控制那些你無法度量的。因而軟件度量對于控制軟件開發(fā)而言，就成為了關鍵。軟件度量甚至因此成為了