很多时候，需求评审通过都是一个里程碑似的名词，因为它意味着需求总体变更幅度会变小，可以正式进入开发、测试阶段了。
接着上一篇的内容，这一篇博客，主要说说需求评审通过后，开发、测试、发布以及项目管理一些内容。。。
四、开发、测试、发布。。。
需求阶段之后的项目过程就是开发、测试、发布，这个阶段的主力是工程师，作为PD，要随时配合工程师确认需求，项目经理，要做好“控制”。
1、开发阶段，各显神通
开发阶段，大概是设计、设计评审、编码、单元测试这几点，大概过程如下：
设计：就是俗称的开发设计，包括系统采用何种框架、服务，数据库设计表字段等等，以及定义开发接口、参数字段等相关的一些东西，一般都会有相关设计文档；
设计评审：一般完成开发设计后，会组织PD和测试人员一起参与评审，审核工程师们对需求的理解是否一致正确，以及方便测试童鞋展开下一步的工作；
编码：这个阶段就是针对需求的具体实现阶段了，开发同学埋头码代码，测试童鞋埋头写用例，讨论需求，功能点，巴拉巴拉，一派和谐；
单元测试：就是开发在自己本地开发环境自测，保证代码功能的实现，自测环节做到位，可以减少很多后期测试童鞋的工作量，问题总是越早发现解决成本越低；
开发完成单元测试后，就会将代码从生产环境提交到测试环境，然后就会进入下一个阶段，测试。
PS：有些公司是单元测试交给专职的人员来做；有些公司开发完成后发提测邮件，由测试拉取分支代码到测试环境，进行测试，具体以公司流程为主！
2、测试阶段，人人有责
之前的读书笔记中有提到过，产品质量是所有人的事，不只是测试的事；缺陷一般都是内建的，而不是外力造成的，所以，测试，人人有责。。。
开发在编码时候，测试一般都是进行需求分析，功能点划分，设计测试计划、测试方案、测试用例（包含测试数据、测试脚本等），并形成文档；大概过程如下：
用例编写：经过需求分析，功能点筛选划分等工作之后，测试工程师根据项目具体情况，利用设计用例的各种方法来设计、编写测试用例；
用例评审：用例编写完成后，会组织PD和开发童鞋进行评审，时间一般在开发提测之前，大家再次确认对需求的理解一致性，很多细节性的东西无法在需求阶段考虑完全，要通过开发和测试阶段
的反复沟通来不断细化；
冒烟测试：即简单快速的对主流程功能进行测试，确认软件基本功能是否正常；
测试阶段：完成冒烟测试后，接下来就是接口测试、系统测试，不断回归验证BUG，UAT测试、上线验收测试等等；
3、发布上线，提心吊胆
完成开发、测试之后，接下来就是该发布到生产环境供用户使用了，几个重点如下：
①代码管理
常用的代码管理工具有SVN、Git等，修改的代码从“开发环境-测试环境-预生产环境-生产”等一步步更新，如果代码版本控制不好，很容易发生BUG频发的情况，工程师想必是深有体会。。。
如果涉及到多个项目并行，就会牵涉到多分支开发，以及代码迁出、合并等问题。
②发布评审
即决定发布的产品，要满足什么要求，是否符合既定的发布上线规定等，比如牵涉到改动较大的项目，甚至可能分模块分步骤发布，比如先发布到哪几台服务器，让一部分用户先用，然后根据情况
发布剩余的服务器等等，对于用户影响较大的版本升级，可以采用“灰度发布”这种方式。
③生产验证
在发布到生产环境之后，测试人员也要进一步在生产环境进行一轮测试回归，确认无问题后，一般需要发邮件或其他形式告诉相关成员：“生产环境验证完成，发布成功”。
④发布时间
一般来说，能安排白天发布固然好，但很多时候为了避开用户使用高峰，只能安排的晚上进行；还有就是尽量不要在周五发布，因为如果出现故障，双休日人员反映等比较困难。
4、关于需求变更
在项目周期内，最怕的是什么？相信有过经历的工程师，都会提起一个词：需求变更。下面是几种常见的情况（需求变更和新增需求这里都归结为变更）：
①需求变更
需求变更是指项目范围内的需求变化，需求细节的确认、微调总是不断存在，对于这点，需要定制一些流程做控制，不是为了限制变更，而是为了让每次变更都经过深思熟虑，对变更
的范围大小以及时间上的影响进行分级和确定，灵活调整整个项目的“工期”；
②新增需求
所谓的新增需求，是指项目范围外的扩展，这种“半路搭车”事件总是存在，对于这种情况，需要今早在需求评审通过之前就确定，作为项目经理等管理者，也要做好控制，不能因为
随意让别人搭车而导致团队长期、高负荷加班，这样得不偿失；
③紧急事件
这种事情偶尔也难以避免，不受常规流程控制，一般是由较高层的leader确认后自上而下的推动，级别越高越需要优先处理（其中种种，有过经历的工程师相信都明白。。。）。
五、项目管理
“计划于控制，就项目管理”。从互联网角度出发，项目管理中的几个关键问题，就是：文档管理、流程管理、敏捷方法。
1、文档管理
模板、规范、操作步骤......等等一系列的文档，导致有些人甚至醉心于此，特别热衷于向别人要一些文档模板、项目管理流程之类的东西，本来只是一种手段，却演变成了一种目的。
文档的存在只是为了方便项目流程管理、新人快速上手、遇到问题快速回溯等，实际上，“文档只是手段”。
至于具体的文档模板，每个公司的文化，团队氛围造就了不同的文档适用性，需要整个项目团队协作和管理，才能有效的进行项目管理。
PD常用文档模板下载链接：http://iamsujie.com/9000/9078
2、流程管理
长视者把目的当手段，短视者把手段当目的。比如教育里的高考，公司里的KPI等，研究手段，不能忘记目的，“流程也是手段”。
①关于项目VS流程
有个需要注意的原则是：新人做老产品，不挑活儿，老产品稳定不容易出事；老人做新产品，需要变化才有激情。
②流程的本质目的
当团队较小的时候，需要“个人”把自己的经验技术转变为显性的知识表达出来，当团队变大，对于经常做的事就需要流程这种形式固化、传承，最起码后来者做事不会太无助。
关于这点，规范、模板作用也类似，这就是团队的核心竞争力。
核心竞争力：个人的核心竞争力是把显性知识转化为隐性知识的能力，团队的核心竞争力是把隐性知识转化为显性知识的能力。
③评审可以省略吗
之前列举了很多的评审，大概如下面几项：
产品会议：必须有，决定“做不做，做多少”，方向错了很可怕；
项目启动会议：最好开一下，鼓舞士气，磨刀不误砍柴工；
需求评审：最好有，以确认统一对需求的理解，问题越早发现越好；
以上三项可以算作商业评审，其决定“做不做”，是产品会议与功能评审。
设计评审：如果时间紧张或开发人员能力较强，可以省略，但如果开发较弱，新人多，业务不熟悉的团队，就很有必要，否则就是给自己找麻烦；
TC评审：仅次于需求评审，这是纯技术的评审，如果不做，那么PD的工作量就更多，后期的验收测试，也需要更细致；
功能评审：可以理解为UAT，是上线发布前的最后一个测试环节，相对来说比较重要，如果注重敏捷方法，也需要通知到相关的人员，让大家去看看；
发布评审：重要程度相对较低，由项目管理者决定是否需要；
以上四项可以说是技术评审，其决定“怎么做”，完全是工程师们的工作职责。
3、敏捷方法
敏捷方法，是互联网发展至今，越来越被提倡的一种软件工程模型，不过需要明白一点：“敏捷更是手段”！
敏捷方法的特点，下面列举一些：
①有计划，更要拥抱变化
互联网行业，一切的信息环境瞬息万变，死守着项目计划不调整最后只有死路一条，而且不确定性会累积越来越大，直至造成不可挽回的结果，类似“雪崩效应”。
所以，强行遵守计划是没意义的，应不断修正不断调整，当然，项目计划开始留出一定的弹性空间很有必要。
②迭代周期内尽量不加任务
敏捷再灵活，也怕毫无控制的变化，所以，确定迭代的权限、范围、内容，就显得很有必要。
③集中工作，小步快跑
小步快跑的精髓，“沟通是核心”。有效快速的沟通，永远是效率提升的不二法门。
④持续细化需求，强调测试
“唯一不变的就是改变”。项目产品都要小步快跑，不用在需求过多花费精力。对于这种敏捷方法下的项目，TDD是一种很好的策略。
⑤不断发布，今早交付
让需求方甚至用户不断、尽快的看到结果，并给予反馈，因为，真正的“用户”，更知道自己要什么。
六、项目的坎坷一生思维导图
