和许多其它大公司(如摩托罗拉、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
此文章共有5页 1 2 3 4 5 下一页
|
Leadge.com首页 > 知识库 
