微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建

1、微軟軟件研發(fā)方法論及軟件開發(fā)平臺的構(gòu)建DEV200議題微軟研發(fā)簡介和研發(fā)系統(tǒng)觀開發(fā)人員配置開發(fā)流程中的重要階段和實踐開發(fā)工具的演化用VSTS/TFS構(gòu)建軟件開發(fā)平臺來加強管理、提高效率微軟對創(chuàng)新的投入從未間斷微軟研發(fā)中心55個研究領(lǐng)域 產(chǎn)品開發(fā)/技術(shù)孵化/基礎(chǔ)研究微軟成功的核心研究中心開發(fā)中心 2009 MicrosoftEcosystemDevelopmentResearchIncubationMade IN China(Deployment)Made FOR China(Production)Made BY China(Ownership)Made WITH China(Impact)微軟

2、在美國以外投資最大、職能最完備、機構(gòu)設(shè)置最全的創(chuàng)新基地五大研發(fā)方向：移動通訊和嵌入式系統(tǒng)、互聯(lián)網(wǎng)技術(shù)產(chǎn)品和服務(wù)、數(shù)字娛樂、服務(wù)器與開發(fā)工具和新興市場微軟中國研發(fā)集團微軟開發(fā)面對的挑戰(zhàn)了解客戶的需求 多樣化的客戶群未來以及潛在需求的開發(fā) 怎樣開發(fā)多種產(chǎn)品為客戶提供長期的價值 很多大團隊怎樣一起共同研發(fā)復(fù)雜的產(chǎn)品雇用優(yōu)秀的工程師 并讓他們很快進入狀態(tài)與全世界不同地區(qū)的同事做分布式的協(xié)同開發(fā)微軟并沒有硬性的開發(fā)規(guī)定微軟有許多不同的產(chǎn)品類型和周期在線產(chǎn)品：每周或每日病毒預(yù)防，重要補丁等等：每月重要的產(chǎn)品：每年Office： 兩到三年 其它不同周期：操作系統(tǒng)，數(shù)據(jù)庫但是，都用同樣的理念！研發(fā)系統(tǒng)觀人員流

3、程工具功能團隊的核心項目管理項目經(jīng)理調(diào)查客戶需求、了解競爭對手并發(fā)展出相關(guān)軟件需求開發(fā)軟件開發(fā)人員編寫符合需求的程序測試軟件測試人員確保產(chǎn)品性能符合需求多重專業(yè)的有序分工開發(fā)測試項目管理IT 運行產(chǎn)品計劃可用性設(shè)計創(chuàng)意內(nèi)容基礎(chǔ)研究工程管理專業(yè) 開發(fā) 測試 項目管理 IT 運行 產(chǎn)品計劃 創(chuàng)意 可用性 基礎(chǔ)研究 內(nèi)容 工程管理組織結(jié)構(gòu)用某開發(fā)團隊為例在微軟，產(chǎn)品是由產(chǎn)品組 “Product Units” 來開發(fā)的，由Product Unit Manager來負責(zé)Group Program Manager, Dev Manager, Test Manager 各負責(zé)一類職責(zé)并向Product Un

4、it Manager匯報項目管理 (Program Management)負責(zé)產(chǎn)品功能集和功能定義七位項目管理經(jīng)理最終向 Group Program Manager 匯報開發(fā) (Development)負責(zé)產(chǎn)品的實現(xiàn)和架構(gòu)十五位軟件開發(fā)工程師最終向Dev Manager匯報測試 (Testing)負責(zé)產(chǎn)品的質(zhì)量保證二十八位軟件開發(fā)測試工程師最終向Test Manager匯報開發(fā)流程: 產(chǎn)品生命周期管理產(chǎn)品年度策略總結(jié)價值分析價值分析價值分析多次發(fā)布策略服務(wù)開發(fā)定義項目服務(wù)上市測試版進度表工程系統(tǒng)版本目標(biāo)功能計劃里程碑優(yōu)化選擇里程碑里程碑功能重復(fù)設(shè)計文件功能描述測試描述測試代碼產(chǎn)品代碼質(zhì)量檢驗功

5、能團隊會用Agile方法時間計劃里程碑 = 產(chǎn)品周期進展的單元常見的里程碑計劃: M0, M1, M2, , Beta1, Beta2, RTM有利于對當(dāng)前進展和所剩工作的評估在里程碑計劃中功能分優(yōu)先級當(dāng)質(zhì)量達到里程碑終結(jié)標(biāo)準(zhǔn)“exit criteria”，里程碑才算完成 2009 Microsoft主要的功能里程碑事件里程碑事件定義Spec Complete規(guī)格完成日里程碑功能設(shè)計規(guī)格應(yīng)寫好并審核完的日期Feature Coding寫功能代碼功能里程碑通常 用8-9 周長短來寫代碼Code Complete(CC)代碼完成日所有里程碑計劃的功能都應(yīng)完成的日期Test Plan Complet

6、e測試計劃完成日里程碑功能測試計劃應(yīng)寫好并審核完的日期Zero Bug Bounce (ZBB)零漏洞震蕩本里程碑大于48小時的漏洞數(shù)量 = 0ZBB Test Pass (ZBB TP) ZBB全測試所有功能測試都在當(dāng)前構(gòu)建（build）上運行一遍Zero Resolved Bugs (ZRB)零解決漏洞里程碑內(nèi)解決的并等待驗證的漏洞數(shù)量 = 0Test Sign-Off測試驗收對里程碑構(gòu)建（build）做最后的驗證和媒介驗收 2009 Microsoft設(shè)計規(guī)格沒有設(shè)計就不要寫產(chǎn)品代碼即使是一個人的項目也要遵守這個好規(guī)則對團隊項目來說則是必須的功能集是由微軟Program Managers

7、來負責(zé)的負責(zé)寫每個功能的設(shè)計規(guī)格,開發(fā)和測試給反饋一個好設(shè)計規(guī)格有如下特點:清楚地說明功能的目標(biāo)和非目標(biāo)清楚地說明客戶和合作伙伴怎樣來用這個功能準(zhǔn)確地說明功能的對象模式和架構(gòu)設(shè)計足夠清楚地讓分開的開發(fā)、測試、文檔、本地化團隊一起來完成編寫代碼對源代碼樹的任何改動在提交前都要由別的開發(fā)工程師來做代碼審核開發(fā)者負責(zé)對實現(xiàn)的功能進行提交測試現(xiàn)趨向于開發(fā)者寫的單元測試達不到60% block-level code-coverage 不能提交功能代碼代碼提交前所有的提交測試都要運行，通過率要100% (2-3 小時的過程)工具：提交排隊系統(tǒng)來運行提交測試提交排隊系統(tǒng)在每次成功提交后會給團隊發(fā)“Check

8、-in mail” 電郵，信中總結(jié)修改了什么代碼、解決的漏洞、修改的文件 Unit Testing單元（unit）測試源代碼樹的結(jié)構(gòu)Main Source BranchFeature BranchTeam1 BranchTeam2 BranchFeature BranchFeature BranchFeature BranchFeature BranchFeature Branch產(chǎn)生每日構(gòu)建Daily Builds每天都要產(chǎn)生一個產(chǎn)品的新構(gòu)建“build”中央build lab 為全division (2800 人)做daily buildBuild 流程:Build 團隊同步源代碼樹 (半

9、夜)開始端到端的build (4:00am)Build 完成 (1:00pm)做 BVT (Build Verification Tests) 來驗證build 是否正常 (4:00pm)從BFD那里拿到hot-fixes 然后re-build BVT 失敗的地方重復(fù) hotfix/BVT 周期直到build 沒有問題 2009 Microsoft每天都有Build報告測試測試團隊是由開發(fā)人員組成的，他們負責(zé)設(shè)計測試計劃、寫自動測試、建立測試基礎(chǔ)設(shè)施著重于提高質(zhì)量、防止退化、能夠快速分析不同的builds和它的變異以及各語言版VS2005測試狀況：102,000 功能測試用例Test Case

10、s505,000 功能測試方案Test Scenarios71 壓力混和變異測試測試實驗室1000 服務(wù)器來自動運行這些測試測試管理系統(tǒng)儲存并管理測試計劃和自動測試運行允許用戶很容易地增加、刪除、分析測試計劃及用例允許用戶遠程用再映像方式(re-image)來配置實驗室里的機器允許用戶遠程在一系列實驗室機器上啟動test-run允許用戶遠程分析測試運行結(jié)果并公布結(jié)果測試質(zhì)量保證（QA）的第一步是測試計劃自動測試用例的實現(xiàn)目標(biāo)是在產(chǎn)品周期結(jié)束時所有測試代碼覆蓋率 85%總是在尋找“test holes”測試中找到的缺陷（bug）會在VSTS/TFS 中記錄定期的自動測試運行會捕捉到退化regre

11、ssionsTest Case Management測試用例管理手動和自動在一個系統(tǒng)里Code Coverage代碼覆蓋率Unit, BVT, Suite, AllBug 漏洞跟蹤Bugs 和 work-items 放在 Team Foundation Server上功能leads 會“triage” Bugs 并給出優(yōu)先級每天會有Status郵件發(fā)給全division來跟蹤bug狀況主要觀察尺度: 新進來的bug數(shù)和修掉的數(shù)以及在每個dev上的bug數(shù)在最后一個功能里程碑完成后，產(chǎn)品團隊的任務(wù)主要是把bug數(shù)減少到零Bug查詢Bug詳細情況產(chǎn)品近尾聲時的滑翔路徑大項目會慢慢滑入“glide

12、in” 而不是突然結(jié)束產(chǎn)品盡早得到真正用戶的反饋很關(guān)鍵 微軟團隊常常在RTM(Release To Manufacture)發(fā)放前要有兩個公開betas在進入“尾聲”前，“滑翔路徑”中的一些主要步驟1) 鎖定功能集，停止增加或改變功能設(shè)計2) 在鎖定設(shè)計基礎(chǔ)上做全方位的測試找出所有能找到的bug3) 努力達到零漏洞震蕩zero bug bounce (ZBB)4) 用幾周時間來吸收回彈的bug數(shù)5) 從系統(tǒng)中把不必須修的bug推掉6) 進入尾聲“end-game” ，開始把代碼改動量減到最小 2009 Microsoft工具的演化單一功能的工具 編輯器、調(diào)試器整合的開發(fā)環(huán)境(IDE) Visu

13、al Studio Professional應(yīng)用開發(fā)周期管理(ALM) Visual Studio Team System with Team Foundation Server 2009 Microsoft微軟的 ALM 解決方案PMODevelopmentOperations 2009 MicrosoftVisual Studio Team SystemTeam Foundation Server團隊協(xié)作開發(fā)的一個整合的平臺團隊 Portal 團隊協(xié)作SharePoint site變更管理 提供靈活的需求、變更請求、bugs、問題、工作項目的跟蹤系統(tǒng)項目管理 管理項目資源、時間線、質(zhì)量版本

14、控制 強健的源代碼版本控制系統(tǒng)，包括所有項目的代碼、分支、變更集（changeset）、擱置集（shelveset）報告 提供中央數(shù)據(jù)倉庫，實時項目指標(biāo)和分析團隊 Build 為團隊項目創(chuàng)建和管理build類型由工具來制定的流程在建立新項目時選擇流程工作項的解剖每一次提交代碼都可以與工作項關(guān)聯(lián)，使得需求、任務(wù)、Bug和代碼關(guān)聯(lián)版本控制 - 關(guān)聯(lián)工作項構(gòu)建工作流 - VSTS/TFS 2010Edit CodeSubmit gated check-inAutomated BuildCommit Check-InY / NReady for Test商業(yè)需求記錄并管理商業(yè)需求，提供從頭到尾的可追蹤性 哪里需要調(diào)整資源?大部分要做的工作在測試方面，表明資源分配不合適或質(zhì)量有問題范圍蠕變“黑事” 在迭代中浮現(xiàn)計劃的工作減少了我們團隊的工作是否有效