和許多其它大公司(如摩托羅拉、IBM等)不同，微軟的產(chǎn)品開發(fā)不用專門的 SCCB 組織。 但這不等于開發(fā)流程不用變更管理, 只是這個管理不是通過變更控制委員會如SCCB來進行的。 7P&scI
sUC8 ##bZ
微軟內(nèi)部使用一個自己開發(fā)的對糾錯和進度跟蹤進行管理的工具叫Raid。 通常我們把它叫Bug Tracking 工具，因為它主要是被測試師用來file bugs, 也就是將測試中找到的差錯紀(jì)錄下來，然后分到開發(fā)工程師那里進行糾錯 (我們把它叫 Activate a bug, assign to dev to fix)。 這個時候bug 的 status 是 “Active”. 開發(fā)工程師將錯改了之后，又將同一個bug 再送回到測試師那里。 這個時候bug 的 status 是 “Resolved”. 測試師重新測試后，證實錯誤的確修正了，這時才將Bug 的status 改成 “Closed”，也就是糾錯的工作算是完成了。 所有的bug fix 都要經(jīng)過這三個過程。 &S0 h9V~Ba
#n=q7F
對產(chǎn)品的設(shè)計的改變，我們也用同樣的工具和流程來管理。 比如我的設(shè)計規(guī)范書一旦審核通過，開發(fā)工作正式開始后，要是我或是別人發(fā)現(xiàn)某個設(shè)計不合理、需要改動， 提出要求的人就用Raid 來file 一個bug。 這個bug 的種類叫作DCR （Design Change Request）, 也就是“設(shè)計改動要求”。 我接到這個bug 后，對設(shè)計規(guī)范書做必要的改動。 改動后召開 “三國會議“ (Triage or Leads Meeting) 對改動進行審核比準(zhǔn)。 一旦審核通過，我就將這 DCR bug 分配到某個開發(fā)工程師頭上，他/她就對編程做必要的修改。 他/她改完后，又將這 bug 分配到某個開發(fā)測試師頭上，他/她再確證這個設(shè)計的改動是完成了。這時他/她將 bug Resolved，再將bug 送回到當(dāng)初提出設(shè)計改動的人那里。 他/她再 Close the Bug。 J?4R:) *U
UnHa^IK
但SCM 的一部分功能由我們專門的Build Lab 來做。 Build Lab or Build Team 是將大家的原碼進行總體的匯編。 所有開發(fā)工程師的原碼都要提交到一個原碼庫里(Team Source Tree)，每天Build Lab進行匯編build. 這個提交過程(Check in) 是有version control 的。 有的團隊用微軟的Visual Source Safe, 絕大多數(shù)團隊用一個內(nèi)部用的工具叫Source Depot。 到發(fā)行前夕，原碼庫(source tree) 是被鎖住的。 不管是誰，要是沒個被 "War Team"("戰(zhàn)爭會議") 批準(zhǔn)的 bug, 不準(zhǔn)、也無法提交改動過的原碼。 所以，到發(fā)行前夕，“三國會議“變成了"戰(zhàn)爭會議": 團隊的所有領(lǐng)導(dǎo)每天聚在一起，對所有的bug 一個個審核，然后決定某個bug 該不該fix. 被批準(zhǔn)了的 bug 才被分到開發(fā)工程師的頭上去改動。 改完、測試完后，用這專門的bug 號碼才可將改動的原碼提交到原碼庫里。 h_ RT%$mD
y44dEb#H o
繞了個大圈子，現(xiàn)在可以回答你的問題： 3(X\r=p^S
ezU`8tX
1） 微軟不用專門的 SCCB 組織和 SCM. 但整套Raid 和Source Deport /VSS 的用法及章程就是一套嚴(yán)謹(jǐn)?shù)?SCCB. [fH +>43_
2） 沒有SCCB, 而是用三國會議(Triage) 來起相同的作用。三國即PM, Dev, QA. Z&j,q hfR
3） 變更的種類有：DCR, Work Item, Code Error, etc.
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://m.vanceur.cn/pmqhd/index.html
