|
團隊開發規範 |
|
|
文檔信息：
|
|
|
|
文檔名稱 |
團隊開發規範 |
|
描述 |
該文檔詳細定義了團隊開發的角色及職責、項目開發流程、開發過程控制的約定、協作開發的約定、代碼版本控制、交流機制等 |
|
負責人 |
|
|
狀態 |
|
文檔變更歷史：
|
|
|
|
|
|
時間 |
修改人 |
章節 |
描述 |
|
|
|
|
|
|
|
|
|
|
文檔路徑：
|
$/Documents/ |
審覈結果：
|
|
|
|
|
審覈人 |
意見 |
簽名檔 |
|
|
|
|
|
|
|
|
目錄
1 團隊組成
整個團隊由六種角色組成，分別爲
· 產品管理（ Product Management ）
· 項目管理（ Program Management ）
· 開發人員（ Development ）
· 測試人員（ Test ）
· 用戶教育人員（ User Education ）
· 發佈管理（ Release Management ）
各角色在團隊的地位相當，各司其職。各個角色的具體目標、職能以及責任在以下的小節中進行詳述。
1.1 產品管理
(1) 目標
滿足客戶需求。
產品管理的目標就是滿足客戶需求。一個成功的項目必須要能夠滿足客戶和用戶的要求。即使項目達到了預算和時間的目標，只要未能滿足客戶需求，那這就是一個失敗的項目。首先必須認清和理解客戶。有時，使用方和投資方的目標需求並不完全相同，因此就需要清晰地區別和分析所有的需求。
(2) 職能
· 市場
§ 推動市場和公關，以對目標客戶發生效用
§ 突出產品與其他競爭對手的區別性，以利於競爭
§ 分發解決方案，以便用戶能夠容易地獲得
§ 爲用戶提供支持，以使其無論在購買還是使用過程中都留下正面的印象
· 業務價值
§ 定義並維護項目的業務正確性
§ 定義並衡量業務價值的實現和評價
· 發展客戶
§ 推動項目和解決方案的遠景目標
§ 負責客戶期望值和溝通
· 產品計劃
§ 收集、分析客戶和業務需求，並區分其優先級
§ 執行市場調查、市場開拓和競爭對手分析
§ 確定業務和成功的標準
§ 識別多目標的發佈計劃
1.2 項目管理
(1) 目標
在項目的約束條件下完成解決方案。
整個團隊的一個主要目標就是在項目的約束條件下完成項目。項目的約束條件包括預算和進度等。大部分項目會根據時間和資金的使用來衡量項目的結果。爲了實現這個目標，項目管理負責並推動進度表、功能集和預算資金。他必須保證能夠在正確的時間發佈正確的項目或產品，保證正確理解了項目投資方的期望，並自始至終貫穿於項目執行過程中。
(2) 職能
· 項目管理
§ 跟蹤和管理預算資金
§ 管理主進度表
§ 推動風險管理流程
§ 加強團隊溝通和協調
§ 跟蹤進度和報告項目狀態
§ 管理資源分配
· 解決方案構建
§ 推動整體項目設計
§ 負責功能規範
§ 負責解決方案範圍和重要決定
· 流程控制
§ 推動流程質量控制
§ 定義並推薦可改進處
· 管理服務
§ 實現項目的管理流程並提供支持
§ 提供管理服務以保證高效的團隊運作
1.3 開發
(1) 目標
按照功能規範說明進行開發。
功能規範說明詳細描述了整個團隊將要提供給客戶的交付物。對整個團隊來說，應該儘可能精確地按照功能規範說明來實現整個項目，因爲功能規範說明可以看成是整個團隊和客戶之間所達成的共識。開發人員必須按照客戶需求和功能規範說明來構建整個解決方案。同時，開發人員還需要爲整個團隊提供技術方面的諮詢，這樣在設計和技術選擇時可以儘量減少開發風險。開發人員提供較低層次的功能設計，並預估完成設計所需的時間。
(2) 職能
· 技術諮詢
§ 爲團隊提供技術諮詢服務
§ 評估並驗證所用技術
§ 積極參與功能規範說明的創建和審覈
§ 定義開發標準
· 實現架構和設計
§ 提供針對解決方案的應用程序、數據和技術細節，以便將企業架構映射到解決方案架構的實現上
§ 負責並實現解決方案的邏輯和物理設計
· 應用程序開發
§ 根據設計規範編寫代碼以實現功能
§ 在開發過程中進行代碼審覈，並共享知識和經驗
§ 在測試人員的幫助下，根據測試計劃執行單元測試
· 架構開發
§ 爲自動安裝開發腳本
§ 開發安裝文檔
1.4 測試
(1) 目標
在確認所有的產品質量問題都得到妥善處理後，批准產品發佈。
所有的軟件產品在發佈時都存在着缺陷。最重要的是，在發佈前，必須清楚地認識和鑑別出這些問題，可以以問題的形式給出解決方法，或者是給出如何繞開該問題的文檔記錄。寧願對於已知的問題，提供了文檔或解決方法，也不要存在一些未知的問題。因爲這些未知的問題，可能會帶來不可預知的後果。
(2) 職能
· 計劃測試
§ 開發測試方法和計劃
§ 參與設置質量標準
§ 開發測試說明
· 測試
§ 開發並維護自動測試案例、工具和腳本
§ 執行測試，以確定產品開發過程的狀態
§ 負責定義構造流程
· 測試報告
§ 爲團隊提供與產品質量相關的數據
§ 跟蹤所有缺陷，並保證在發佈前得到妥善處理
1.5 用戶教育
(1) 目標
提高用戶使用效率。
爲了使得產品取得成功，必須要增強用戶工作和操作的方式。即使產品具備了豐富的功能或內容，但只要對目標用戶的可用性差，那麼這還是一個失敗的產品。
(2) 職能
· 技術溝通
§ 爲技術支持設計和開發文檔
§ 開發幫助文檔
· 培訓
§ 開發和執行學習策略
· 可用性
§ 收集、分析用戶需求，並區分優先級
§ 爲解決方案設計提供反饋和輸入
§ 開發使用場景和用戶案例
§ 在團隊中扮演用戶的角色
· 圖像設計
§ 推動用戶界面設計
· 國際化
§ 改進解決方案在國際市場上的質量和可用性
· 輔助功能
§ 推動在設計時加入輔助功能的概念和需求
1.6 發佈管理
(1) 目標
順利發佈和後期運作。
不能忽略順利的發佈過程。如果安裝過程錯誤百出，那麼用戶可能認爲安裝的產品也是同樣的。所以對於整個團隊來說，發佈並不是目標，需要的是一個順利而平滑的發佈過程。必須確認在發佈以前，培訓、基礎架構和技術支持已經全部就緒。
(2) 職能
· 架構
§ 企業架構計劃
§ 協調物理環境的計劃和使用（數據中心、實驗室、分公司等）
§ 爲團隊提供持續的架構管理和標準政策以及手續
§ 管理團隊的硬件和軟件需求
· 支持
§ 爲 IT 用戶提供聯絡和客戶服務
§ 提供問題解決方案，快速回應用戶並記錄發生的問題
§ 爲開發和設計提供反饋
§ 開發故障轉移和恢復流程
· 運作
§ 賬戶和系統安裝控制，管理用戶賬戶和權限
§ 消息傳遞、數據庫、通信運作、網絡運作
§ 系統管理、批處理操作
§ 防火牆管理、安全管理
§ 應用程序服務
§ 主機集成服務
§ 目錄服務運作
· 商業發佈管理
§ 產品註冊碼、註冊驗證流程
§ 許可證管理
§ 打包
§ 管理分發渠道
§ 印刷和電子出版物
1.7 角色共享
儘管團隊組成包含了六種角色，但並不意味着一個團隊至少需要六個成員，也不意味着一個人只能承擔一種角色，重要的是這六種角色必須在一個團隊中體現。一般情況下，團隊成員常常共享角色。在一些較小的團隊中，不同的角色只能進行兼任。角色共享有兩條重要原則：
一是開發組成員不能共享角色。開發人員是項目的構建者，他們不應該從他們的主任務中分身。如果對開發組成員要求額外的角色，往往會使得他們無法按時完成進度要求。
二是不要試圖組合具有一定利益衝突的角色。比如，產品管理和項目管理的利益具有衝突點，所以他們的角色不能組合。產品管理注重滿足客戶需求，而項目管理主要關心在時間和預算的限度內完成項目。如果這兩個角色組合在一起，那麼在需求發生變更時，可能會發生一些情況，諸如沒有足夠地考慮客戶滿意度而忽略該變更，或者是沒考慮對項目的衝擊盲目地接受變更。讓不同的團隊成員擔任這樣的角色有助於確保每個方面得到相當的考慮和重視程度。同樣，這也適用於組合開發人員和測試人員。
圖 1 顯示了可能會引起風險（ N 和 U ）以及可能產生協作作用（ P ）的角色共享。
圖 1 角色共享
2 開發流程
在開發過程中，採用多里程碑式的過程模型，如 圖 2 所示。而其中每一個循環均包含四個里程碑。
圖 2 多里程碑模型
這四個里程碑組成的循環放大後如 圖 3 所示，稱爲“過程模型”。
圖 3 過程模型
2.1 達成共識
· 基本完成需求調研和分析（產品管理負責）
· 確定大方向和長中短期目標
· 所有角色都參與討論並真正認同結論
· 產生的文檔
§ 常見用戶情景：覆蓋 80% 以上功能
§ 前景：言簡意賅地說明大方向，並有激勵團隊的作用
2.2 完成項目計劃
· 編寫詳細的功能規範（項目管理負責）
· 在編程前想清楚所有功能流程，並引導用戶明確需求
· 所有角色都參與審閱功能規範
· 制訂開發計劃和進度表（開發團隊）
· 制訂測試計劃和進度表（測試團隊）
· 分配資源（人力和預算）
· 形成項目綜合計劃和綜合進度表
2.3 完成功能
· 開發人員分別完成自己的功能
· 使用版本控制工具
· 對每一項可測試的功能進行測試，無需等待
· 通過測試用例，對功能進行完整和重複的檢驗
· 記錄所有程序問題
· 實現解決缺陷的自動流程
· 按照綜合進度表不斷檢查進度
2.4 穩定與發佈
· 測試組全面地測試功能，包括性能和穩定性
· 開發組全力配合解決缺陷
· 監測質量情況
· 預測發佈日期
· 專家會診機制
§ 決定缺陷的優先度
§ 決定哪些缺陷可以在下個里程碑或版本中解決
§ 決定由誰解決某個缺陷
3 代碼管理
3.1 代碼規範
請參看相應的代碼規範文檔。
3.2 版本管理
(1) 概述
版本控制有如下好處：
· 可以獲得連續的受版本控制的項目，並保存不同版本的區別以作比較
· 能獲得版本控制工具中保存的任何版本
· 能夠把出錯或誤操作的最新版的項目恢復到正確的歷史版本
· 獲得歷史版本的詳細信息
在開發過程中，使用 Visual SourceSafe 6.0 進行版本控制。它能夠防止用戶文件意外丟失，並能對以前版本跟蹤；對源文件進行分支 (branch) 、共享 (share) 、合併 (merge) 操作，同時對整個項目進行版本控制。 Visual SourceSafe 6.0 的具體使用方法，請參看 VSS 使用手冊。
(2) 代碼管理
Microsoft Visual SourceSafe 是將文件保存在網絡上的一箇中央數據庫中，而不是保存在一個普通的文件夾下。當通過 Visual SourceSafe 觀看時，這個數據庫看上去包括了以項目層次樹方式組織的所有文件和歷史記錄。
當獲得了一個文件時， Visual SourceSafe 會在它的數據庫中將該文件標記爲已被你簽出（ Check out ），而後允許你在你的機器上對該文件進行修改。當你將文件簽入（ Check in ）時， Visual SourceSafe 會更新它的數據庫並把你機器上的該文件的訪問權限改回爲只讀。針對每一個改動， Visual SourceSafe 數據庫都會記錄和跟蹤項目信息。每當從項目中添加了一個文件，修改了一個文件或者共享、移動、刪除了一個文件， Visual SourceSafe 都會同時共享文件和項目的歷史記錄。
在開發之前先從 VSS 服務器上獲得最新版本的源代碼，對代碼做修改之前先要簽出（ Check out ），在代碼修改完成之後簽入（ Check in ）之前需要完成一系列的如下步驟：
1)
從服務器上獲得最新的源代碼
（獲得最新版本，
Get Latest Version
）
必須從服務器上獲取整個項目的所有的源代碼到本地
，
對於自己已經簽出
（
Check out
）
的文件
，
VSS
會提示是覆蓋、不覆蓋、還是歸併。必須選擇歸併（
Merge
）。
2)
重新編譯本地的所有源代碼（
Rebuild All
）
允許簽入（
Check in
）到服務器的源代碼的最低要求就是能夠通過編譯，否則是不允許簽入（
Check in
）的，同時最好能夠去掉編譯警告。
3)
代碼審查（
Code Review
）
在
VSS
中對簽出（
Check out
）的文件選擇版本比較（
Show Difference
），向自己的同事解釋本次對源文件做的修改。同事幫助其確認是否的確解決了需要解決的問題、是如何解決的，以及算法是否還可以優化、代碼是否符合編程規範、是否還有潛在的錯誤。
4)
簽入（
Check in
）
完成了代碼審查之後可以簽入（
Check in
）源代碼。如果代碼審查的時間過長，則還需要重複做一次以獲得最新的源代碼和重新編譯，來保證這段時間內別的同事所做的操作不會與自己做的操作發生衝突。
5)
發籤入（
Check in
）報告
簽入（
Check in
）之後需要給整個開發團隊發一個報告，爲的是讓別的同事知道現在項目的進度。報告中必須註明：本次簽入（
Check in
）的目的、和自己一起做代碼審查的同事的名字、代碼審查的具體內容、是否做過單元測試、簽入（
Check in
）的所有文件的列表。格式如下：
|
目的描述： [ 描述該次簽入（ Check in ）的目的 ] 產生的影響： [ 對其他模塊代碼可能的影響 ] 審覈人： [ 幫助審覈的同事姓名 ] 步驟： 是否從 VSS 獲得最新版本（ Get Latest Version ）？ [Y/N ] 是否重新編譯所有源代碼？ [Y/N ] 代碼是否符合編程規範？ [Y/N ] 代碼中是否存在潛在的缺陷可能性？ [Y/N ] 是否有解決問題的更好方法？ [Y/N ] 是否通過了單元測試（ Unit test ）？ [Y/N ] 文件列表： [ 簽入文件的列表 ] |