和许多其它大公司(如摩托罗拉、IBM等)不同，微软的产品开发不用专门的 SCCB 组织。 但这不等于开发流程不用变更管理, 只是这个管理不是通过变更控制委员会如SCCB来进行的。 7P&scI
sUC8 ##bZ
微软内部使用一个自己开发的对纠错和进度跟踪进行管理的工具叫Raid。 通常我们把它叫Bug Tracking 工具，因为它主要是被测试师用来file bugs, 也就是将测试中找到的差错纪录下来，然后分到开发工程师那里进行纠错 (我们把它叫 Activate a bug, assign to dev to fix)。 这个时候bug 的 status 是 “Active”. 开发工程师将错改了之后，又将同一个bug 再送回到测试师那里。 这个时候bug 的 status 是 “Resolved”. 测试师重新测试后，证实错误的确修正了，这时才将Bug 的status 改成 “Closed”，也就是纠错的工作算是完成了。 所有的bug fix 都要经过这三个过程。 &S0 h9V~Ba
#n=q7F
对产品的设计的改变，我们也用同样的工具和流程来管理。 比如我的设计规范书一旦审核通过，开发工作正式开始后，要是我或是别人发现某个设计不合理、需要改动， 提出要求的人就用Raid 来file 一个bug。 这个bug 的种类叫作DCR （Design Change Request）, 也就是“设计改动要求”。 我接到这个bug 后，对设计规范书做必要的改动。 改动后召开 “三国会议“ (Triage or Leads Meeting) 对改动进行审核比准。 一旦审核通过，我就将这 DCR bug 分配到某个开发工程师头上，他/她就对编程做必要的修改。 他/她改完后，又将这 bug 分配到某个开发测试师头上，他/她再确证这个设计的改动是完成了。这时他/她将 bug Resolved，再将bug 送回到当初提出设计改动的人那里。 他/她再 Close the Bug。 J?4R:) *U
UnHa^IK
但SCM 的一部分功能由我们专门的Build Lab 来做。 Build Lab or Build Team 是将大家的原码进行总体的汇编。 所有开发工程师的原码都要提交到一个原码库里(Team Source Tree)，每天Build Lab进行汇编build. 这个提交过程(Check in) 是有version control 的。 有的团队用微软的Visual Source Safe, 绝大多数团队用一个内部用的工具叫Source Depot。 到发行前夕，原码库(source tree) 是被锁住的。 不管是谁，要是没个被 "War Team"("战争会议") 批准的 bug, 不准、也无法提交改动过的原码。 所以，到发行前夕，“三国会议“变成了"战争会议": 团队的所有领导每天聚在一起，对所有的bug 一个个审核，然后决定某个bug 该不该fix. 被批准了的 bug 才被分到开发工程师的头上去改动。 改完、测试完后，用这专门的bug 号码才可将改动的原码提交到原码库里。 h_ RT%$mD
y44dEb#H o
绕了个大圈子，现在可以回答你的问题： 3(X\r=p^S
ezU`8tX
1） 微软不用专门的 SCCB 组织和 SCM. 但整套Raid 和Source Deport /VSS 的用法及章程就是一套严谨的 SCCB. [fH +>43_
2） 没有SCCB, 而是用三国会议(Triage) 来起相同的作用。三国即PM, Dev, QA. Z&j,q hfR
3） 变更的种类有：DCR, Work Item, Code Error, etc.
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
