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