产品与团队——企业开发流程与管理

摘要

本博文主要是介绍在公司中开发实际流程，帮助你更好的进入工作状态。快速熟悉公司流程。同时本人在世界五百强软件公司工作，我们公司的开发流程请大家参考。

一、工作岗位介绍

1.1 PM(project management)/PMO(project management office)：产品经理

主要的职责：通过对用户的分析和反馈，还有多年行业经验，以及同行之间产品分析，想出很多的产品需求，做好这些需求设计之后，就得他们的产品总监和其他产品内部评审这份设计。产品总监认可之后的需求。产品经理就会拿着需求交给程序员。

1.2 ARC:（Architect） 架构师

项目架构设计，项目优化设计

1.3 UE/UI：交互设计师

负责页面布局、交互的设计，不负责视图的细节。交互确定之后，设计页面样式。注意，很多情况下，UE 和 UI 是一个人。

1.4 RD（DEV ）：后端开发人员

后端项目开发，Bug的修复，项目的单元的测试，function的编写，project demo展示

1.5 CRD：客户端开发人员，安卓和 ios 都是

1.6 FE：前端开发人员

1.7 QA：测试人员

1.8 OP：服务器运维人员，一般负责审批上线单

二、工作流程图

三、工作流程图说明

3.1 产品经理提需求

产品经理通过对用户的分析和反馈，还有多年行业经验，以及同行之间产品分析，想出很多的产品需求，做好这些需求设计之后，就得他们的产品总监和其他产品内部评审这份设计。产品总监认可之后的需求。产品经理们就会拿着需求来交给程序员。

3.2 需求评估

产品经理拉上各种开发人员，比如APP、Java后端、前端、UE交互、UI设计、QA测试等等，进行这个需求的评审。每个人对这个需求各抒己见，哪些地方不合理，哪些地方这期不适合开发等等，产品会做会议记录邮件，然后更改需求，如果改动较小，就以邮件形式通知各位开发们，如果改动较大，还需进行二次评审。

3.3 技术方案设计

产品经理提出需求，然后后端开始做技术详细设计，UE做交互稿，QA做测试用例，UI根据UE的交互稿做页面设计。后端的技术方案设计非常重要，这一步其实是对产品业务的一个梳理过程，让你能够更加了解业务需求，在设计的过程中能够及时发现哪里不合理，哪里有风险，哪里用什么样的技术栈等等。能让你在写代码的时候，速度又快，质量又高的完成开发工作。

3.4 技术设计评审

这里有几个方面需要评审，UE的交互稿，QA的测试用例，这个是需要全体人员进行参加的。而后端的技术方案设计，只需要技术leader和一些组内技术人员参加评审即可，因为其他人参加也听不懂嘛。这个技术评审能让你学到很多东西，对业务的风险把控，技术栈的选择等等，leader会针对这些给你提一些专业性的意见。所以技术方案一定要做好，这也是领导了解你的一个过程。你每次都做的很详细，很靠谱，那以后有好项目领导肯定会优先考虑交给你做。

3.5 项目进度排期

进入开发前要先进行工作量排期，就是工作计划安排，今天干什么，明天干什么，这个排期非常重要，排期有时候能直接影响你是996还是965， 因为严格控制排期，按照排期计划走，能让你比较从容的开发，各个环节有条不紊的进行。但是如果情况特殊，就是有好几个需求并行开发，时间都特别紧急，那排期也救不了你了。比如到了双十一大促，618大促，那都是很忙的时候。

3.6 项目开发

以上都搞完之后就可以进入真正的开发了，首先前后端要进行mock接口定义， 提供一些mock数据给前端等等，因为目前都是前后端分离的开发模式，双方定义好接口交互方式，就可以各自干活了，相当于并行开发。这样的工作效率非常高，谁也不用等谁。双方开发完之后就进入联调，前端切换成后端的真实接口，然后双方进行自测。

3.7 code review

 开发工作全部完毕之后，进入代码review阶段，这个时候一般是叫上leader和组内的其他技术人员参加，他们会根据业务背景，以及你的代码实现提出一些意见，比如这里用工厂设计模式比较好，或者这里的代码逻辑可以在优化一下等等，这个阶段也是一个非常好的学习过程，你写代码都是按照自己的知识储备和风格去写，别人从他们自己的知识储备来看你的代码，会提出不同的思路，这样你就能学习他人的一些知识。

3.8 项目测试

以上都做完之后就进入测试阶段了，写个提测邮件给测试爸爸们，心里祈祷着千万别测试bug，结果测试经理们立马给你发了一条钉钉消息：英雄来干了这碗bug。测试一般分为测试环境和沙箱环境，测试环境又细分了很多子环境，比如stable环境、betaa环境、betab、betac、betad环境等，为什么要搞这么多测试环境呢，因为可能会有很多需求并行在开发，就需要很多环境来测试这些需求。一般中小型公司就没这么多环境。那么沙箱环境又是什么呢，就是模拟线上环境，几乎和线上环境是一模一样的，就是为了在上线前能够保证不出任何问题，因为上线是一件特别神圣的事，一旦出问题，你就背锅吧。测试完成后产品进行验收，产品经理满意了，这个时候就可以上线了。

3.9 项目上线

上线是一件非常神圣又庄严的事情，一般老哥都会先沐浴更衣之后在执行上线，因为一旦上线出问题，那就没时间洗脸洗澡了。上线前要做很多准备工作，列出一份上线清单，把上线涉及的影响点全部列出来给QA。比如是否有数据库工单，是否申请了ES索引等等，集群上线顺序，出现问题回滚顺序等等，万事俱备之后，就开始神圣的上线了。

3.10 上线后回测

 不要以为上完线就万事大吉可以开溜了，QA还需要回测此次版本涉及的功能点，这个时候就得祈祷了，千万别有什么问题，要不今晚又回不去家了，如果上线出现问题不能短时间解决，最好的方法就是回滚，回滚到上一个可用版本。如果没有任何问题，这个时候产品经理就要登场了，来验收你的劳动成果，产品经理点头了就可以收拾东西回家睡觉了。

四、敏捷开发流程

摘要

主要是介绍敏捷开发的相关的概念和理解。

敏捷开发

以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发！其核心：用户的需求进化

采用的方法：迭代、循序渐进。

敏捷开发原则

敏捷开发的实现

产品

UI+开发

测试+开发

敏捷开发流程

首先是需求评审，产品经理与客户沟通好需求后，将客户的需求细化为一个个的story，需求评审由各leader参加。

一、story讲解

     1.1 制作竞品分析PPT，UE全组参与。（用时：根据产品复杂度，0.5-2小时之内）

     1.2 制作产品原型，交由客户看，客户没有异议之后拆story

     1.3 产品在禅道拆分好story，并且定义出优先级，关联需求，后续开发根据优先级进行开发

     1.4 由产品讲解story，前端和后端都参与。（用时：根据产品的复杂度，1-3小时之内）

二、人员划分

     2.1 新建wiki项目主业，把PPT和产品原型（HTML文件）上传到wiki

     2.2 根据产品原型，按照模块划分相关负责人，前端和后端都是，并放到wiki。（由项目负责人新建）

     命名：xxx项目人员分工（前（后）端）

三、做方案设计、定义接口文档（2-3天）

     3.1 前端后端相关人员一起，对照原型，根据模块及页面大概定义出接口

         3.1.1 一个页面中有几个接口，每个接口入参与出参是什么

     3.2 后端每个模块的负责人，根据开会讨论的结果，在wiki上生成标准的接口文档

     3.3 将后端做好的接口文档发给前端模块负责人过目，有问题继续修改；没问题开始后续的步骤 。

四、方案设计（1小时-1天左右，根据模块大小定义时间）

     4.1 后端开发人员，根据原型以及定义的接口，做好方案设计

         4.1.1 对有难度或者有疑点的接口，做出方案，尽量给出多个合理方案

     4.1.2 每个方案写清楚优点缺点

五、方案评审（2-3小时）

     5.1 对做出的方案设计，做方案评审，建议全体人员参与（无论做不做该项目）

六、禅道拆分（1-2小时）

     6.1 相关负责人按照优先级顺序，在禅道拆分自己的任务，单个任务最多不要超过4小时，即拆分要详细

七、开发

     7.1 搭建开发服务器

     7.2 开发人员根据禅道上的任务，按时完成自己的开发工作，具体体现到日报上

     7.3 每天上午开10分钟左右进度会议，如果有延迟现象出现，拿出解决方案，保证项目按照禅道上的时间点完成

     7.4 数据库索引：

     两种索引：1.经常查询的，数据散列度比较高的，做一般索引，不需要建联合索引。2.数据必须保持唯一的，建唯一索引。

        要有文档，文档表明哪些字段要建索引。发邮件。

八、阶段测试

     与开发并行

     8.1 每天至少发布一次代码到开发环境，并且保证发布完之后程序没问题

九、性能测试和coderevivew（1天）

     9.1 对每个接口做好性能测试

       9.1.1 每个接口的响应时间不超过200ms，如果有超过的，做优化，尽量缩小到200ms内

     9.2 完成codereview，根据codereview结论完成修改

十、压力测试

    10.1做好压测报告

十一、 Demo

     1、发demo申请邮件，收件人包括产品、测试同学、前后端相关开发人员

         主题：XX项目demo通知

         内容：时间 地点  参会人员

     2、开demo会议：主讲人：某个开发人员

         会议途中产品和测试提出问题

     3、发demo结果通知邮件(由产品同学发)

          内容包括：1、demo结果  2、如果不通过，有哪些问题

     4、如果不通过，召集第二次Demo会议，知道通过为止。第二次会议只需演示之前不通过的部分

11.2 测试

     1、demo通过之后，1：开发人员对代码打tag，参考文档如何打tag2.开发人员部署测试环境，部署完成之后发邮件，写明域名；3：交给测试人员进行测试，测试人员发送全体测试周期邮件

     2、测试期间，开发人员要常去禅道看自己的BUG ，及时确认BUG，及时修改

     3、修改BUG之后，开发环境前端代码由前端同学自己部署，后端代码由后端同学自己部署

     测试环境每天的下午6点由后端同学统一部署前后端代码

     4、测试完成之后，测试或产品发送上线通知

十二、 发布测试环境、集成测试（2-3天）

     12.1 禅道上建立bug，测试出bug，指派给相关人员修改

十三、发布线上环境，同时停止开发环境和测试环境

十四、线上监控

     错误报告

博文参考

开发流程_阿里等大厂真实开发流程_Ferrybunny的博客-CSDN博客

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！