到了后期新open的BUG数量一直上升则说明风险在增大，有可能无法控制，也就是说fix了一个BUG导致了多个新的BUG产生。在量化开发进度中也可以用代码数量的曲线图来粗略的呈现。在有大量新功能增加时可能代码量的增加会较快，当在fix bug阶段，代码的修改较多，因此代码数量的增幅会降低，依据代码量可以看出开发的状况处于何种阶段。

需要指出的是我们对BUG的定义比较广泛，一些新功能也可以作为BUG被提出，只不过这些BUG级别比较低，让它们进入到下一个版本中去实现。因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身，因为他可能会找出一些BUG，有些是其他开发者的，有些可能是此开发者本身的，把这个BUG添加进BUG库中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路，但此BUG的verify必须要让测试本模块的测试人员来verify。

8. Code Freeze

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

9. Tech Talk

计算机知识更新速度非常快，经常有一些新的术语、新的名词、新的思想、新的技术所产生，如过离开此行业几个月后重新回来就会对这些新的事物不解，而我们平时为了自己的项目埋头苦干可能忘了周围的世界发生了什么。Tech Talk就提供了一个让我们了解新知识和最新发展趋势的机会，让大家把知识共享，共同提高。Tech Talk一般会在项目不是太忙碌的时候进行，主持人会提前一个星期指定某个人去准备一下Tech Talk，一般此人可能对某方面比较感兴趣，然后他会花一些时间去了解这方面的情况，写成一个文档如PowerPoint并上传到局域网内，同时通知大家可以先去浏览。Tech Talk的内容非常广泛，不一定同我们的项目紧密相关，任何新的思想、新的知识（当然一般是限在计算机领域内）都可作为Tech Talk的内容，而在主讲人讲完之后还有一段时间被大家提问，共同对这个话题进行讨论，答疑解惑。当然Tech Talk也可同我们的项目相关，如研究一下竞争对手的产品技术，本公司产品的架构等。研究本公司的产品架构可以使大家对本公司的产品有一个全局的概念，从整体上来看自己的产品，顺便整理一下产品的架构使之更加清晰有条理。平时大家都只注重于自己负责的其中的一小块，在Tech Talk中可以跳出自己的小框框来了解全局，同时这也是新员工了解公司核心技术整体框架的好机会。每个模块的负责人需要阐述此模块的方方面面，让大家来了解并回答问题。

10. Code Review