发布时间 : 星期六 文章杰思敏软件开发流程更新完毕开始阅读a6ff2d14bb68a98271fefa27
对协同平台做升级开发时，有时我们编写的代码涉及到多个文件，而且此改动是比较复杂需要花费多天的工作量，如果现在check in进去可能会导致BVT（Build Verify Test）测试通不过，因为有些代码没有完全完成，而之前的代码能使BVT测试通过，而且这些代码基本上不会涉及到他人，在这种情况下可以不check in进去，直到全部代码完成能提交BVT测试时再一起check in进去。
每天我们都会做daily build，一般是在凌晨4点进行，那时有个程序会自动从JSM Soft中拉下最新的代码并进行编译。如果想要把修改的代码进入到这个build中去那就需要在凌晨4点之前把相应的代码check in进去。
若有人check in进去的代码导致编译通不过则会在本步骤中被发现。他将被扣分并通报。
当编译完成之后，由自动化测试程序进行测试，如果发现了什么BUG就能自动反映出来，即时通知测试人员处理。
测试部门首先会依据程序员前一天提交程序所解决的BUG和功能点，先手动测试一遍，若有问题，直接登记到JSM Soft的需求BUG中，然后，编制自动化测试程序，对这些代码进行自动化测试。
主要平台和组建更新，自动化测试就会进行，看新加入的代码或修改是否会影响系统的基本功能，便于及早发现错误。
5.2 项目提交测试
对C/S软件开发，在程序员完成了Function Spec后，提交测试、审核、批准、归档流程。
测试部门应提前开始测试规划，确定需要测试哪些方面，如何测试及进度安排。
测试人员需要写许多测试代码，有些测试代码需要集成进BVT测试，有些可能需要进行单独的测试，目的都是为了使产品符合要求，找出问题所在，并即时通知程序员改正。
产品功能是否符合了要求，是否能被发布是由测试人员决定的，因此测试人员也比较辛苦，责任重大。还有一些性能测试、兼容性测试、灾难测试等需要在
9
产品发布前进行。在完成这些测试之后由测试人员决定本产品是否能release出去了，如果没有什么问题则会给某些关系较好的用户进行β测试，之后再最终release出去。
5.3 BUG管理
由于我们每天进行着测试，因此经常有BUG被测试部门发现，一旦发现了新的BUG，就会被添加进JSM Soft 需求BUG中。JSM Soft 需求BUG是开发人员和测试人员之间的纽带，开发人员和测试人员通过需求BUG联系着。每个BUG有其类型、来源和级别，这些代表了重要性及紧急程度，重要且迫切的BUG需要很快fix，在本版本release之前必须fix掉，若真的不能或不重要则由测试人员确定并降低优先级进入到下一个版本中去fix。
测试人员发现一个BUG后在JSM Soft需求BUG中增加一个BUG，同时填入相关信息并即时通知给相应的程序员，程序员收到BUG分析并fix后再提交流程，其中要填上分析的结果以及如何解决的详细说明，有测试人员再测试，直到所有计划中的需求和BUG都被Close。
每星期在Status Meeting上会进行BUG状况报告，主要由测试人员报告BUG的状况，主要是新增BUG数，Close掉多少，还有多少处于open状态，有多少处于等待verify的状态，据此可以了解开发及测试情况。
在Status Meeting上我们还会进行BUG Review，BUG Review一般在一个小组内进行，其主要作用是重新明确每个人头上的BUG以及了解每个BUG的状况，如开发人员对这些BUG将作何处理等，以此来了解开发中是否有碰到比较棘手的问题和各类风险。
通过JSM Soft的统计功能，可以展示像股市曲线一样BUG的数量曲线图，一般总体趋势是前期BUG放量攀升，后期震荡下挫，若到了后期新Open的BUG数量一直上升则说明风险在增大，有可能无法控制，也就是说Close了一个BUG导致了多个新的BUG产生，这时，需要考虑人员是否胜任，是否需要好好整理思路，放两天假也许是个好主意。
10
在量化开发进度中也可以用代码数量的曲线图来粗略的呈现。在有大量新功能增加时可能代码量的增加会较快，当在处理 bug阶段，代码的修改较多，因此代码数量的增幅会降低，而修改量会增加，依据代码量可以分析出开发的状况处于何种阶段。
需要指出的是我们对BUG的定义比较广泛，一些新功能也可以作为BUG被提出，只不过这些BUG级别比较低，让它们进入到下一个版本中去实现。因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身，因为他可能会找出一些BUG，有些是其他开发者的，有些可能是此开发者本身的，把这个BUG添加进BUG库中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路，但此BUG的验证必须要让测试本模块的测试人员来做。
5.4 Code Freeze
当BUG都被修复了，这时离release日期也就不远了，一般是2个星期后就能release产品，这时要对JSM Soft中的代码进行freeze，以保证代码库的稳定性。Code freeze阶段一般会把各开发人员的check in和check out的权限关闭，若在这时仍有BUG报告上来并经讨论确定是重大的且必须在本版本中Close的，则需要经管理层同意并特殊地授予权限，在修改完成后修改者要把修改了哪些文件，影响了哪些文档等信息上报给各部门如测试、文档编写者等。在code freeze阶段，测试部门在紧张地进行着各种测试，得出各种数据，并决定本版本是否可以release了。
6. 技术沙龙
计算机知识更新速度非常快，经常有一些新的术语、新的名词、新的思想、新的技术所产生，如过离开此行业几个月后重新回来就会对这些新的事物不解，而我们平时为了自己的项目埋头苦干可能忘了周围的世界发生了什么。
11
技术沙龙就提供了一个让我们了解新知识和最新发展趋势的机会，让大家把知识共享，共同提高。技术沙龙一般会在项目不是太忙碌的周末进行，主持人会提前一个星期指定某个人去准备一下某个主题，一般此人可能对某方面比较感兴趣，然后他会花一些时间去了解这方面的情况，写成一个文档如PowerPoint并上传到局域网内，同时通知大家可以先去浏览。技术沙龙的内容非常广泛，不一定同我们的项目紧密相关，任何新的思想、新的知识（当然一般是限在计算机领域内）都可作为技术沙龙的内容，而在主讲人讲完之后还有一段时间被大家提问，共同对这个话题进行讨论，答疑解惑。
当然技术沙龙也可同我们的项目相关，如研究一下产品技术、产品的架构等。研究本公司的产品架构可以使大家对本公司的产品有一个全局的概念，从整体上来看自己的产品，顺便整理一下产品的架构使之更加清晰有条理。平时大家都只注重于自己负责的其中的一小块，在Tech Talk中可以跳出自己的小框框来了解全局，同时这也是新员工了解公司核心技术整体框架的好机会。每个模块的负责人需要阐述此模块的方方面面，让大家来了解并回答问题。
7. Code Review
当进行工作移交时我们会进行Code Review，在碰到棘手的BUG时也会进行Code Review，Code Review是大家了解其详细实现的一个好机会。
在Code Review之后会对此代码产生亲切感而不是陌生惧怕感，相信很多人在读他人代码时会有非常痛苦的经历，通过JSM Soft来Code Review是减少此痛苦感的好药方。
在进行Code Review前，主讲人会提前发出一个通知告诉相关人员要review哪些代码，这样参与者可以抽出时间提前了解相关代码，对不懂的地方做个笔记以便在Code Review进行中提出疑问。在我们碰到比较棘手的BUG没有什么思路或大惑不解时，这时找几个相关人员或对此代码也熟悉的人进行一次Code Review，这时形式比较随意，大家可以临时提出问题，让主讲人解答，在这个过程中可能听的人并不会非常快地了解其中的详细过程，但是讲的人在这个过程中
12