團隊開發(fā)規(guī)范

1、團隊開發(fā)規(guī)范文檔信息：文檔名稱團隊開發(fā)規(guī)范描述該文檔詳細定義了團隊開發(fā)的角色及職責、項目開發(fā)流程、開發(fā)過程控制的約定、協作開發(fā)的約定、代碼版本控制、交流機制等負責人佘及仁狀態(tài)最終版文檔變更歷史：時間修改人章節(jié)描述2003-2-15佘及仁所有章節(jié)創(chuàng)建文檔初稿2003-5-8佘及仁代碼管理添加簽入（Check in）報告模板文檔路徑：$/BlueHill/HR/Documents/審核結果：審核人意見簽名檔佘及仁通過佘及仁目錄1團隊組成41.1產品管理41.2項目管理51.3開發(fā)51.4測試61.5用戶教育71.6發(fā)布管理71.7角色共享82開發(fā)流程92.1達成共識102.2完成項目計劃102.3

2、完成功能112.4穩(wěn)定與發(fā)布113代碼管理113.1代碼規(guī)范113.2版本管理11(1)概述11(2)代碼管理121 團隊組成整個團隊由六種角色組成，分別為 產品管理（Product Management） 項目管理（Program Management） 開發(fā)人員（Development） 測試人員（Test） 用戶教育人員（User Education） 發(fā)布管理（Release Management）各角色在團隊的地位相當，各司其職。各個角色的具體目標、職能以及責任在以下的小節(jié)中進行詳述。1.1 產品管理(1) 目標滿足客戶需求。產品管理的目標就是滿足客戶需求。一個成功的項目必須要能夠滿

3、足客戶和用戶的要求。即使項目達到了預算和時間的目標，只要未能滿足客戶需求，那這就是一個失敗的項目。首先必須認清和理解客戶。有時，使用方和投資方的目標需求并不完全相同，因此就需要清晰地區(qū)別和分析所有的需求。(2) 職能 市場 推動市場和公關，以對目標客戶發(fā)生效用 突出產品與其他競爭對手的區(qū)別性，以利于競爭 分發(fā)解決方案，以便用戶能夠容易地獲得 為用戶提供支持，以使其無論在購買還是使用過程中都留下正面的印象 業(yè)務價值 定義并維護項目的業(yè)務正確性 定義并衡量業(yè)務價值的實現和評價 發(fā)展客戶 推動項目和解決方案的遠景目標 負責客戶期望值和溝通 產品計劃 收集、分析客戶和業(yè)務需求，并區(qū)分其優(yōu)先級 執(zhí)行市場

4、調查、市場開拓和競爭對手分析 確定業(yè)務和成功的標準 識別多目標的發(fā)布計劃1.2 項目管理(1) 目標在項目的約束條件下完成解決方案。整個團隊的一個主要目標就是在項目的約束條件下完成項目。項目的約束條件包括預算和進度等。大部分項目會根據時間和資金的使用來衡量項目的結果。為了實現這個目標，項目管理負責并推動進度表、功能集和預算資金。他必須保證能夠在正確的時間發(fā)布正確的項目或產品，保證正確理解了項目投資方的期望，并自始至終貫穿于項目執(zhí)行過程中。(2) 職能 項目管理 跟蹤和管理預算資金 管理主進度表 推動風險管理流程 加強團隊溝通和協調 跟蹤進度和報告項目狀態(tài) 管理資源分配 解決方案構建 推動整體項

5、目設計 負責功能規(guī)范 負責解決方案范圍和重要決定 流程控制 推動流程質量控制 定義并推薦可改進處 管理服務 實現項目的管理流程并提供支持 提供管理服務以保證高效的團隊運作1.3 開發(fā)(1) 目標按照功能規(guī)范說明進行開發(fā)。功能規(guī)范說明詳細描述了整個團隊將要提供給客戶的交付物。對整個團隊來說，應該盡可能精確地按照功能規(guī)范說明來實現整個項目，因為功能規(guī)范說明可以看成是整個團隊和客戶之間所達成的共識。開發(fā)人員必須按照客戶需求和功能規(guī)范說明來構建整個解決方案。同時，開發(fā)人員還需要為整個團隊提供技術方面的咨詢，這樣在設計和技術選擇時可以盡量減少開發(fā)風險。開發(fā)人員提供較低層次的功能設計，并預估完成設計所需的

6、時間。 (2) 職能 技術咨詢 為團隊提供技術咨詢服務 評估并驗證所用技術 積極參與功能規(guī)范說明的創(chuàng)建和審核 定義開發(fā)標準 實現架構和設計 提供針對解決方案的應用程序、數據和技術細節(jié)，以便將企業(yè)架構映射到解決方案架構的實現上 負責并實現解決方案的邏輯和物理設計 應用程序開發(fā) 根據設計規(guī)范編寫代碼以實現功能 在開發(fā)過程中進行代碼審核，并共享知識和經驗 在測試人員的幫助下，根據測試計劃執(zhí)行單元測試 架構開發(fā) 為自動安裝開發(fā)腳本 開發(fā)安裝文檔1.4 測試(1) 目標在確認所有的產品質量問題都得到妥善處理后，批準產品發(fā)布。所有的軟件產品在發(fā)布時都存在著缺陷。最重要的是，在發(fā)布前，必須清楚地認識和鑒別出

7、這些問題，可以以問題的形式給出解決方法，或者是給出如何繞開該問題的文檔記錄。寧愿對于已知的問題，提供了文檔或解決方法，也不要存在一些未知的問題。因為這些未知的問題，可能會帶來不可預知的后果。(2) 職能 計劃測試 開發(fā)測試方法和計劃 參與設置質量標準 開發(fā)測試說明 測試 開發(fā)并維護自動測試案例、工具和腳本 執(zhí)行測試，以確定產品開發(fā)過程的狀態(tài) 負責定義構造流程 測試報告 為團隊提供與產品質量相關的數據 跟蹤所有缺陷，并保證在發(fā)布前得到妥善處理1.5 用戶教育(1) 目標提高用戶使用效率。為了使得產品取得成功，必須要增強用戶工作和操作的方式。即使產品具備了豐富的功能或內容，但只要對目標用戶的可用性

8、差，那么這還是一個失敗的產品。(2) 職能 技術溝通 為技術支持設計和開發(fā)文檔 開發(fā)幫助文檔 培訓 開發(fā)和執(zhí)行學習策略 可用性 收集、分析用戶需求，并區(qū)分優(yōu)先級 為解決方案設計提供反饋和輸入 開發(fā)使用場景和用戶案例 在團隊中扮演用戶的角色 圖像設計 推動用戶界面設計 國際化 改進解決方案在國際市場上的質量和可用性 輔助功能 推動在設計時加入輔助功能的概念和需求1.6 發(fā)布管理(1) 目標順利發(fā)布和后期運作。不能忽略順利的發(fā)布過程。如果安裝過程錯誤百出，那么用戶可能認為安裝的產品也是同樣的。所以對于整個團隊來說，發(fā)布并不是目標，需要的是一個順利而平滑的發(fā)布過程。必須確認在發(fā)布以前，培訓、基礎架構

9、和技術支持已經全部就緒。(2) 職能 架構 企業(yè)架構計劃 協調物理環(huán)境的計劃和使用（數據中心、實驗室、分公司等） 為團隊提供持續(xù)的架構管理和標準政策以及手續(xù) 管理團隊的硬件和軟件需求 支持 為IT用戶提供聯絡和客戶服務 提供問題解決方案，快速回應用戶并記錄發(fā)生的問題 為開發(fā)和設計提供反饋 開發(fā)故障轉移和恢復流程 運作 賬戶和系統安裝控制，管理用戶賬戶和權限 消息傳遞、數據庫、通信運作、網絡運作 系統管理、批處理操作 防火墻管理、安全管理 應用程序服務 主機集成服務 目錄服務運作 商業(yè)發(fā)布管理 產品注冊碼、注冊驗證流程 許可證管理 打包 管理分發(fā)渠道 印刷和電子出版物1.7 角色共享盡管團隊組成

10、包含了六種角色，但并不意味著一個團隊至少需要六個成員，也不意味著一個人只能承擔一種角色，重要的是這六種角色必須在一個團隊中體現。一般情況下，團隊成員常常共享角色。在一些較小的團隊中，不同的角色只能進行兼任。角色共享有兩條重要原則：一是開發(fā)組成員不能共享角色。開發(fā)人員是項目的構建者，他們不應該從他們的主任務中分身。如果對開發(fā)組成員要求額外的角色，往往會使得他們無法按時完成進度要求。二是不要試圖組合具有一定利益沖突的角色。比如，產品管理和項目管理的利益具有沖突點，所以他們的角色不能組合。產品管理注重滿足客戶需求，而項目管理主要關心在時間和預算的限度內完成項目。如果這兩個角色組合在一起，那么在需求發(fā)

11、生變更時，可能會發(fā)生一些情況，諸如沒有足夠地考慮客戶滿意度而忽略該變更，或者是沒考慮對項目的沖擊盲目地接受變更。讓不同的團隊成員擔任這樣的角色有助于確保每個方面得到相當的考慮和重視程度。同樣，這也適用于組合開發(fā)人員和測試人員。圖 1 顯示了可能會引起風險（N和U）以及可能產生協作作用（P）的角色共享。 圖 1 角色共享2 開發(fā)流程在開發(fā)過程中，采用多里程碑式的過程模型，如圖 2 所示。而其中每一個循環(huán)均包含四個里程碑。圖 2 多里程碑模型這四個里程碑組成的循環(huán)放大后如圖 3所示，稱為“過程模型”。圖 3 過程模型2.1 達成共識 基本完成需求調研和分析（產品管理負責） 確定大方向和長中短期目標

12、 所有角色都參與討論并真正認同結論 產生的文檔 常見用戶情景：覆蓋80%以上功能 前景：言簡意賅地說明大方向，并有激勵團隊的作用2.2 完成項目計劃 編寫詳細的功能規(guī)范（項目管理負責） 在編程前想清楚所有功能流程，并引導用戶明確需求 所有角色都參與審閱功能規(guī)范 制訂開發(fā)計劃和進度表（開發(fā)團隊） 制訂測試計劃和進度表（測試團隊） 分配資源（人力和預算） 形成項目綜合計劃和綜合進度表2.3 完成功能 開發(fā)人員分別完成自己的功能 使用版本控制工具 對每一項可測試的功能進行測試，無需等待 通過測試用例，對功能進行完整和重復的檢驗 記錄所有程序問題 實現解決缺陷的自動流程 按照綜合進度表不斷檢查進度2.

13、4 穩(wěn)定與發(fā)布 測試組全面地測試功能，包括性能和穩(wěn)定性 開發(fā)組全力配合解決缺陷 監(jiān)測質量情況 預測發(fā)布日期 專家會診機制 決定缺陷的優(yōu)先度 決定哪些缺陷可以在下個里程碑或版本中解決 決定由誰解決某個缺陷3 代碼管理3.1 代碼規(guī)范請參看相應的代碼規(guī)范文檔。3.2 版本管理(1) 概述版本控制有如下好處： 可以獲得連續(xù)的受版本控制的項目，并保存不同版本的區(qū)別以作比較 能獲得版本控制工具中保存的任何版本 能夠把出錯或誤操作的最新版的項目恢復到正確的歷史版本 獲得歷史版本的詳細信息在開發(fā)過程中，使用Visual SourceSafe 6.0進行版本控制。它能夠防止用戶文件意外丟失，并能對以前版本跟蹤

14、；對源文件進行分支(branch)、共享(share)、合并(merge)操作，同時對整個項目進行版本控制。Visual SourceSafe 6.0的具體使用方法，請參看VSS使用手冊。(2) 代碼管理Microsoft Visual SourceSafe是將文件保存在網絡上的一個中央數據庫中，而不是保存在一個普通的文件夾下。當通過Visual SourceSafe觀看時，這個數據庫看上去包括了以項目層次樹方式組織的所有文件和歷史記錄。當獲得了一個文件時，Visual SourceSafe會在它的數據庫中將該文件標記為已被你簽出（Check out），而后允許你在你的機器上對該文件進行修改。

15、當你將文件簽入（Check in）時，Visual SourceSafe會更新它的數據庫并把你機器上的該文件的訪問權限改回為只讀。針對每一個改動，Visual SourceSafe數據庫都會記錄和跟蹤項目信息。每當從項目中添加了一個文件，修改了一個文件或者共享、移動、刪除了一個文件，Visual SourceSafe都會同時共享文件和項目的歷史記錄。在開發(fā)之前先從VSS服務器上獲得最新版本的源代碼，對代碼做修改之前先要簽出（Check out），在代碼修改完成之后簽入（Check in）之前需要完成一系列的如下步驟：1) 從服務器上獲得最新的源代碼（獲得最新版本，Get Latest Vers

16、ion）必須從服務器上獲取整個項目的所有的源代碼到本地，對于自己已經簽出（Check out）的文件，VSS會提示是覆蓋、不覆蓋、還是歸并。必須選擇歸并（Merge）。2) 重新編譯本地的所有源代碼（Rebuild All）允許簽入（Check in）到服務器的源代碼的最低要求就是能夠通過編譯，否則是不允許簽入（Check in）的，同時最好能夠去掉編譯警告。3) 代碼審查（Code Review）在VSS中對簽出（Check out）的文件選擇版本比較（Show Difference），向自己的同事解釋本次對源文件做的修改。同事幫助其確認是否的確解決了需要解決的問題、是如何解決的，以及算法是否還可以優(yōu)化、代碼是否符合編程規(guī)范、是否還有潛在的錯誤。4) 簽入（Check in）完成了代碼審查之后可以簽入（Check in）源代碼。如果代碼審查的時間過長，則還需要重復做一次以獲得最新的源代碼和重新編譯，來保證這段時間內別的同事所做的操作不會與自己做的操作發(fā)生沖突。5) 發(fā)簽入（Check in）報告簽入（Check in）之后需要給整個開發(fā)團隊發(fā)一個報告，為的是讓別的同事知道現在項目的進度。報告中必須注明：本次簽入（Check i