[ZC][Part] 一个高效成熟的商业软件开发流程和团队

......

虽然这个开发进度时间是一个大概的估计时间，但我们要尽力按照这个开发进度来执行。每个星期五下午我们有一个Status Meeting（一般那时工作效率较低，适合开会），在此会议上我们会根据这个进度来review我们的工作，每个人手上的工作是否按照这个进度在走，是否有人延后了，是否block住别人的工作了。在此会议上每个人都要报告自己的进度，同时还要报告上个星期做了什么，正在做什么，以及下个星期打算做什么。通过这个会议，会让你觉得有人在监督你，无形之中迫使你不断地督促自己不要使任务延后

......

若有谁check in的代码导致daily build失败则会被要求某些惩罚措施或警告，象微软公司要负责照看当日的每日构建。有时我们编写的代码涉及到多个文件，而且此改动是比较复杂需要花费多天的工作量，如果现在check in进去可能会导致BVT（Build Verify Test）测试通不过，因为有些代码没有完全完成，而之前的代码能使BVT测试通过，而且这些代码基本上不会涉及到他人，在这种情况下可以不check in进去，直到全部代码完成能提交BVT测试时再一起check in进去。
每天我们都会做daily build，一般是在凌晨4点进行，那时有个程序会自动从VSS中拉下最新的代码并进行编译。因为我们同美国进行同步开发，因此如果想要把修改的代码进入到这个build中去那就需要在凌晨4点之前把相应的代码check in进去。若有人check in进去的代码导致编译通不过则会在本步骤中被发现。当编译完成之后自动产生安装包，测试部门将会对这些代码进行BVT测试，同时对VSS中开发库打上label，如果发现了什么BUG就能根据这个label知道是哪个时候开始出现这个BUG的。BVT是指Build Verify Test，是对组件中基本功能的测试。这个测试每天都会进行，看新加入的代码或修改是否会影响系统的基本功能，便于及早发现错误。

......

5. 测试
在开发人员完成了function Spec后，测试部门开始了测试规划，确定需要测试哪些方面，如何测试及进度安排。测试人员需要写许多测试代码，有些测试代码需要集成进BVT测试，有些可能需要进行单独的测试，目的都是为了使产品符合要求，使开发人员容易找出问题所在并改正。产品功能是否符合了要求，是否能被发布是由测试人员决定的，因此测试人员也比较辛苦，责任重大。通过了每天的BVT测试，还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。在完成这些测试之后由测试人员决定本产品是否能release出去了，如果没有什么问题则会给某些关系较好的用户进行β测试，之后再最终release出去。
......

在QA增加BUG和开发人员fix BUG的游戏中，BUG的数量曲线图会象股市曲线一样上下波动，但总体趋势一般是前期BUG放量攀升，后期震荡下挫，若到了后期新open的BUG数量一直上升则说明风险在增大，有可能无法控制，也就是说fix了一个BUG导致了多个新的BUG产生。在量化开发进度中也可以用代码数量的曲线图来粗略的呈现。在有大量新功能增加时可能代码量的增加会较快，当在fix bug阶段，代码的修改较多，因此代码数量的增幅会降低，依据代码量可以看出开发的状况处于何种阶段。 
需要指出的是我们对BUG的定义比较广泛，一些新功能也可以作为BUG被提出，只不过这些BUG级别比较低，让它们进入到下一个版本中去实现。因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身，因为他可能会找出一些BUG，有些是其他开发者的，有些可能是此开发者本身的，把这个BUG添加进BUG库中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路，但此BUG的verify必须要让测试本模块的测试人员来verify。 
.......

7. Code Freeze当P5之前的BUG都被修复了，这时离产品发布日期也就不远了，一般是2个星期后就能release产品，这时要对VSS中的代码进行freeze，以保证代码库的稳定性。Code freeze阶段一般会把各开发人员的check in和check out的权限关闭，若在这时仍有BUG报告上来并经讨论确定是重大的且必须在本版本中fix的，则需要经管理层同意并特殊地授予权限，在修改完成后修改者要把修改了哪些文件，影响了哪些文档等信息上报给各部门如QA、build人员、文档编写者等。在code freeze阶段，测试部门在紧张地进行着各种测试，得出各种数据，并决定本版本是否可以release了。