项目流程的制定
在我们工作中，创业公司或是需要抢占市场的项目都采用敏捷开发的方式。最快上线投入市场，可是随着公司的成长，项目的变大项目流程就显得越来越重要了。于是就会在项目开发的过程中引入项目流程控制，以保证项目周期和质量。此是可能是由公司高层制定，也可能与我们测试人员商量，对于我们测试人员，应该如何制定项目流程呢？
一， 国际性工业化流程
软件项目工程有标准的流程，也就是国际化标准流程，当然我们可以从书上或是网上获得相。如下所示，是我在网上查找到的一个流程：
在实际的公司项目流程中，发现如果完全按标准的流程来走会有很多问题，关键原因就是这个标准的项目流程是有适应条件的：
（1）项目周期长，有充足的时间；而公司的项目往往周期比较短，一周的项目周期就算长的了，所以根本无法按正规的周期来执行。
（2）相关标准和文档比较完善，而且要求高。而现在公司很多开发人员不愿意写文档，或是项目历史包袱较重，没有办法整理相关的文档。
（3）领导重视项目流程，严格按标准执行。大型的公司比较重视流程，而现在关注点比较多，如收入，客户，市场等等，造成流程无法完全按标准执行。
二，个性化的项目流程
针对标准化的流程执行起来比较困难，所以需要根据自己业务和团队特点来制定个性化的项目流程。简化标准流程，加强自己需要的部分，下面我们举个例子，以下面四个阶段做相应的流程控制：
（1）需求阶段流程控制
需求是一个项目最早的阶段，所以我们也需求从这个方面开始进行控制。如从以下几个方面进行控制：
- 项目启动阶段：在需求评审之前，则产品给项目相关人员发送一封项目启动邮件。简单描述项目情况，并安排需求评审的相关事项。
- 测试用例评审：在需求评审完成后，测试人员需要开始设计相关测试用例，并发起测试用例评审。以确认项目相关人等对需求理解一致，防止需求遗漏等现象。如有变动，回复项目启动邮件，周知大家。
- 需求同步：在开发过程或是测试过程中如果需求有任何变动，必须同步相关人员，不能开发和产品一商量就改了需求，测试人员不知道相关情况。回复项目启动邮件，周知大家变动的内容。
- 新增加需求控制：需求要项目启动的时候，可能没有想的那么细，如果在开发或是测试阶段，需要增加相应的需求，必须三方人员一起评估新增加内容的工作量。如果不影响项目排期，可以添加；如果影响了项目排期，就需要评估是延期还是再新开需求。并回复项目启动邮件，周知大家评估的结果。
（2） 提测试阶段流程控制
在需求开发阶段，如果有必须需要进行设计评审，对设计方案，实现细节进行评审。当然这个评审可以在开发内部进行，产品和测试参加与否都可以。但是提测试阶段也有相应的需要控制的部分：
- 冒烟测试必须通过方可提测试：在测试评审结果后，测试人员会提供冒烟测试用例给开发进行自测；开发人员必须自测冒烟测试，所有冒烟测试用例通过后方可提测试。开发人员在提测时，回复项目启动邮件，把冒烟测试的详情情况周知大家。
- 自测版本必须是提测版本：开发人员在自测的时候，必须是提测试的最终版本，不可在本地测试，然后打包后发现出了问题，不可以测试。如有可能，可以按测试的方法来部署环境，进行自测试。
- 如果冒烟测试通过不过，测试人员有权拒绝测试。根据经验表示，如果冒烟测试通过不过，或是只有部分功能实现的情况下，测试人员的介入是无用的，此时往往浪费很多测试时间。等再次提测试的时候，先前测试过的内容还需要重新测试。为了保证项目流程，合理利用各方资源，必须有权决定测试介入时间。在测试人员冒烟测试通过后，请产品进行初验，以保证符合需求内容。冒烟验收测试无论通过与否，都需要回复项目启动邮件周知大家。
- 提测文件必须全面，做到不遗漏。如果开发的文件较多，在提测试的时候必须保证相关的文件都进行的提测试，不能在测试的过程中才发现文件漏提。如果发现这种情况，回复项目启动邮件，周知大家，督促相关人员提高提测质量。
（3）Bug相关流程控制
在测试过程中，会发现不少Bug，当然不同的公司都会有不同的Bug管理办法。Bug管理在流程控制中是非常重要的环节，需要从以下几个方面考虑：
- 所有在测试中发现的Bug必须提到Bug管理平台中：有些是测试人员的习惯，发现问题直接告诉开发人员进行修改；有些儿是开发人员不喜欢从Bug管理平台上看自己的问题，这些儿都是不好的习惯，所有的问题必须记录。否则就会造成问题的遗漏，也不便后期项目总结的时候进行问题分析。
- 开发人员必须按Bug优先级进行处理：有不少程序员喜欢按难易程序进行问题的修复，可是这不利于测试工作的进行。既然测试人员对Bug进行了分级，就必须按优先级来进行处理。
- 开发人员修复Bug需要及时更新状态，测试人员按Bug状态进行验证测试。在测试过程中，Bug修复情况以管理平台中的状态为准，没有更新状态的Bug按未修复处理，不予进行验证测试。
- 上线的时候，如果存在Bug没有修复，需要严格处理。如果到了上线日期，仍然有Bug没有修复完成，必须认真处理。必须处理的Bug没有修复，则不予上线。延期处理的分给产品请产品注明原因，并回复项目启动邮件予以说明。
（4）上线阶段流程控制
项目到了上线阶段应该不过有太多的问题了，可是还是会因为一些儿细节问题会影响上线的。所以在上线阶段也不能放松：
- 项目负责人制定上线计划，包括：a,上线需要的前期准备，相关权限，内容的申请；b,上线顺序及相关负责人；c,上线后的后续工作。并回复项目启动邮件，通过相关人等。
- 上线时相关人员必须在场，并确定拥有相应的权限。一般项目如果到了晚上上线，有些相关人员如果通知不到，会发现上线的时候找不到人。或是上线人员没有对应的权限，严重影响上线流程。
- 项目上线完成后，产品回复项目启动邮件，总结上线成果，并关闭项目。当然大的项目还会进行项目总结，进行相关内容的汇总与讨论。
风险预警
风险预警贯穿于整个项目的始终，任何阶段如果出现了严重影响项目排期的问题，必须进行风险预警。邮件通知所有人员，并组织相关人员进行风险评估，同时同步评估结果，以便相关人员进行工作调整。
通过上面四个阶段做相应的保障，同时在各个阶段把控相应的产品，以及严格确认能否进行下一个阶段，就能基本保障一个项目流程不会出现严重的问题。当然还可以根据自己团队的特点，强化或是弱化相关的内容。
三，项目流程的保障因素
一个流程或是规章制度无论再完善，还是需要靠人来执行和保障的，同样项目流程也需要有相应的保障：
（1）项目负责人重视项目流程
一个项目需要有相关的负责人，或是项目经理，或是产品，也可以是开发或是测试。不管是任何人，必须严格把控项目流程，注重相应该阶段的产出，如果有问题及时找相应的人员来处理。
（2）参与人严格遵守
项目的参与人必须严格遵守流程，按规则执行相应的步骤，产出相应的输入。积极改正以前不好的习惯，如部分测试，不提bug,提测试时不进行冒烟测试等等。
（3）测试严格把关并拥有相关权限
测试人员是项目质量的验收人员，必须在项目流程中进行严格的把关。任何阶段输出给测试的产出不符合要求，都要有权进行拒测，或是要求做出明确的说明。如果测试人员没有任何权限，项目流程在测试环境肯定执行不好。
（4）领导的大力支持
做好整个项目流程的把控，没有领导的支持是不够的。
首先，领导需要认可我们在项目流程控制中的工作，如果不认可，相关人员就没有动力。
其次，支持相关人员做相应的控制，比如说，如果测试说冒烟测试不通过不能测试，产品或开发找到了领导，领导让听产品或是开发的，而不是听测试人员为什么不能测试，那也不好进行流程控制。
再次，领导不能做打破流程控制的指示，如直接对相关人员下达命令，让做什么样的工作，而这个工作有可能影响整个项目的流程等等。
总体来说，项目流程控制在前期执行起来相当痛苦，需要改变很多我们以前的习惯。做相当多的额外工作，大部分人还是会抵触的，因为不爽嘛！可是一旦流程化执行起来后，后续工作就会非常容易，项目优化，项目交接，新人介入等等。所以建议先从新项目，周期比较长的项目引入流程化，慢慢改变大家的不好习惯，严格按流程进行相应的工作。
