【軟體專案回顧&總結】（原創，MSF為引用）

從上世紀中葉計算機的誕生同時也就產生了program，將近有半個多世紀了，而從1970s的軟體危機起誕生的軟體工程理論的萌芽到90年代的井噴，而現在已經逐漸進入成熟和完善期，而國內的大部分軟體公司卻仍處於對國外90年代末期軟體理論的學習和了解階段。其實軟體工程是一個極具規則化的專案過程管理，這個遊戲涉及中的人必須都按要求遵循，我這裡簡單的介紹下Microsoft的一套MSF (Microsoft Solutions Framework) 開發流程。

不同的註釋風格，不通的開發思路），還有大量的程式冗餘（不同的地方寫著相同功能的方法，還有一些根本用不著的功能——可能是先前需要的後來又不要了吧）；接手的第一個月……是痛苦的一個月，可以這樣形容：頭上的每一根頭髮都有疑問，業務上的每一個邏輯的程式碼實現幾乎都感覺有問題，一個熟悉人員3天的專案，我熟悉了3周，加班開發了一週，提交日本後的結果確是不合格。

[@more@]

我以前在一家日企，是做標籤列印的，這也是我畢業後的第一家公司，而我去的第一個年頭的絕大部分時間是去開發和維護一款進銷存軟體（當然也是和標籤列印有關係的），說了這麼多，我只是想為回顧一下以前專案的開發做個開場，言歸正傳：

由於是一個沿用作坊式的開發模式，雖然公司人員也有50幾口，但真正一個專案的開發通常會控制到10人一下。專案經理PM與客戶做完前期溝通後，發起一個專案【立項】，並提交給合適的1～2個Team Leader，TL簡單評估各自選擇1～3個程式設計師協助開發，此時程式設計師接到通知並開始檢視文件，然後與TL，PM展開詳盡的討論。終端使用者的需求要透過PM，TL，甚至先前開發人員才傳到現在的開發人員手裡，而我當時就是屬於這種接手先輩（沒有bs的意思，先輩，先前開發的前輩）的專案，而我接手時那個專案已經在市場上爬滾了近10年，前後參與修改的人員至少也有15人了吧（不同的註釋風格，不通的開發思路），還有大量的程式冗餘（不同的地方寫著相同功能的方法，還有一些根本用不著的功能——可能是先前需要的後來又不要了吧）；接手的第一個月……是痛苦的一個月，可以這樣形容：頭上的每一根頭髮都有疑問，業務上的每一個邏輯的程式碼實現幾乎都感覺有問題，一個熟悉人員3天的專案，我熟悉了3周，加班開發了一週，提交日本後的結果確是不合格。但就從那次我終於開始熟悉了程式碼，瞭解了業務，之後慢慢的熟悉起來，2個月後一直到我離開那家公司之前，那個軟體中文版相關的改進，版本升級和維護都一直是我來負責。

分析下當中遇到的一些問題：

1、 前期產品需求分析過於簡單，經常是一個簡單的業務流程圖+幾百字的一份郵件，造成立項後需要花費大量的時間與PM溝通，甚至再次與客戶溝通，我們常常戲稱那份郵件為“開發秘籍”，往往TL和開發人員人手一份，討論會上字斟句酌，但仍有些百思不解；

2、 無論是從需求分析上的業務流程或是程式設計上的邏輯流程還是開發流程等“遊戲規則”，或多或少的總有些人不遵守，比如說不同的開發人員對TL和PM指定的規則理解的有歧義，到最後程式碼merge的時候發現問題；

3、 一些聰明而又執著的開發人員偶爾會因為過度開發而導致專案的延誤（雖然警鐘在心，偶確還是偶有再犯，罪過啊！罪過！！阿彌陀佛！！！）；

4、 人員分配的失策，一種是引入新的開發人員，就像我剛接手上面的那個專案時，花了別人N倍的時間，但最終還是導致TL對結果買單（可憐的TL加了2天班終於搞定）；二是引入質量失控人員，開發出的程式碼問題多多；

5、 流程混亂，有時候會出現逆流現象；程式設計文件在開發時嚴重偏離，甚至會發生程式開發結束後才根據程式碼來寫文件（程式設計師往往樂此不已，可憐）；

6、 風險管理，往往在開發或測試的後期，迫於客戶或老闆的要求，追加新的功能，再加上dead-line的關係，導致了end-user面前看到的臭蟲永遠比想象中的要多的多；

總結：

從上世紀中葉計算機的誕生同時也就產生了program，將近有半個多世紀了，而從1970s的軟體危機起誕生的軟體工程理論的萌芽到90年代的井噴，而現在已經逐漸進入成熟和完善期，而國內的大部分軟體公司卻仍處於對國外90年代末期軟體理論的學習和了解階段。其實軟體工程是一個極具規則化的專案過程管理，這個遊戲涉及中的人必須都按要求遵循，我這裡簡單的介紹下Microsoft的一套MSF (Microsoft Solutions Framework) 開發流程。

1、 Chatting（預討論）（專案經理，商務分析員，客戶）進行可行性分析

分析的工具是：CBA (cost benefit analysis) 成本收益分析 ，它的結果是ROI (return of investment) 投入產出比 。一般情況下，使用者提供benefit（收益）分析結果，IT評估專案的cost（成本）。公司目前的立項標準是ROI10比1。我從專案經理那得到的資料是，大致1/3的專案可以繼續往下走。

里程碑：立項。（專案得到使用者部門經理和IT部門經理的批准，專案進入專案列表）

2、 Envisioning. （想象）（專案經理，業務分析人員，使用者，開發組）

專案的範圍界定。描繪專案的範圍和關鍵功能點，使專案有個可視的輪廓。這時候，專案經理會收集各個小組的建議。例如，和開發組溝通大致的開發時間，向伺服器組徵詢伺服器的型別和配置，向DBA徵詢資料庫的型別和配置等等。

里程碑：批准的VSD(vision scope definition)

3、Planning。（專案經理，BA, 開發組，測試組，支援組）

制定詳細的專案計劃。確定專案的三要素“時間”，“資源”和“範圍”。再加上風險管理。

i。對於專案經理來說，最重要是向老闆要resource（資源）。當然還要確定專案開發的確切時間。

ii。對於業務分析人員來說，需要明確詳細的業務需求。這時候會畫出系統流程圖和使用者介面草圖，再加上每一項功能的業務描述等等。這些都包括在SRS(system requirement specification)中。

iii。對於開發組來說，最重要是制定了開發計劃，瓜分用例（把每一個功能點分配給開發人員）。定製每個開發人員的開發進度表，code review計劃。

IV。對於開發組來說，還需要定義風險管理計劃和措施。這裡的風險，特指技術難點。技術難點需要先做prototype，risk太高的需要捨棄一些功能。（FMEA, failure model effect analysis）因為“任何可能出錯的地方都會出錯。”

V。測試組根據SRS定製測試計劃。

VI。專案計劃獲得使用者，專案經理，開發經理和測試經理的同意。

里程碑：批准的SRS(system requirement specification)

4. Developing。（專案經理，開發組，使用者，伺服器組，資料庫管理員）

設計階段：

i、開發組：軟體建模。定義系統的架構（邏輯、物理），域建模，用例分析，對每個用例的序列圖分析，物件建模。重新評估專案的複雜度。在這個階段，可適當調整專案計劃。

ii、伺服器組：安裝測試伺服器，安裝開發相關軟體。如IIS，BIG IP, IBM Message Queue等等。

iii、DBA：安裝配置開發資料庫。配置使用者賬號：一般情況下分為兩個賬號。app帳號為正式環境下執行的受限帳號。admin帳號為可建立資料庫物件的特權帳號。

iv、專案經理：協調各團隊的工作，檢查各項工作進度。

里程碑：批准的設計文件SDS(system design specification)。

編碼階段：把設計轉換成程式碼，根據實際問題適當調整並同步設計，code review和稽核進度。

里程碑：程式碼透過單元測試,程式碼和文件都check in版本管理器。

測試階段：

A、SIT內部測試，根據用例描述測試每一個場景，分析記憶體洩漏，最佳化系統效能，提交資料庫效能execution plan執行計劃給DBA review。對系統進行壓力測試（必要情況下提交到專業的壓力測試組進行測試）。

里程碑：完成內部測試報告和得到DBA的上線批准。

B、UAT（user acceptable testing）使用者測試。使用者根據用例描述測試每一個場景，反饋系統bug和issue。開發人員修正bug並基於issue對系統影響和對業務影響進行判斷，適當的修正系統或記錄業務需求，根據業務優先等級，整合進以後的演進階段。

里程碑：UAT Sign off。使用者簽收當前系統功能。

部署：

專案經理整理文件（Design document, SIT test report, UAT sign off, System downtime approval, server check list, DB checklist. implementation plan. back out plan(data & program)），向change committee（一個專門控制系統更新的委員會）提交新系統上線請求。如果change committee批准請求。

開發組在指定的時間裡向production（生產）計算機部署系統，生成資料庫部署指令碼，提交給DBA。

DBA執行部署指令碼，反饋結果。

5. Stabilizing。（專案經理，開發組，支援組）

系統穩定期。開發組記錄和反饋系統BUG，向支援組移交程式和文件等等。

Bug修正：為了減少對生產的影響，在生產環境下的任何bug修正都需要change committee的批准。Change committee只有週二和週四下午接受修改請求，緊急情況下需要部門經理特別批准。對開發組而言，bug修正是一件非常痛苦的事情，這樣在一定程度上也提高了軟體質量。

里程碑：Support Team Sign off。

角色：User，Project team 專案經理, BA 業務分析人員， Server team 伺服器組, DBA 資料庫管理員, Develop team 開發組, Support team 支援組

話外篇，逆流現象往往發生在作坊公司，軟體工程意識淡薄，軟體詳細設計人員和開發人員重疊過重，解決辦法：軟體設計和開發過程分離，即使軟體開發中發現設計缺陷，也應該將所有與設計相關人員討論，並將結果歸檔後再繼續開發。想起上一篇文章《指數效應》——差之毫釐，失之千里。

2008-9-3 凌晨 完