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

微軟軟件研發(fā)方法論及軟件開(kāi)發(fā)平臺(tái)的構(gòu)建微軟軟件研發(fā)方法論及軟件開(kāi)發(fā)平臺(tái)的構(gòu)建DEV200微軟軟件研發(fā)方法論及軟件開(kāi)發(fā)平臺(tái)的構(gòu)建DEV200議題微軟研發(fā)簡(jiǎn)介和研發(fā)系統(tǒng)觀開(kāi)發(fā)人員配置開(kāi)發(fā)流程中的重要階段和實(shí)踐開(kāi)發(fā)工具的演化用VSTS/TFS構(gòu)建軟件開(kāi)發(fā)平臺(tái)來(lái)加強(qiáng)管理、提高效率議題微軟研發(fā)簡(jiǎn)介和研發(fā)系統(tǒng)觀微軟對(duì)創(chuàng)新的投入從未間斷微軟研發(fā)中心55個(gè)研究領(lǐng)域產(chǎn)品開(kāi)發(fā)/技術(shù)孵化/基礎(chǔ)研究微軟成功的核心研究中心開(kāi)發(fā)中心微軟對(duì)創(chuàng)新的投入從未間斷微軟研發(fā)中心研究中心開(kāi)發(fā)中心?2009MicrosoftEcosystemDevelopmentResearchIncubationMadeINChina(Deployment)MadeFORChina(Production)MadeBYChina(Ownership)MadeWITHChina(Impact)微軟在美國(guó)以外投資最大、職能最完備、機(jī)構(gòu)設(shè)置最全的創(chuàng)新基地五大研發(fā)方向：移動(dòng)通訊和嵌入式系統(tǒng)、互聯(lián)網(wǎng)技術(shù)產(chǎn)品和服務(wù)、數(shù)字娛樂(lè)、服務(wù)器與開(kāi)發(fā)工具和新興市場(chǎng)微軟中國(guó)研發(fā)集團(tuán)?2009MicrosoftEcosystemDevel微軟開(kāi)發(fā)面對(duì)的挑戰(zhàn)了解客戶的需求多樣化的客戶群未來(lái)以及潛在需求的開(kāi)發(fā)怎樣開(kāi)發(fā)多種產(chǎn)品為客戶提供長(zhǎng)期的價(jià)值

很多大團(tuán)隊(duì)怎樣一起共同研發(fā)復(fù)雜的產(chǎn)品雇用優(yōu)秀的工程師并讓他們很快進(jìn)入狀態(tài)與全世界不同地區(qū)的同事做分布式的協(xié)同開(kāi)發(fā)微軟開(kāi)發(fā)面對(duì)的挑戰(zhàn)了解客戶的需求微軟并沒(méi)有硬性的開(kāi)發(fā)規(guī)定微軟有許多不同的產(chǎn)品類型和周期在線產(chǎn)品：每周或每日病毒預(yù)防，重要補(bǔ)丁等等：每月重要的產(chǎn)品：每年Office：兩到三年其它不同周期：操作系統(tǒng)，數(shù)據(jù)庫(kù)…但是，都用同樣的理念！微軟并沒(méi)有硬性的開(kāi)發(fā)規(guī)定微軟有許多不同的產(chǎn)品類型和周期研發(fā)系統(tǒng)觀人員流程工具研發(fā)系統(tǒng)觀人員流程工具功能團(tuán)隊(duì)的核心項(xiàng)目管理項(xiàng)目經(jīng)理調(diào)查客戶需求、了解競(jìng)爭(zhēng)對(duì)手并發(fā)展出相關(guān)軟件需求開(kāi)發(fā)軟件開(kāi)發(fā)人員編寫符合需求的程序測(cè)試軟件測(cè)試人員確保產(chǎn)品性能符合需求功能團(tuán)隊(duì)的核心項(xiàng)目管理項(xiàng)目經(jīng)理調(diào)查客戶需求、了解競(jìng)爭(zhēng)對(duì)手并發(fā)多重專業(yè)的有序分工開(kāi)發(fā)測(cè)試項(xiàng)目管理IT運(yùn)行產(chǎn)品計(jì)劃可用性設(shè)計(jì)創(chuàng)意內(nèi)容基礎(chǔ)研究工程管理專業(yè)開(kāi)發(fā)測(cè)試項(xiàng)目管理

IT運(yùn)行產(chǎn)品計(jì)劃創(chuàng)意可用性基礎(chǔ)研究?jī)?nèi)容工程管理多重專業(yè)的有序分工開(kāi)發(fā)測(cè)試項(xiàng)目管理IT運(yùn)行產(chǎn)品計(jì)劃可用性設(shè)組織結(jié)構(gòu)–用某開(kāi)發(fā)團(tuán)隊(duì)為例在微軟，產(chǎn)品是由產(chǎn)品組“ProductUnits”來(lái)開(kāi)發(fā)的，由ProductUnitManager來(lái)負(fù)責(zé)GroupProgramManager,DevManager,TestManager各負(fù)責(zé)一類職責(zé)并向ProductUnitManager匯報(bào)項(xiàng)目管理(ProgramManagement)負(fù)責(zé)產(chǎn)品功能集和功能定義七位項(xiàng)目管理經(jīng)理最終向GroupProgramManager匯報(bào)開(kāi)發(fā)(Development)負(fù)責(zé)產(chǎn)品的實(shí)現(xiàn)和架構(gòu)十五位軟件開(kāi)發(fā)工程師最終向DevManager匯報(bào)測(cè)試(Testing)負(fù)責(zé)產(chǎn)品的質(zhì)量保證二十八位軟件開(kāi)發(fā)測(cè)試工程師最終向TestManager匯報(bào)組織結(jié)構(gòu)–用某開(kāi)發(fā)團(tuán)隊(duì)為例在微軟，產(chǎn)品是由產(chǎn)品組“Prod開(kāi)發(fā)流程:產(chǎn)品生命周期管理產(chǎn)品年度策略總結(jié)價(jià)值分析價(jià)值分析價(jià)值分析多次發(fā)布策略服務(wù)開(kāi)發(fā)定義項(xiàng)目服務(wù)上市測(cè)試版進(jìn)度表工程系統(tǒng)版本目標(biāo)功能計(jì)劃里程碑優(yōu)化選擇里程碑里程碑功能重復(fù)設(shè)計(jì)文件功能描述測(cè)試描述測(cè)試代碼產(chǎn)品代碼質(zhì)量檢驗(yàn)功能團(tuán)隊(duì)會(huì)用Agile方法開(kāi)發(fā)流程:產(chǎn)品生命周期管理產(chǎn)品年度策略價(jià)值分析價(jià)值分析價(jià)值時(shí)間計(jì)劃里程碑=產(chǎn)品周期進(jìn)展的單元常見(jiàn)的里程碑計(jì)劃:M0,M1,M2,…,Beta1,Beta2,RTM有利于對(duì)當(dāng)前進(jìn)展和所剩工作的評(píng)估在里程碑計(jì)劃中功能分優(yōu)先級(jí)當(dāng)質(zhì)量達(dá)到里程碑終結(jié)標(biāo)準(zhǔn)“exitcriteria”，里程碑才算完成?2009Microsoft時(shí)間計(jì)劃里程碑=產(chǎn)品周期進(jìn)展的單元?2009Micr主要的功能里程碑事件里程碑事件定義SpecComplete規(guī)格完成日里程碑功能設(shè)計(jì)規(guī)格應(yīng)寫好并審核完的日期FeatureCoding寫功能代碼功能里程碑通常

用8-9周長(zhǎng)短來(lái)寫代碼CodeComplete(CC)代碼完成日所有里程碑計(jì)劃的功能都應(yīng)完成的日期TestPlanComplete測(cè)試計(jì)劃完成日里程碑功能測(cè)試計(jì)劃應(yīng)寫好并審核完的日期ZeroBugBounce(ZBB)零漏洞震蕩本里程碑大于48小時(shí)的漏洞數(shù)量=

0ZBBTestPass(ZBBTP)ZBB全測(cè)試所有功能測(cè)試都在當(dāng)前構(gòu)建（build）上運(yùn)行一遍ZeroResolvedBugs(ZRB)零解決漏洞里程碑內(nèi)解決的并等待驗(yàn)證的漏洞數(shù)量=0TestSign-Off測(cè)試驗(yàn)收對(duì)里程碑構(gòu)建（build）做最后的驗(yàn)證和媒介驗(yàn)收?2009Microsoft主要的功能里程碑事件里程碑事件定義SpecComplete設(shè)計(jì)規(guī)格沒(méi)有設(shè)計(jì)就不要寫產(chǎn)品代碼即使是一個(gè)人的項(xiàng)目也要遵守這個(gè)好規(guī)則對(duì)團(tuán)隊(duì)項(xiàng)目來(lái)說(shuō)則是必須的功能集是由微軟ProgramManagers來(lái)負(fù)責(zé)的負(fù)責(zé)寫每個(gè)功能的設(shè)計(jì)規(guī)格,開(kāi)發(fā)和測(cè)試給反饋一個(gè)好設(shè)計(jì)規(guī)格有如下特點(diǎn):清楚地說(shuō)明功能的目標(biāo)和非目標(biāo)清楚地說(shuō)明客戶和合作伙伴怎樣來(lái)用這個(gè)功能準(zhǔn)確地說(shuō)明功能的對(duì)象模式和架構(gòu)設(shè)計(jì)足夠清楚地讓分開(kāi)的開(kāi)發(fā)、測(cè)試、文檔、本地化團(tuán)隊(duì)一起來(lái)完成設(shè)計(jì)規(guī)格沒(méi)有設(shè)計(jì)就不要寫產(chǎn)品代碼編寫代碼對(duì)源代碼樹的任何改動(dòng)在提交前都要由別的開(kāi)發(fā)工程師來(lái)做代碼審核開(kāi)發(fā)者負(fù)責(zé)對(duì)實(shí)現(xiàn)的功能進(jìn)行提交測(cè)試現(xiàn)趨向于開(kāi)發(fā)者寫的單元測(cè)試達(dá)不到60%block-levelcode-coverage不能提交功能代碼代碼提交前所有的提交測(cè)試都要運(yùn)行，通過(guò)率要100%(2-3小時(shí)的過(guò)程)工具：提交排隊(duì)系統(tǒng)來(lái)運(yùn)行提交測(cè)試提交排隊(duì)系統(tǒng)在每次成功提交后會(huì)給團(tuán)隊(duì)發(fā)“Check-inmail”電郵，信中總結(jié)修改了什么代碼、解決的漏洞、修改的文件

編寫代碼對(duì)源代碼樹的任何改動(dòng)在提交前都要由別的開(kāi)發(fā)工程師來(lái)做UnitTesting單元（unit）測(cè)試UnitTesting單元（unit）測(cè)試源代碼樹的結(jié)構(gòu)MainSourceBranchFeatureBranchTeam1BranchTeam2BranchFeatureBranchFeatureBranchFeatureBranchFeatureBranchFeatureBranch源代碼樹的結(jié)構(gòu)MainSourceBranchFeatu產(chǎn)生每日構(gòu)建DailyBuilds每天都要產(chǎn)生一個(gè)產(chǎn)品的新構(gòu)建“build”中央buildlab為全division(~2800人)做dailybuildBuild流程:Build團(tuán)隊(duì)同步源代碼樹(~半夜)開(kāi)始端到端的build(~4:00am)Build完成(~1:00pm)做BVT(BuildVerificationTests)來(lái)驗(yàn)證build是否正常(~4:00pm)從BFD那里拿到hot-fixes然后re-buildBVT失敗的地方重復(fù)hotfix/BVT周期直到build沒(méi)有問(wèn)題?2009Microsoft產(chǎn)生每日構(gòu)建DailyBuilds每天都要產(chǎn)生一個(gè)產(chǎn)品的新每天都有Build報(bào)告每天都有Build報(bào)告測(cè)試測(cè)試團(tuán)隊(duì)是由開(kāi)發(fā)人員組成的，他們負(fù)責(zé)設(shè)計(jì)測(cè)試計(jì)劃、寫自動(dòng)測(cè)試、建立測(cè)試基礎(chǔ)設(shè)施著重于提高質(zhì)量、防止退化、能夠快速分析不同的builds和它的變異以及各語(yǔ)言版VS2005測(cè)試狀況：102,000功能測(cè)試用例TestCases505,000功能測(cè)試方案TestScenarios71壓力混和變異測(cè)試測(cè)試實(shí)驗(yàn)室~1000服務(wù)器來(lái)自動(dòng)運(yùn)行這些測(cè)試測(cè)試管理系統(tǒng)儲(chǔ)存并管理測(cè)試計(jì)劃和自動(dòng)測(cè)試運(yùn)行允許用戶很容易地增加、刪除、分析測(cè)試計(jì)劃及用例允許用戶遠(yuǎn)程用再映像方式(re-image)來(lái)配置實(shí)驗(yàn)室里的機(jī)器允許用戶遠(yuǎn)程在一系列實(shí)驗(yàn)室機(jī)器上啟動(dòng)test-run允許用戶遠(yuǎn)程分析測(cè)試運(yùn)行結(jié)果并公布結(jié)果測(cè)試測(cè)試團(tuán)隊(duì)是由開(kāi)發(fā)人員組成的，他們負(fù)責(zé)設(shè)計(jì)測(cè)試計(jì)劃、寫自動(dòng)測(cè)試質(zhì)量保證（QA）的第一步是測(cè)試計(jì)劃自動(dòng)測(cè)試用例的實(shí)現(xiàn)目標(biāo)是在產(chǎn)品周期結(jié)束時(shí)所有測(cè)試代碼覆蓋率>85%總是在尋找“testholes”測(cè)試中找到的缺陷（bug）會(huì)在VSTS/TFS中記錄定期的自動(dòng)測(cè)試運(yùn)行會(huì)捕捉到退化regressions測(cè)試質(zhì)量保證（QA）的第一步是測(cè)試計(jì)劃TestCaseManagement測(cè)試用例管理手動(dòng)和自動(dòng)在一個(gè)系統(tǒng)里TestCaseManagement測(cè)試用例管理CodeCoverage代碼覆蓋率Unit,BVT,Suite,AllCodeCoverage代碼覆蓋率Bug漏洞跟蹤Bugs和work-items放在TeamFoundationServer上功能leads會(huì)“triage”Bugs并給出優(yōu)先級(jí)每天會(huì)有Status郵件發(fā)給全division來(lái)跟蹤bug狀況主要觀察尺度:新進(jìn)來(lái)的bug數(shù)和修掉的數(shù)以及在每個(gè)dev上的bug數(shù)在最后一個(gè)功能里程碑完成后，產(chǎn)品團(tuán)隊(duì)的任務(wù)主要是把bug數(shù)減少到零Bug漏洞跟蹤Bugs和work-items放在TBug查詢Bug查詢Bug詳細(xì)情況Bug詳細(xì)情況產(chǎn)品近尾聲時(shí)的滑翔路徑大項(xiàng)目會(huì)慢慢滑入“glidein”而不是突然結(jié)束產(chǎn)品盡早得到真正用戶的反饋很關(guān)鍵微軟團(tuán)隊(duì)常常在RTM(ReleaseToManufacture)發(fā)放前要有兩個(gè)公開(kāi)betas在進(jìn)入“尾聲”前，“滑翔路徑”中的一些主要步驟1)鎖定功能集，停止增加或改變功能設(shè)計(jì)2)在鎖定設(shè)計(jì)基礎(chǔ)上做全方位的測(cè)試找出所有能找到的bug3)努力達(dá)到零漏洞震蕩zerobugbounce(ZBB)4)用幾周時(shí)間來(lái)吸收回彈的bug數(shù)5)從系統(tǒng)中把不必須修的bug推掉6)進(jìn)入尾聲“end-game”，開(kāi)始把代碼改動(dòng)量減到最小?2009Microsoft產(chǎn)品近尾聲時(shí)的滑翔路徑大項(xiàng)目會(huì)慢慢滑入“glidein”工具的演化單一功能的工具–編輯器、調(diào)試器整合的開(kāi)發(fā)環(huán)境(IDE)

–

VisualStudio

Professional應(yīng)用開(kāi)發(fā)周期管理(ALM)

–

VisualStudioTeamSystemwithTeamFoundationServer?2009Microsoft工具的演化單一功能的工具–編輯器、調(diào)試器?2009M微軟的ALM解決方案PMODevelopmentOperations?2009Microsoft微軟的ALM解決方案PMODevelopmentOperVisualStudioTeamSystem

TeamFoundationServer團(tuán)隊(duì)協(xié)作開(kāi)發(fā)的一個(gè)整合的平臺(tái)團(tuán)隊(duì)Portal–團(tuán)隊(duì)協(xié)作SharePointsite變更管理–提供靈活的需求、變更請(qǐng)求、bugs、問(wèn)題、工作項(xiàng)目的跟蹤系統(tǒng)項(xiàng)目管理–管理項(xiàng)目資源、時(shí)間線、質(zhì)量版本控制–強(qiáng)健的源代碼版本控制系統(tǒng)，包括所有項(xiàng)目的代碼、分支、變更集（changeset）、擱置集（shelveset）報(bào)告–提供中央數(shù)據(jù)倉(cāng)庫(kù)，實(shí)時(shí)項(xiàng)目指標(biāo)和分析團(tuán)隊(duì)Build–為團(tuán)隊(duì)項(xiàng)目創(chuàng)建和管理build類型VisualStudioTeamSystem

Team由工具來(lái)制定的流程在建立新項(xiàng)目時(shí)選擇流程由工具來(lái)制定的流程在建立新項(xiàng)目時(shí)選擇流程工作項(xiàng)的解剖ValuePropositionExperienceFeatureTaskTaskFeatureTaskExperienceFeatureTaskBackoftheboxMarketingfeatureSpecFeatureCrewTask工作項(xiàng)的解剖ValuePropositionExperie每一次提交代碼都可以與工作項(xiàng)關(guān)聯(lián)，使得需求、任務(wù)、Bug和代碼關(guān)聯(lián)版本控制-關(guān)聯(lián)工作項(xiàng)每一次提交代碼都可以與工作項(xiàng)關(guān)聯(lián)，使得需求、任務(wù)、Bug和代構(gòu)建工作流-VSTS/TFS2010EditCodeSubmitgatedcheck-inAutomatedBuildCommitCheck-InY/NReadyforTest構(gòu)建工作流-VSTS/TFS2010EditCode商業(yè)需求記錄并管理商業(yè)需求，提供從頭到尾的可追蹤性商業(yè)需求記錄并管理商業(yè)需求，提供從頭到尾的可追蹤性哪里需要調(diào)整資源?大部分要做的工作在測(cè)試方面，表明資源分配不合適或質(zhì)量有問(wèn)題哪里需要調(diào)整資源?大部分要做的工作在測(cè)試方面，表明資源分配不范圍蠕變“黑事”在迭代中浮現(xiàn)計(jì)劃的工作減少了范圍蠕變“黑事”在迭代中浮現(xiàn)計(jì)劃的工作減少了我們團(tuán)隊(duì)的工作是否有效?測(cè)試率

(通過(guò),沒(méi)結(jié)論,失敗)用顏色區(qū)分代碼覆蓋率,…代碼改動(dòng),…有效的

bugs我們團(tuán)隊(duì)的工作是否有效?測(cè)試率

(通過(guò),沒(méi)結(jié)論,失敗)測(cè)試不足代碼覆蓋率降低通過(guò)的測(cè)試減少?zèng)]結(jié)論的增多代碼改動(dòng)量增加測(cè)試不足代碼覆蓋率降低通過(guò)的測(cè)試減少?zèng)]結(jié)論的增多代碼改動(dòng)量增整個(gè)開(kāi)發(fā)工程系統(tǒng)的性能R&D投入提供給客戶的價(jià)值現(xiàn)有的工程系統(tǒng)更新過(guò)的工程系統(tǒng)創(chuàng)新整個(gè)開(kāi)發(fā)工程系統(tǒng)的性能R&D投入提供給客戶的價(jià)值現(xiàn)有的工參考資源BrianHarry博客:/bharry/VSTSMSDN主頁(yè):/en-us/teamsystem/default.aspxTFSMSDN主頁(yè):/en-us/teamsystem/dd408382.aspxVC++MSDN論壇:/Forums/en-US/category/vsts參考資源BrianHarry博客:http://blo專家問(wèn)答區(qū)(F4)

本課程結(jié)束后，我將在接下來(lái)的70分鐘內(nèi)于4層專家問(wèn)答區(qū)與您交流答疑專家問(wèn)答區(qū)(F4)

本課程結(jié)束后，我將在接下來(lái)的70分鐘內(nèi)微軟軟件研發(fā)方法論及軟件開(kāi)發(fā)平臺(tái)的構(gòu)建疑問(wèn)和解答疑問(wèn)和解答微軟軟件研發(fā)方法論及軟件開(kāi)發(fā)平臺(tái)的構(gòu)建微軟軟件研發(fā)方法論及軟件開(kāi)發(fā)平臺(tái)的構(gòu)建微軟軟件研發(fā)方法論及軟件開(kāi)發(fā)平臺(tái)的構(gòu)建DEV200微軟軟件研發(fā)方法論及軟件開(kāi)發(fā)平臺(tái)的構(gòu)建DEV200議題微軟研發(fā)簡(jiǎn)介和研發(fā)系統(tǒng)觀開(kāi)發(fā)人員配置開(kāi)發(fā)流程中的重要階段和實(shí)踐開(kāi)發(fā)工具的演化用VSTS/TFS構(gòu)建軟件開(kāi)發(fā)平臺(tái)來(lái)加強(qiáng)管理、提高效率議題微軟研發(fā)簡(jiǎn)介和研發(fā)系統(tǒng)觀微軟對(duì)創(chuàng)新的投入從未間斷微軟研發(fā)中心55個(gè)研究領(lǐng)域產(chǎn)品開(kāi)發(fā)/技術(shù)孵化/基礎(chǔ)研究微軟成功的核心研究中心開(kāi)發(fā)中心微軟對(duì)創(chuàng)新的投入從未間斷微軟研發(fā)中心研究中心開(kāi)發(fā)中心?2009MicrosoftEcosystemDevelopmentResearchIncubationMadeINChina(Deployment)MadeFORChina(Production)MadeBYChina(Ownership)MadeWITHChina(Impact)微軟在美國(guó)以外投資最大、職能最完備、機(jī)構(gòu)設(shè)置最全的創(chuàng)新基地五大研發(fā)方向：移動(dòng)通訊和嵌入式系統(tǒng)、互聯(lián)網(wǎng)技術(shù)產(chǎn)品和服務(wù)、數(shù)字娛樂(lè)、服務(wù)器與開(kāi)發(fā)工具和新興市場(chǎng)微軟中國(guó)研發(fā)集團(tuán)?2009MicrosoftEcosystemDevel微軟開(kāi)發(fā)面對(duì)的挑戰(zhàn)了解客戶的需求多樣化的客戶群未來(lái)以及潛在需求的開(kāi)發(fā)怎樣開(kāi)發(fā)多種產(chǎn)品為客戶提供長(zhǎng)期的價(jià)值

很多大團(tuán)隊(duì)怎樣一起共同研發(fā)復(fù)雜的產(chǎn)品雇用優(yōu)秀的工程師并讓他們很快進(jìn)入狀態(tài)與全世界不同地區(qū)的同事做分布式的協(xié)同開(kāi)發(fā)微軟開(kāi)發(fā)面對(duì)的挑戰(zhàn)了解客戶的需求微軟并沒(méi)有硬性的開(kāi)發(fā)規(guī)定微軟有許多不同的產(chǎn)品類型和周期在線產(chǎn)品：每周或每日病毒預(yù)防，重要補(bǔ)丁等等：每月重要的產(chǎn)品：每年Office：兩到三年其它不同周期：操作系統(tǒng)，數(shù)據(jù)庫(kù)…但是，都用同樣的理念！微軟并沒(méi)有硬性的開(kāi)發(fā)規(guī)定微軟有許多不同的產(chǎn)品類型和周期研發(fā)系統(tǒng)觀人員流程工具研發(fā)系統(tǒng)觀人員流程工具功能團(tuán)隊(duì)的核心項(xiàng)目管理項(xiàng)目經(jīng)理調(diào)查客戶需求、了解競(jìng)爭(zhēng)對(duì)手并發(fā)展出相關(guān)軟件需求開(kāi)發(fā)軟件開(kāi)發(fā)人員編寫符合需求的程序測(cè)試軟件測(cè)試人員確保產(chǎn)品性能符合需求功能團(tuán)隊(duì)的核心項(xiàng)目管理項(xiàng)目經(jīng)理調(diào)查客戶需求、了解競(jìng)爭(zhēng)對(duì)手并發(fā)多重專業(yè)的有序分工開(kāi)發(fā)測(cè)試項(xiàng)目管理IT運(yùn)行產(chǎn)品計(jì)劃可用性設(shè)計(jì)創(chuàng)意內(nèi)容基礎(chǔ)研究工程管理專業(yè)開(kāi)發(fā)測(cè)試項(xiàng)目管理

IT運(yùn)行產(chǎn)品計(jì)劃創(chuàng)意可用性基礎(chǔ)研究?jī)?nèi)容工程管理多重專業(yè)的有序分工開(kāi)發(fā)測(cè)試項(xiàng)目管理IT運(yùn)行產(chǎn)品計(jì)劃可用性設(shè)組織結(jié)構(gòu)–用某開(kāi)發(fā)團(tuán)隊(duì)為例在微軟，產(chǎn)品是由產(chǎn)品組“ProductUnits”來(lái)開(kāi)發(fā)的，由ProductUnitManager來(lái)負(fù)責(zé)GroupProgramManager,DevManager,TestManager各負(fù)責(zé)一類職責(zé)并向ProductUnitManager匯報(bào)項(xiàng)目管理(ProgramManagement)負(fù)責(zé)產(chǎn)品功能集和功能定義七位項(xiàng)目管理經(jīng)理最終向GroupProgramManager匯報(bào)開(kāi)發(fā)(Development)負(fù)責(zé)產(chǎn)品的實(shí)現(xiàn)和架構(gòu)十五位軟件開(kāi)發(fā)工程師最終向DevManager匯報(bào)測(cè)試(Testing)負(fù)責(zé)產(chǎn)品的質(zhì)量保證二十八位軟件開(kāi)發(fā)測(cè)試工程師最終向TestManager匯報(bào)組織結(jié)構(gòu)–用某開(kāi)發(fā)團(tuán)隊(duì)為例在微軟，產(chǎn)品是由產(chǎn)品組“Prod開(kāi)發(fā)流程:產(chǎn)品生命周期管理產(chǎn)品年度策略總結(jié)價(jià)值分析價(jià)值分析價(jià)值分析多次發(fā)布策略服務(wù)開(kāi)發(fā)定義項(xiàng)目服務(wù)上市測(cè)試版進(jìn)度表工程系統(tǒng)版本目標(biāo)功能計(jì)劃里程碑優(yōu)化選擇里程碑里程碑功能重復(fù)設(shè)計(jì)文件功能描述測(cè)試描述測(cè)試代碼產(chǎn)品代碼質(zhì)量檢驗(yàn)功能團(tuán)隊(duì)會(huì)用Agile方法開(kāi)發(fā)流程:產(chǎn)品生命周期管理產(chǎn)品年度策略價(jià)值分析價(jià)值分析價(jià)值時(shí)間計(jì)劃里程碑=產(chǎn)品周期進(jìn)展的單元常見(jiàn)的里程碑計(jì)劃:M0,M1,M2,…,Beta1,Beta2,RTM有利于對(duì)當(dāng)前進(jìn)展和所剩工作的評(píng)估在里程碑計(jì)劃中功能分優(yōu)先級(jí)當(dāng)質(zhì)量達(dá)到里程碑終結(jié)標(biāo)準(zhǔn)“exitcriteria”，里程碑才算完成?2009Microsoft時(shí)間計(jì)劃里程碑=產(chǎn)品周期進(jìn)展的單元?2009Micr主要的功能里程碑事件里程碑事件定義SpecComplete規(guī)格完成日里程碑功能設(shè)計(jì)規(guī)格應(yīng)寫好并審核完的日期FeatureCoding寫功能代碼功能里程碑通常

用8-9周長(zhǎng)短來(lái)寫代碼CodeComplete(CC)代碼完成日所有里程碑計(jì)劃的功能都應(yīng)完成的日期TestPlanComplete測(cè)試計(jì)劃完成日里程碑功能測(cè)試計(jì)劃應(yīng)寫好并審核完的日期ZeroBugBounce(ZBB)零漏洞震蕩本里程碑大于48小時(shí)的漏洞數(shù)量=

0ZBBTestPass(ZBBTP)ZBB全測(cè)試所有功能測(cè)試都在當(dāng)前構(gòu)建（build）上運(yùn)行一遍ZeroResolvedBugs(ZRB)零解決漏洞里程碑內(nèi)解決的并等待驗(yàn)證的漏洞數(shù)量=0TestSign-Off測(cè)試驗(yàn)收對(duì)里程碑構(gòu)建（build）做最后的驗(yàn)證和媒介驗(yàn)收?2009Microsoft主要的功能里程碑事件里程碑事件定義SpecComplete設(shè)計(jì)規(guī)格沒(méi)有設(shè)計(jì)就不要寫產(chǎn)品代碼即使是一個(gè)人的項(xiàng)目也要遵守這個(gè)好規(guī)則對(duì)團(tuán)隊(duì)項(xiàng)目來(lái)說(shuō)則是必須的功能集是由微軟ProgramManagers來(lái)負(fù)責(zé)的負(fù)責(zé)寫每個(gè)功能的設(shè)計(jì)規(guī)格,開(kāi)發(fā)和測(cè)試給反饋一個(gè)好設(shè)計(jì)規(guī)格有如下特點(diǎn):清楚地說(shuō)明功能的目標(biāo)和非目標(biāo)清楚地說(shuō)明客戶和合作伙伴怎樣來(lái)用這個(gè)功能準(zhǔn)確地說(shuō)明功能的對(duì)象模式和架構(gòu)設(shè)計(jì)足夠清楚地讓分開(kāi)的開(kāi)發(fā)、測(cè)試、文檔、本地化團(tuán)隊(duì)一起來(lái)完成設(shè)計(jì)規(guī)格沒(méi)有設(shè)計(jì)就不要寫產(chǎn)品代碼編寫代碼對(duì)源代碼樹的任何改動(dòng)在提交前都要由別的開(kāi)發(fā)工程師來(lái)做代碼審核開(kāi)發(fā)者負(fù)責(zé)對(duì)實(shí)現(xiàn)的功能進(jìn)行提交測(cè)試現(xiàn)趨向于開(kāi)發(fā)者寫的單元測(cè)試達(dá)不到60%block-levelcode-coverage不能提交功能代碼代碼提交前所有的提交測(cè)試都要運(yùn)行，通過(guò)率要100%(2-3小時(shí)的過(guò)程)工具：提交排隊(duì)系統(tǒng)來(lái)運(yùn)行提交測(cè)試提交排隊(duì)系統(tǒng)在每次成功提交后會(huì)給團(tuán)隊(duì)發(fā)“Check-inmail”電郵，信中總結(jié)修改了什么代碼、解決的漏洞、修改的文件

編寫代碼對(duì)源代碼樹的任何改動(dòng)在提交前都要由別的開(kāi)發(fā)工程師來(lái)做UnitTesting單元（unit）測(cè)試UnitTesting單元（unit）測(cè)試源代碼樹的結(jié)構(gòu)MainSourceBranchFeatureBranchTeam1BranchTeam2BranchFeatureBranchFeatureBranchFeatureBranchFeatureBranchFeatureBranch源代碼樹的結(jié)構(gòu)MainSourceBranchFeatu產(chǎn)生每日構(gòu)建DailyBuilds每天都要產(chǎn)生一個(gè)產(chǎn)品的新構(gòu)建“build”中央buildlab為全division(~2800人)做dailybuildBuild流程:Build團(tuán)隊(duì)同步源代碼樹(~半夜)開(kāi)始端到端的build(~4:00am)Build完成(~1:00pm)做BVT(BuildVerificationTests)來(lái)驗(yàn)證build是否正常(~4:00pm)從BFD那里拿到hot-fixes然后re-buildBVT失敗的地方重復(fù)hotfix/BVT周期直到build沒(méi)有問(wèn)題?2009Microsoft產(chǎn)生每日構(gòu)建DailyBuilds每天都要產(chǎn)生一個(gè)產(chǎn)品的新每天都有Build報(bào)告每天都有Build報(bào)告測(cè)試測(cè)試團(tuán)隊(duì)是由開(kāi)發(fā)人員組成的，他們負(fù)責(zé)設(shè)計(jì)測(cè)試計(jì)劃、寫自動(dòng)測(cè)試、建立測(cè)試基礎(chǔ)設(shè)施著重于提高質(zhì)量、防止退化、能夠快速分析不同的builds和它的變異以及各語(yǔ)言版VS2005測(cè)試狀況：102,000功能測(cè)試用例TestCases505,000功能測(cè)試方案TestScenarios71壓力混和變異測(cè)試測(cè)試實(shí)驗(yàn)室~1000服務(wù)器來(lái)自動(dòng)運(yùn)行這些測(cè)試測(cè)試管理系統(tǒng)儲(chǔ)存并管理測(cè)試計(jì)劃和自動(dòng)測(cè)試運(yùn)行允許用戶很容易地增加、刪除、分析測(cè)試計(jì)劃及用例允許用戶遠(yuǎn)程用再映像方式(re-image)來(lái)配置實(shí)驗(yàn)室里的機(jī)器允許用戶遠(yuǎn)程在一系列實(shí)驗(yàn)室機(jī)器上啟動(dòng)test-run允許用戶遠(yuǎn)程分析測(cè)試運(yùn)行結(jié)果并公布結(jié)果測(cè)試測(cè)試團(tuán)隊(duì)是由開(kāi)發(fā)人員組成的，他們負(fù)責(zé)設(shè)計(jì)測(cè)試計(jì)劃、寫自動(dòng)測(cè)試質(zhì)量保證（QA）的第一步是測(cè)試計(jì)劃自動(dòng)測(cè)試用例的實(shí)現(xiàn)目標(biāo)是在產(chǎn)品周期結(jié)束時(shí)所有測(cè)試代碼覆蓋率>85%總是在尋找“testholes”測(cè)試中找到的缺陷（bug）會(huì)在VSTS/TFS中記錄定期的自動(dòng)測(cè)試運(yùn)行會(huì)捕捉到退化regressions測(cè)試質(zhì)量保證（QA）的第一步是測(cè)試計(jì)劃TestCaseManagement測(cè)試用例管理手動(dòng)和自動(dòng)在一個(gè)系統(tǒng)里TestCaseManagement測(cè)試用例管理CodeCoverage代碼覆蓋率Unit,BVT,Suite,AllCodeCoverage代碼覆蓋率Bug漏洞跟蹤Bugs和work-items放在TeamFoundationServer上功能leads會(huì)“triage”Bugs并給出優(yōu)先級(jí)每天會(huì)有Status郵件發(fā)給全division來(lái)跟蹤bug狀況主要觀察尺度:新進(jìn)來(lái)的bug數(shù)和修掉的數(shù)以及在每個(gè)dev上的bug數(shù)在最后一個(gè)功能里程碑完成后，產(chǎn)品團(tuán)隊(duì)的任務(wù)主要是把bug數(shù)減少到零Bug漏洞跟蹤Bugs和work-items放在TBug查詢Bug查詢Bug詳細(xì)情況Bug詳細(xì)情況產(chǎn)品近尾聲時(shí)的滑翔路徑大項(xiàng)目會(huì)慢慢滑入“glidein”而不是突然結(jié)束產(chǎn)品盡早得到真正用戶的反饋很關(guān)鍵微軟團(tuán)隊(duì)常常在RTM(ReleaseToManufacture)發(fā)放前要有兩個(gè)公開(kāi)betas在進(jìn)入“尾聲”前，“滑翔路徑”中的一些主要步驟1)鎖定功能集，停止增加或改變功能設(shè)計(jì)2)在鎖定設(shè)計(jì)基礎(chǔ)上做全方位的測(cè)試找出所有能找到的bug3)努力達(dá)到零漏洞震蕩zerobugbounce(ZBB)4)用幾周時(shí)間來(lái)吸收回彈的bug數(shù)5)從系統(tǒng)中把不必須修的bug推掉6)進(jìn)入尾聲“end-game”，開(kāi)始把代碼改動(dòng)量減到最小?2009Microsoft產(chǎn)品近尾聲時(shí)的滑翔路徑大項(xiàng)目會(huì)慢慢滑入“glidein”工具的演化單一功能的工具–編輯器、調(diào)試器整合的開(kāi)發(fā)環(huán)境(IDE)

–

VisualStudio

Professional應(yīng)用開(kāi)發(fā)周期管理(ALM)

–

VisualStudioTeamSystemwithTeamFoundationServer?2009Microsoft工具的演化單一功能的工具–編輯器、調(diào)試器?2009M微軟的ALM解決方案PMODevelopmentOperations?2009Microsoft微軟的ALM解決方案PMODevelopmentOperVisualStudioTeamSystem

TeamFoundationServer團(tuán)隊(duì)協(xié)作開(kāi)發(fā)的一個(gè)整合的平臺(tái)團(tuán)隊(duì)Portal–團(tuán)隊(duì)協(xié)作SharePointsite變更管理–提供靈活的需求、變更請(qǐng)求、bugs、問(wèn)題、工作項(xiàng)目的跟蹤系統(tǒng)項(xiàng)目管理–管理項(xiàng)目資源、時(shí)間線、質(zhì)量版本控制–強(qiáng)健的源代碼版本控制系統(tǒng)，包括所有項(xiàng)目的代碼、分支、變更集（changeset）、擱置集（shelveset）