引言

战国·邹·孟轲《孟子·离娄上》：“离娄之明，公输子之巧，不以规矩，不能成方圆。”

每一个行业都有自己行之有效的规矩，同样软件行业也有自己一套的开发流程，今天就来跟大家聊一聊咱们公司的开发流程，让大家品评下，有兴趣的可以把自家的公司流程放到评论中哦，相互学习，相互进步。

需求确定

需求提出人（运营、财务、销售、人事等）会提出自己的诉

产品经理会按照诉求，梳理出需求文档和原型并最终和需求提出人确定最终版。

确定技术方案

产品经理、项目经理和架构师会按照上面出的需求进行技术评审，结合人力、成本、时间、风险等因素，确定合理的技术方案，并制定开发计划，确定开发周期。

组织需求评审

确定好需求及技术方案后，产品经理会组织所有的开发童鞋和测试童鞋，开发童鞋了解需要做什么，测试童鞋需要按照需求评审编写测试用例文档。

编写概要设计

开发人员按照需求评审中的内容及项目经理分配的开发计划中分配的开发内容，编写概要设计文档，文档中包含关键业务逻辑、业务流程图、数据库表设计等。

建议：文档内容力求能说出关键点，图表多一些，文字少一些。

概要评审

等开发人员编写完概要设计文档后，项目经理组织概要设计的评审，来确认从技术层面和业务层面是否满足需求功能。

注意：评审可以进行多次，务必要保证开发明确自己的开发目标，不能有含糊的字样。

功能开发

等概要文档评审后，开发童鞋按照文档中的内容进行开发，其中如果发现开发过程中有异议，也需要同步到文档中，用做记录。

功能演示

在迭代版本中，项目经理可以组织一定次数的功能演示，来检验开发的功能是否满足需求。

注意：可以按照需求维度、或者按照时间维度进行演示。

代码review

在迭代版本中，架构师（或技术大牛）可以组织一定次数的代码走查，用于发现代码中的坏味道，确保代码规范。

建议：不要等功能开发完毕后再进行代码review，因为迭代开发完后再改动成本大，就像建大楼到楼顶的时候，发现地基有问题，凉凉~

测试用例评审

在转测前，测试童鞋会组织一次全员的测试用例评审，看是否有对于功能的遗漏，进行补全。

冒烟测试

在转测前，开发童鞋根据评审后的测试用例评审，找到高优先级的测试用例在测试环境进行自测，确定是否成功。

测试环境转测

当代码review、冒烟测试、功能演示并在测试环境部署完成后，项目经理发送转测邮件，申请转测。

测试童鞋在测试环境进行测试，验证功能是否满足需求。

验收环境转测

当测试童鞋确定测试环境验证通过后，需要运维童鞋把测试环境的系统部署到验收环境。

测试童鞋、产品经理在测试环境进行测试，验证功能是否满足需求。

注意：验收环境是模拟生产环境，测试数据力求与生产环境保持一样。

压力测试

当整体功能测试完毕后，如果该功能有性能指标的话，测试童鞋会对功能进行压力测试（压力测试工具例如：jmeter等），如有问题可以协调运维童鞋和开发童鞋来处理。

迭代上线

当功能测试和压力测试都通过后，测试童鞋发送测试结果邮件，项目经理发送上线邮件，邮件包括：上线时间点、上线内容、上线计划、上线人员、值班人员等。

按照时间点上线，整个迭代到此结束。

最后，一句话根本形容不了我的穷，跪求工作，南京~