前 言
前段時間一直在寫技術方面的文章，現在想轉轉口味，從軟件開發過程和項目管理的角度來談論軟件開發。本座也知道，從這兩個角度來談論軟件開發對談論者來說是非常冒險的一件事情，它不像技術，對就對錯就錯，有一個客觀的評判標准，別人想噴你也得自己先好好研究等拿到了足夠的論據才能噴，但開發過程和項目管理就不同了，別人僅憑一點點所謂的管理經驗甚至是主觀推斷就能噴得你體無完膚，搖搖欲墜 ~ 因為沒有什么所謂的事實標准與放之四海皆有效的軟件開發過程和項目管理方法。保守估計，100個人中至少有150種想法。本座也深知其中的凶險，因此避重就輕，從基本原理談起，宏觀的角度闡述相關問題，盡量減少中彈的機會。歡迎大家暢所欲言 ^_*
注：本文大量圖片和素材來自《Rapid Development》(Steve McConnell 1996)
1 概 述
時間 -- 成本 -- 質量（或特性）是評價軟件項目成敗的三個關鍵指標，這三個指標之間相互影響和制約，形成了所謂的“項目管理三角形”。要提高質量或增加特性意味着成本和時間的增加，或兩者都增加；要在時間不變的前提下縮減開發成本或成本不變的前提下縮減時間則意味着質量的下降或特性的削減。
圖 1-1 項目管理三角形
上述分析其實只是理論上的“理想平衡”狀態。現實工作中往往出現的情形是：要么時間超過計划，要么成本超過預算，要么質量達不到要求，要么三個指標都達不到預期。
典型例子：
由於客戶的壓力需要盡量縮減開發時間，由於企業間的競爭和盈利壓力需要盡量節約成本，因此需要一個人做兩個人的工作，一個月做兩個月的工作，同時壓縮需求分析、設計、測試、評審和項目會議等活動。可想而知，即使軟件的構建階段能夠按時完成，但做出的軟件質量是難以保證的。更糟糕的還在后面：由於質量的低劣，構建階段結束后對系統進行集成測試時，很多問題就會暴露出來：對某些需求的理解有誤差，導致這部分功能要重新分析、設計、編碼和測試；架構設計缺乏整體思維導致系統不同模塊各自為政，產生大量重復的難以維護的代碼；編碼太倉促導致一大堆的Bug；溝通不暢順導致模塊接口不兼容……從而項目被帶入了修改無限循環地帶，即使勉強上線發布，修改還是一直持續，直至最后，沒有人再敢接近這套代碼，對這個項目談虎色變。
軟件開發項目有其自身規律和原則，只有遵守其原則並付諸相應的實踐才可能使項目健康穩定地前進。本文講述的是軟件開發的基本原則，它是通用的，幾乎適用於所有的軟件開發項目。不同項目可以根據自身特點在原則的指導下定義相應的項目開發實踐。
2 策略和因素
2.1 總體策略
要避免混亂低效的開發，就要求每個人能夠放棄他們自己的一些壞習慣，通過采取以下四種策略實現快速開發：
1、 避免典型錯誤
2、 打好開發基礎
3、 管理風險，避免災難發生
4、 采用面向進度的實踐
圖 2.1-1 快速開發的四跟支柱
典型錯誤：是指一些經常被許多人使用的無效的開發實踐，如：不現實的預期，缺乏計划，功能蔓延和銀彈綜合症等。將在第3章詳細講解。
開發基礎：是指項目開發過程中管理、技術、質量保證等方面行為和活動，如：計划編制，需求管理和技術回顧等。將在第4章詳細講解。
風險管理：是指對有可能影響項目的風險進行評估和控制。將在第5章討論進度計划相關的風險。
面向進度的實踐有以下三類：
-
- 面向速度的實踐：可以提升開發速度，幫助你更快的交付軟件
- 面向進度風險的實踐：可以降低計划風險，幫助你的項目平穩推進
- 面向可視化的實踐：可以提高進程的可視化程度，幫助你掌握項目動態
圖 2.1-2 面向進度的實踐
圖2.1-1所示的前三根柱子為可能的最佳進度提供了最重要的支撐，雖然可能不是最理想的，但卻是最需要的。也就是說，即使不借助於面向進度的實踐方法，也可能實現較優化的項目進度；但是，如果僅僅依賴面向進度的實踐卻不可以支撐可能的最佳進度計划。
圖 2.1-3 僅僅依賴面向進度的實踐不足以支撐最佳進度計划
2.2 軟件開發的四維
每個軟件項目都有四個重要的維：
- 人員：完成任務要么快，要么慢
- 過程：優化人員的工作效率，或者浪費人員的時間
- 產品：以自我完善的形式定義，或者阻礙人員達到最好效果的形式定義
- 技術：促進或者阻礙開發的實現
圖 2.2-1 開發速度的四維
2.2.1 人員
研究數據：
人件極大地影響着生產效率，任何關注提高生產效率的組織首先必須有一套良好的人員激勵、團隊合作、員工選擇及培訓機制。
發揮人員最大潛能，縮短項目周期的方法：
1、 項目成員的選擇
五個原則：
- 用更少更好的人
- 使任務與人員的技能和動機相匹配
- 幫助人員自我實現，而不是強制地把他推到他最有經驗或最需要他的崗位上
- 人員選擇應強調人員之間的互補與協調性
- 盡快排除或替換不稱職的人員
2、 團隊組織結構
人員的組織方式對人員的工作效率有很大影響，調整項目團隊以使之與項目規模、產品特點以及進度目標相匹配。特定的軟件項目也可以從適宜的專門組織中受益。
3、 人員激勵
人員激勵能激發人的動力，從而付出額外的努力工作；它適用於不同組織、不同項目和不同人員。人員激勵是達成快速開發的最具潛力方法。
2.2.2 過程
研究數據：
Hughes Aircraft、Lockheed、Motorola、NASA、Raytheon和Xerox等組織通過對開發過程的改進將產品上市時間縮短了一半，降低成本、減少錯誤為原來的1/3~1/10。
過程是指軟件開發生命周期中定義的一系列工作流程和活動的集合。可以概括為以下三類：
- 基本過程：包括獲取過程、供應過程、開發過程、運作過程、維護過程和管理過程
- 支持過程：包括文檔過程、配置管理過程、質量保證過程、驗證過程、確認過程、聯合評審過程、審計過程以及問題解決過程
- 組織過程：包括基礎設施過程、改進過程以及培訓過程
忽略過程容易造成工作效率低下，工作目的交叉重復，產品質量難以保證等問題；另一方面，如果過程過於嚴格、過於官僚同樣會挫傷人員的積極性，或者由於執行過程的成本過高而影響實際的工作效率。
組織可以對現有的過程進行裁剪和調整，制定出適合特定項目的過程；或者可以為項目從頭開始定義過程。無論是裁剪過程或是定義過程，應該把關注點放在以下幾個方面：
1、 避免返工
軟件項目節省時間一個最直接的方式就是確定過程，避免重復工作。如果在項目最后階段改變需求，就可能不得不重新設計、編碼和測試；如果直到系統測試階段才發現設計有問題，就可能不得不扔掉已經細化的設計和編碼。
2、 質量保證
質量保證有兩個目的：
- 確保交付的產品能夠達到可接受的質量水平
- 在各階段以最少的時間和成本代價查出錯誤
應盡早在錯誤發生的時候就查出來，錯誤在產品中停留的時間越長，清楚錯誤所花費的時間和成本就越多。質量保證是任何開發過程中必不可少的部分。
3、 開發基礎
一系列的軟件工程實踐活動形成了開發基礎，如：分析、設計、構建、集成和測試等。在過程中對開發基礎加以關注，並定義良好的工作規范和任務集合能防止項目失控。
4、 風險管理
與進度相關的風險管理是開發過程必要的組成部分。風險管理雖然不能直接提高開發速度，但它是避免項目災難的有效實踐。
5、 資源目標
資源包括人力資源、環境資源和軟硬件資源等。優化資源的調配有助於提高生產率。
6、 生命周期計划
生命周期計划是基本的管理計划，有助於確定軟件項目要進行的活動集合和資源分配。每種周期模型都有其適用范圍和缺點，為項目選擇適當的生命周期模型能有效提高工作效率或降低項目風險。
圖 2.2.2-1 純瀑布模型
圖 2.2.2-2 瀑布模型的另一種形式——鮭魚生命期模型
圖 2.2.2-3 編碼修正模型（一種不規范的模型）
圖 2.2.2-4 螺旋模型
圖 2.2.2-5 生魚片模型
圖 2.2.2-6 包含子項目的瀑布模型
圖 2.2.2-7 能夠降低風險的瀑布模型（對需求分析和架構設計階段采用螺旋模型）
圖 2.2.2-8 漸進原型模型
圖 2.2.2-9 階段交付模型
圖 2.2.2-10 面向進度模型
圖 2.2.2-11 漸進交付模型
圖 2.2.2-12 面向開發工具的設計模型
7、 面向客戶開發
誰是客戶？
對客戶的理解取決於場合，可能是項目委托人，最終用戶，市場人員或者老板。
現代軟件開發非常關注客戶的需求與期望，開發出合符產品規格的軟件只是完成了一半工作，另一半是幫助客戶配置出產品能夠實現的功能，而實現這些功能所花費的時間通常遠遠多於確定紙面上的產品規格所需要的時間。
將自己站在客戶的角度考慮問題是避免大量返工的最好方法。同時應該建立有效的客戶溝通渠道，合理控制客戶的期望值。
2.2.3 產品
在軟件開發的四維中，最切實的維是產品維。對產品規模和產品特性的關注，意味着巨大的縮短計划進度的機會。削減了產品功能通常就可以縮短產品開發周期。
1、 產品規模
產品規模是對開發進度影響最大的一個因素。構建軟件所需的工作量的增長比產品規模的增長要快得多，並且增長是不成比例的，所以產品規模的縮小將大大提高開發速度。將中等規模的軟件削減一半通常可以使工作負荷削減2/3。
2、 產品特性
產品的一些非功能性需求或額外關注點會影響設計的復雜度和構建的工作量，如對性能、穩定性、可維護性和可擴展性等要求很高的產品比沒有這些特性要求的產品需要更長的開發周期。
2.2.4 技術
從使用低效的工具轉為使用高效的工具是提高開發速度的快捷方法。選擇有效的工具並管理好由此帶來的風險也是提高開發速度的方法。
敬請期待：軟件開發基本原則（二）—— 典型錯誤