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

團隊開發(fā)規(guī)范文檔信息：文檔名稱團隊開發(fā)規(guī)范描述該文檔具體定義了團隊開發(fā)的角色及職責(zé)、項目開發(fā)流程、開發(fā)過程控制的約定、協(xié)作開發(fā)的約定、代碼版本控制、交流機制等負(fù)責(zé)人佘及仁狀態(tài)最終版文檔變更歷史：時間修改人章節(jié)描述2023-2-15佘及仁所有章節(jié)創(chuàng)建文檔初稿2023-5-8佘及仁REF_Ref51381361\h代碼管理添加簽入（Checkin）報告模板文檔途徑：$/BlueHill/HR/Documents/審核結(jié)果：審核人意見署名檔佘及仁通過佘及仁目錄1 團隊組成 41.1 產(chǎn)品管理 41.2 項目管理 51.3 開發(fā) 51.4 測試 61.5 用戶教育 71.6 發(fā)布管理 71.7 角色共享 82 開發(fā)流程 92.1 達成共識 102.2 完畢項目計劃 102.3 完畢功能 112.4 穩(wěn)定與發(fā)布 113 代碼管理 113.1 代碼規(guī)范 113.2 版本管理 11(1) 概述 11(2) 代碼管理 12團隊組成整個團隊由六種角色組成，分別為產(chǎn)品管理（ProductManagement）項目管理（ProgramManagement）開發(fā)人員（Development）測試人員（Test）用戶教育人員（UserEducation）發(fā)布管理（ReleaseManagement）各角色在團隊的地位相稱，各司其職。各個角色的具體目的、職能以及責(zé)任在以下的小節(jié)中進行詳述。產(chǎn)品管理目的滿足客戶需求。產(chǎn)品管理的目的就是滿足客戶需求。一個成功的項目必須要可以滿足客戶和用戶的規(guī)定。即使項目達成了預(yù)算和時間的目的，只要未能滿足客戶需求，那這就是一個失敗的項目。一方面必須認(rèn)清和理解客戶。有時，使用方和投資方的目的需求并不完全相同，因此就需要清楚地區(qū)別和分析所有的需求。 職能市場推動市場和公關(guān)，以對目的客戶發(fā)生效用突出產(chǎn)品與其他競爭對手的區(qū)別性，以利于競爭分發(fā)解決方案，以便用戶可以容易地獲得為用戶提供支持，以使其無論在購買還是使用過程中都留下正面的印象業(yè)務(wù)價值定義并維護項目的業(yè)務(wù)對的性定義并衡量業(yè)務(wù)價值的實現(xiàn)和評價發(fā)展客戶推動項目和解決方案的遠(yuǎn)景目的負(fù)責(zé)客戶盼望值和溝通產(chǎn)品計劃收集、分析客戶和業(yè)務(wù)需求，并區(qū)分其優(yōu)先級執(zhí)行市場調(diào)查、市場開拓和競爭對手分析擬定業(yè)務(wù)和成功的標(biāo)準(zhǔn)辨認(rèn)多目的的發(fā)布計劃項目管理目的在項目的約束條件下完畢解決方案。整個團隊的一個重要目的就是在項目的約束條件下完畢項目。項目的約束條件涉及預(yù)算和進度等。大部分項目會根據(jù)時間和資金的使用來衡量項目的結(jié)果。為了實現(xiàn)這個目的，項目管理負(fù)責(zé)并推動進度表、功能集和預(yù)算資金。他必須保證可以在對的的時間發(fā)布對的的項目或產(chǎn)品，保證對的理解了項目投資方的盼望，并自始至終貫穿于項目執(zhí)行過程中。職能項目管理跟蹤和管理預(yù)算資金管理主進度表推動風(fēng)險管理流程加強團隊溝通和協(xié)調(diào)跟蹤進度和報告項目狀態(tài)管理資源分派解決方案構(gòu)建推動整體項目設(shè)計負(fù)責(zé)功能規(guī)范負(fù)責(zé)解決方案范圍和重要決定流程控制推動流程質(zhì)量控制定義并推薦可改善處管理服務(wù) 實現(xiàn)項目的管理流程并提供支持提供管理服務(wù)以保證高效的團隊運作開發(fā)目的按照功能規(guī)范說明進行開發(fā)。功能規(guī)范說明具體描述了整個團隊將要提供應(yīng)客戶的交付物。對整個團隊來說，應(yīng)當(dāng)盡也許精確地按照功能規(guī)范說明來實現(xiàn)整個項目，由于功能規(guī)范說明可以當(dāng)作是整個團隊和客戶之間所達成的共識。開發(fā)人員必須按照客戶需求和功能規(guī)范說明來構(gòu)建整個解決方案。同時，開發(fā)人員還需要為整個團隊提供技術(shù)方面的征詢，這樣在設(shè)計和技術(shù)選擇時可以盡量減少開發(fā)風(fēng)險。開發(fā)人員提供較低層次的功能設(shè)計，并預(yù)估完畢設(shè)計所需的時間。職能技術(shù)征詢?yōu)閳F隊提供技術(shù)征詢服務(wù)評估并驗證所用技術(shù)積極參與功能規(guī)范說明的創(chuàng)建和審核定義開發(fā)標(biāo)準(zhǔn)實現(xiàn)架構(gòu)和設(shè)計提供針對解決方案的應(yīng)用程序、數(shù)據(jù)和技術(shù)細(xì)節(jié)，以便將公司架構(gòu)映射到解決方案架構(gòu)的實現(xiàn)上負(fù)責(zé)并實現(xiàn)解決方案的邏輯和物理設(shè)計應(yīng)用程序開發(fā)根據(jù)設(shè)計規(guī)范編寫代碼以實現(xiàn)功能在開發(fā)過程中進行代碼審核，并共享知識和經(jīng)驗在測試人員的幫助下，根據(jù)測試計劃執(zhí)行單元測試架構(gòu)開發(fā) 為自動安裝開發(fā)腳本開發(fā)安裝文檔測試目的在確認(rèn)所有的產(chǎn)品質(zhì)量問題都得到妥善解決后，批準(zhǔn)產(chǎn)品發(fā)布。所有的軟件產(chǎn)品在發(fā)布時都存在著缺陷。最重要的是，在發(fā)布前，必須清楚地結(jié)識和鑒別出這些問題，可以以問題的形式給出解決方法，或者是給出如何繞開該問題的文檔記錄。寧愿對于已知的問題，提供了文檔或解決方法，也不要存在一些未知的問題。由于這些未知的問題，也許會帶來不可預(yù)知的后果。職能計劃測試開發(fā)測試方法和計劃參與設(shè)立質(zhì)量標(biāo)準(zhǔn)開發(fā)測試說明測試開發(fā)并維護自動測試案例、工具和腳本執(zhí)行測試，以擬定產(chǎn)品開發(fā)過程的狀態(tài)負(fù)責(zé)定義構(gòu)造流程測試報告 為團隊提供與產(chǎn)品質(zhì)量相關(guān)的數(shù)據(jù)跟蹤所有缺陷，并保證在發(fā)布前得到妥善解決用戶教育目的提高用戶使用效率。為了使得產(chǎn)品取得成功，必須要增強用戶工作和操作的方式。即使產(chǎn)品具有了豐富的功能或內(nèi)容，但只要對目的用戶的可用性差，那么這還是一個失敗的產(chǎn)品。職能技術(shù)溝通為技術(shù)支持設(shè)計和開發(fā)文檔開發(fā)幫助文檔培訓(xùn)開發(fā)和執(zhí)行學(xué)習(xí)策略可用性收集、分析用戶需求，并區(qū)分優(yōu)先級為解決方案設(shè)計提供反饋和輸入開發(fā)使用場景和用戶案例在團隊中扮演用戶的角色圖像設(shè)計推動用戶界面設(shè)計國際化改善解決方案在國際市場上的質(zhì)量和可用性輔助功能 推動在設(shè)計時加入輔助功能的概念和需求發(fā)布管理目的順利發(fā)布和后期運作。不能忽略順利的發(fā)布過程。假如安裝過程錯誤百出，那么用戶也許認(rèn)為安裝的產(chǎn)品也是同樣的。所以對于整個團隊來說，發(fā)布并不是目的，需要的是一個順利而平滑的發(fā)布過程。必須確認(rèn)在發(fā)布以前，培訓(xùn)、基礎(chǔ)架構(gòu)和技術(shù)支持已經(jīng)所有就緒。職能架構(gòu)公司架構(gòu)計劃協(xié)調(diào)物理環(huán)境的計劃和使用（數(shù)據(jù)中心、實驗室、分公司等）為團隊提供連續(xù)的架構(gòu)管理和標(biāo)準(zhǔn)政策以及手續(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ā)渠道印刷和電子出版物 角色共享盡管團隊組成包含了六種角色，但并不意味著一個團隊至少需要六個成員，也不意味著一個人只能承擔(dān)一種角色，重要的是這六種角色必須在一個團隊中體現(xiàn)。一般情況下，團隊成員經(jīng)常共享角色。在一些較小的團隊中，不同的角色只能進行兼任。角色共享有兩條重要原則：一是開發(fā)組成員不能共享角色。開發(fā)人員是項目的構(gòu)建者，他們不應(yīng)當(dāng)從他們的主任務(wù)中分身。假如對開發(fā)組成員規(guī)定額外的角色，往往會使得他們無法準(zhǔn)時完畢進度規(guī)定。二是不要試圖組合具有一定利益沖突的角色。比如，產(chǎn)品管理和項目管理的利益具有沖突點，所以他們的角色不能組合。產(chǎn)品管理注重滿足客戶需求，而項目管理重要關(guān)心在時間和預(yù)算的限度內(nèi)完畢項目。假如這兩個角色組合在一起，那么在需求發(fā)生變更時，也許會發(fā)生一些情況，諸如沒有足夠地考慮客戶滿意度而忽略該變更，或者是沒考慮對項目的沖擊盲目地接受變更。讓不同的團隊成員擔(dān)任這樣的角色有助于保證每個方面得到相稱的考慮和重視限度。同樣，這也合用于組合開發(fā)人員和測試人員。REF_Ref50448750\h圖1顯示了也許會引起風(fēng)險（N和U）以及也許產(chǎn)生協(xié)作作用（P）的角色共享。圖SEQ圖\*ARABIC1角色共享開發(fā)流程在開發(fā)過程中，采用多里程碑式的過程模型，如REF_Ref50449257\h圖2所示。而其中每一個循環(huán)均包含四個里程碑。圖SEQ圖\*ARABIC2多里程碑模型這四個里程碑組成的循環(huán)放大后如REF_Ref50449573\h圖3所示，稱為“過程模型”。圖SEQ圖\*ARABIC3過程模型達成共識基本完畢需求調(diào)研和分析（產(chǎn)品管理負(fù)責(zé)）擬定大方向和長中短期目的所有角色都參與討論并真正認(rèn)同結(jié)論產(chǎn)生的文檔常見用戶情景：覆蓋80%以上功能前景：言簡意賅地說明大方向，并有激勵團隊的作用完畢項目計劃編寫具體的功能規(guī)范（項目管理負(fù)責(zé)）在編程前想清楚所有功能流程，并引導(dǎo)用戶明確需求所有角色都參與審閱功能規(guī)范制訂開發(fā)計劃和進度表（開發(fā)團隊）制訂測試計劃和進度表（測試團隊）分派資源（人力和預(yù)算）形成項目綜合計劃和綜合進度表完畢功能開發(fā)人員分別完畢自己的功能使用版本控制工具對每一項可測試的功能進行測試，無需等待通過測試用例，對功能進行完整和反復(fù)的檢查記錄所有程序問題實現(xiàn)解決缺陷的自動流程按照綜合進度表不斷檢查進度穩(wěn)定與發(fā)布測試組全面地測試功能，涉及性能和穩(wěn)定性開發(fā)組全力配合解決缺陷監(jiān)測質(zhì)量情況預(yù)測發(fā)布日期專家會診機制決定缺陷的優(yōu)先度決定哪些缺陷可以在下個里程碑或版本中解決決定由誰解決某個缺陷代碼管理代碼規(guī)范請參看相應(yīng)的代碼規(guī)范文檔。版本管理概述版本控制有如下好處：可以獲得連續(xù)的受版本控制的項目，并保存不同版本的區(qū)別以作比較能獲得版本控制工具中保存的任何版本可以把犯錯或誤操作的最新版的項目恢復(fù)到對的的歷史版本獲得歷史版本的具體信息在開發(fā)過程中，使用VisualSourceSafe6.0進行版本控制。它可以防止用戶文獻意外丟失，并能對以前版本跟蹤；對源文獻進行分支(branch)、共享(share)、合并(merge)操作，同時對整個項目進行版本控制。VisualSourceSafe6.0的具體使用方法，請參看VSS使用手冊。代碼管理MicrosoftVisualSourceSafe是將文獻保存在網(wǎng)絡(luò)上的一個中央數(shù)據(jù)庫中，而不是保存在一個普通的文獻夾下。當(dāng)通過VisualSourceSafe觀看時，這個數(shù)據(jù)庫看上去涉及了以項目層次樹方式組織的所有文獻和歷史記錄。當(dāng)獲得了一個文獻時，VisualSourceSafe會在它的數(shù)據(jù)庫中將該文獻標(biāo)記為已被你簽出（Checkout），而后允許你在你的機器上對該文獻進行修改。當(dāng)你將文獻簽入（Checkin）時，VisualSourceSafe會更新它的數(shù)據(jù)庫并把你機器上的該文獻的訪問權(quán)限改回為只讀。針對每一個改動，VisualSourceSafe數(shù)據(jù)庫都會記錄和跟蹤項目信息。每當(dāng)從項目中添加了一個文獻，修改了一個文獻或者共享、移動、刪除了一個文獻，VisualSourceSafe都會同時共享文獻和項目的歷史記錄。在開發(fā)之前先從VSS服務(wù)器上獲得最新版本的源代碼，對代碼做修改之前先要簽出（Checkout），在代碼修改完畢之后簽入（Checkin）之前需要完畢一系列的如下環(huán)節(jié)：從服務(wù)器上獲得最新的源代碼（獲得最新版本，GetLatestVersion）

必須從服務(wù)器上獲取整個項目的所有的源代碼到本地，對于自己已經(jīng)簽出（Checkout）的文獻，VSS會提醒是覆蓋、不覆蓋、還是歸并。必須選擇歸并（Merge）。重新編譯本地的所有源代碼（RebuildAll）

允許簽入（Checkin）到服務(wù)器的源代碼的最低規(guī)定就是可以通過編譯，否則是不允許簽入（Checkin）的，同時最佳可以去掉編譯警告。代碼審查（CodeReview）

在VSS中對簽出（Checkout）的文獻選擇版本比較（ShowDifference），向自己的同事解釋本次對源文獻做的修改。同事幫助其確認(rèn)是否的確解決了需要解決的問題、是如何解決的，以及算法是否還可以優(yōu)化、代碼是否符合編程規(guī)范、是否尚有潛在的錯誤。簽入（Checkin）

完畢了代碼審查之后可以簽入（Checkin）源代碼。假如代碼審查的時間過長，則還需要反復(fù)做一次以獲得最新的源代碼和重新編譯，來保證這段時間內(nèi)別的同事所做的操作不會與自己做的操作發(fā)生沖突。發(fā)簽入（Checkin）報告

簽入（Checkin）之后需要給整個開發(fā)團隊發(fā)一個報告，為的是讓別的同事知道現(xiàn)在項目的進度。報告中必須注明：本次簽入（Checkin）的目的、和自己一起做代碼審查的同事的名字、