1. 概述
1.1.什么是流程规范
流程规范常伴于我们，小到一次会议，大到团队的管理。当然在我们的实际项目管理中，流程规范也是最重要的环节之一。流程规范中规范了产品、开发、测试等需要做的事。对于不清晰地界的说明，对于具体事项的划分，以及每个节点的要求。
1.2.为什么要做流程规范
流程规范的本质目的是提高工作效率、保证项目质量，从个人角度看似乎是降低了个人效率，实则是提高了整个项目组的效率。其中规范了每个节点的要求，利于提前发现版本迭代中的问题，降低了问题解决成本。
1.3.流程规范范围
项目流程规范定义了完整的软件研发工作流程，从需求管理、迭代规划、任务分配到编码、质量审查、部署测试、正式上线，适用于所有参与邻商科技项目人员，包括产品、开发、UI、QA等。
1.4.规范中数据化留存的意义
我们在规范中规定了每一步需要保留的具体数据：包括需求数据，开发数据，UI、QA留存数据，这种方式看似耗费了每个人的时间，实则提高了整个团队的协同效率。例如：我们经常会发现我们产品中的某些功能通常会在运行一段时间后，出现一些问题，后续的维护人员在查找问题时经常会一头雾水，难以维护，有时费事费力甚至不如重写；假如我们在实现的时候有统一标准规范，完善的需求开发设计文档，具体的实现方式等，那后续维护可能就会事半功倍。
所以说团队里面的每个人，在进行任何任务之前，小到一个功能点的代码改动，大到一个产品的需求规划，一定要想明白要解决的问题在哪里，事情的开展方案规划，预估好方案成本，把团队目标与配合的团队成员充分沟通，让每个人在执行个人任务时都可以从整个团队利益考虑，进而提高产品质量以及生产效率。一定要充分考虑到功能和代码的长远发展与维护，才能实现整个团队利益的最大化。
2. 需求流程规范说明
项目管理中，产品收集提出需求，需求经确认可纳入「项目」管理，由技术管理者转化成技术实现方案，通过「里程碑」规划迭代；接下来，将里程碑拆分为具体任务，安排给技术团队成员，实现从需求产生到落地的管理。
2.1.产品需求PRD文档流程规范
产品需要提前根据产品计划梳理业务，明确版本需求，根据优先级安排版本计划，大体流程如下：搜集需求→产品模块整理→需求池（功能整理）→梳理版本计划→墨刀设计PRD原型图→准备评审思考单、原型图PRD文档→发起评审→UEA验收评审通过→输出更新PRD文档→根据版本计划→提交UI设计→提交技术开发功能→测试上线→数据分析→产品迭代；
PRD文档具体包括内容：需求背景描述；具体功能说明；原型图输出物；技术可行性方案；详细规范如下：
2.1.1.需求背景描述
需求的背景和目标是否阐述清楚，讲清楚为什么要做这个需求，包括「做什么」「为什么做」「有什么价值」？
2.1.2.功能说明
功能点描述
需求涉及的每个功能点需要罗列出来，并且每个功能点详细说明，细节描述清晰无异议。
例：客户需要维护产品分类需求，设计功能点可能有以下几个
功能1 新增产品分类
功能2 编辑产品分类
功能3 删除产品分类
功能4 查询商品分类
每个功能点需要详细描述具体功能细节说明。
核心流程和业务逻辑
需求涉及的所有核心流程和业务逻辑描述清晰，无歧义。
例：还是以客户需要维护产品分类需求为例
流程方面：
核心流程1：用户需要先新增产品分类，然后对已有的产品分类进行增删改查操作；
核心流程2…
核心流程3…
其它业务流程等；
涉及业务逻辑方面：
新增逻辑：新增支持三级目录，顺序从一级类目-二级类目-三级类目顺序新增；
删除逻辑：删除遵循从低级类目到高级类目删除顺序，不允许越级删除等；
其它业务逻辑等；
2.1.3.原型图输出物
原型图页面完整度
1.界面逻辑清晰，页面状态完整不缺失；
2.原型图尺寸合理，还原真实文案。避免实际应用时位置不够，影响还原度；
3.建议使用黑白灰来表达页面层级和逻辑。尽量避免使用大量的色彩，以免造成焦点偏离等视觉干扰，不利于原型图的理解，也容易给视觉设计师造成困扰和误导；
4.忌用页面截图。截图容易造成表达上的误导和页面元素不统一的问题。线上产品优化如使用页面截图，需在图片上标注修改内容，以便于原型图的快速理解。
建议：
1.如果原型图中有尚未确定的内容，建议使用占位符代替；
2.如果需要特别突出的地方，建议在旁边标注或用文字的形式描述需求。如果用自己也不确定的一种色彩或者形式突出容易误导设计师；
3.常用控件可以尽量使用墨刀自带的控件，便于原型图的统一。
原型图注释
原型注释是为了便于开发和UI理清思路，准确的理解产品功能及需求，减少设计和开发过程中的障碍。
1.注释内容要尽可能详细、条理清晰，使技术、UI人员等更高效使用原型。
2.注释内容要遵循就近注释原则，便于阅读、并快速准确地理解原型图；
u 交互方案说明
交互包含页面间的交互、界面元素之间的交互。
1.要注明使用场景，并描述要实现什么逻辑和功能；
2.在对元素进行标注的时候，要注意标清元素、控件、功能的链接关系，触发该功能后指向哪里。
3.对触发动作进行描述，利用什么动作能达到什么效果。
2.1.4.技术可行性
产品设计在技术上是否可行
- 产品设计前是否与架构师进行了技术沟通，架构师负责产品技术可行性的评估。架构师明确否定的，无须进行评审，存在不确定的可提交评审会集体讨论。
2. 技术可行性评估原则：尽可能采用成熟技术、谨慎引入最新技术、着眼于具体的开发环境和开发人员、用户数据是否安全、新方案的实施成本等。
3. 技术可行性评估主要包括：
在限制条件下，功能目标是否能达到；
利用现有技术，性能目标是否能够达到；
对开发人员数量和质量的要求，是否能够满足；
在规定期限内，开发是否能够完成。涉及到接口/开发数据是否提供完整
- 是否详细提供开发所使用到的接口：包括top接口及后端接口；
2. 是否提供接口具体使用到的参数；
3. 开发账号不能模拟数据的情况，是否提供了用户账号或模拟数据？风险评估，应急预案说明
产品设计与线上逻辑存在冲突，或产品设计影响线上数据安全或严重影响用户使用习惯等较大版本变动时，必须提供应急预案。
应急预案涉及：
1. 何种场景下启动应急预案；
2. 应急预案是否可操作，是否依赖用户端；
3. 指定应急预案第一责任人；
2.2.版本流程
主/次版本号变更任务的开发流程（大流程）
线上版本号规则采用通用的三级版本号定义，包括：主版本号 ，次版本号，修订版本号，具体形式如下：
V3.2.050主版本号是3，次版本号2， 修订版本050
1. 主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化，导致项目整体发生全局变化时，主版本号加1。此版本号由产品经理决定是否修改。
2. 次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动或是在原有基础上增加部分功能等，主版本号不变，子版本号加1。此版本号由产品经理决定是否修改。
3. 修订版本号：一般是Bug的修复或是一些小的变动或是一些功能的扩充，要发布修订版，修复一个严重Bug即可发布一个修订版，主版本号和子版本号都不变化，修订版本号加1。此版本号由产品经理决定是否修改。
2.3.里程碑规范
在Gitee中，规划迭代是通过里程碑功能实现的，里程碑可以以工作模块/时间等维度对项目工作进行二级拆分，确定各阶段工作目标和各时间周期内的整体计划，控制项目工作的进展和保证实现总目标。
里程碑颗粒度细化建议为4-6周的时间规划，有明确时间点和计划的产品需求建议采用版本计划规划里程碑，例如：邻商小铺第一版需求计划时间节点是20200830，我们根据总目标的需求拆分到三个阶段完成，可以设立三个里程碑完成总目标。
V1.0.0 时间0612-0712 ：描述版本计划和目标内容
V1.1.0 时间0712-0812 ：描述版本计划和目标内容
V1.2.0时间0812-0912 ：描述版本计划和目标内容
Gitee里面里程碑的优点：
1. 「里程碑」展示了迭代计划、任务状态和层级关系、时间安排、相关负责人、相应交付的代码及其审查测试情况，充分发挥团队协作的灵活性。
2. 里程碑计划支持从项目集的维度，整体规划所有子孙项目集或项目的里程碑。
3. 支持项目树状视图，清晰展示项目集与项目间的层级结构。
4. 支持查看、编辑项目的负责人、起止时间以及时长等项目属性，轻松管理项目信息。
5. 甘特图上的里程碑支持拖拽，灵活更新里程碑完成时间。
6. 支持新建、编辑里程碑，以及快速更新里程碑状态。
7. 支持导出里程碑，便于数据统计、汇报。
2.4.需求任务管理及留存
在Gitee里面，我们可以在任务里面新增需求，录入需求后，如果需求不明也可以在形成结论之前，可利用 “需求评论” 功能对需求进行讨论。所有讨论会完整记录下来，确定需求以及形成PRD文档后，可以在当前需求下发起需求评审任务，如果需求过大，也可以分别拆分可独立实现的小需求完成（拆分小需求涉及比较少）。
里程碑以及需求确定后，需要在在 Gitee 企业版的【文档】中创建相关文档以描述里程碑目标和计划，需求评审完成之后，产品要把最终的设计文档以及评审思考单，统一放到企业文档里面根据里程碑-具体需求目录里面进行数据留存。
3. 开发工作规范流程
3.1.开发任务管理
在【项目】中，产品根据实际情况确定好确定各阶段工作目标和各时间周期内的整体计划，产品设置好里程碑需求后，可直接在里程碑-需求-指派开发任务，开发任务可继续拆分为任务、子任务（支持无限级）。3.1.1.开发任务分配拆分
当开发完成确定并完成一个需求后，需新增一个开发任务指派具体开发实现，负责的同事在该任务中，将大致的想法在其中描述，并且把相关的同事添加为此任务的协作者。协作者可以对任务进行评论或者编辑。
该任务经过沟通讨论定稿之后，开发负责人更改任务状态为【进行中】，根据任务讨论情况拆分建立子任务，并指定相应的子任务负责人。开发任务拆分的要求是子任务颗粒度尽量细化到0.5-1天；
3.1.2.开发协作
开发人员在本地完成自己的任务后，将代码提交到约定远程分支，然后在开发任务新增测试任务分别提交产品/UI验收，验收通过后可指派QA测试，测试通过之后，开发人员将代码提交到 指定【项目】中指定的【仓库】上，并且向由开发负责人指定的合并分支提出合并请求（Pull Request）。
3.1.3.代码评审与合并
开发负责人收到开发人员提交的合并请求，要求必须对合并请求的内容进行代码审查（Code Review），质量审查在于找出及修正软件开发初期忽略的错误，强制性要求开发人员代码规范，可读性，稳定性，维护性提高，流水化代码产出，提高效率，提升代码质量。 Gitee企业版的「 Pull Request 」可在开发者提交代码后，自动触发代码质量分析，减少人工审核，提升效率，通过人员审查后，将开发人员的改动合并到要进行发布的分支，最终由专人进行发布，建议有条件的情况下除了自动触发的质量分析，也可以采用人工代码评审
在代码审查完成后，是否进一步需要提交QA测试，需要根据实际情况而定，如审查问题严重，代码变更过大，建议在次提交测试任务QA进一步测试通过后，在提交代码审核与合并。
3.2.仓库与分支规范
当整个项目确定后，从开发角度而言，开发需要创建对应的仓库，分支方便代码提交，从代码的角度，Gitee支持“项目-仓库-分支”三级管理，支持分支保护，灵活适配各种开发架构。3.2.1.仓库规范
- 库名一律采用项目名子项目或模块结构名具体模块分类功能的形式。
例如：LinShangCloudShop_MiniProgram；
LinShang_CloudShop_BackStage；
2. 库名中不得出现下述规定的字符- \ @ ! # $ % ^ & * () [] {} | \ ; : ‘’ ’ ， 。 《 》 < > · ~ 。
3. 库名应尽量避免使用 名.名的形式。
4. 库名应尽量使用英文，禁止使用中文字符。一般情况下，库名中出现的各个单词的首字母应使用大写。各个单词不能使用连接符 -连接；如有必要，应使用下划线 。
5. 缩写的单词一律使用大写。3.2.2.分支规范
分支管理
分类
1.常设分支master 和develop ，此些分支不允许有任何的代码提交，修改只能是从release，hotfix，develop的分支进行Pull Request合并（下面简称P）
2.临时分支 分为release发布，feature功能，hotfix热修复分支
版本分支的维护由项目后端负责人负责切换和merge整合
另外:
· 个人分支不做限制（例：以前代码要重构或者修复bug，新功能又要开发，可以自行切分支，记得合并就好）
· develop和master分支的PR由项目负责人负责规范(实操在gitee上)
· git user.name 建议要求改成中文名称
· 命令如下 git config —global user.name “自己的中文名字”
介绍
- *Production 分支（生产分支）
也就是我们经常使用的master分支，这个分支是最近发布到生产环境的代码。并且master分支不允许又任何提交记录。仅接受来自功能分支（feature/fix）的 PR 或 热修复分支（hotfixe）的 cherry-pick（下文简称为 CP）
每个合到master分支上的提交都要加Tag
- *Develop 分支（开发分支）
develop 分支用于日常开发，作为功能的聚合分支，存放最新的开发版本。并且 develop 分支也不允许有任何提交记录。仅接受来自功能分支（feature/fix）的 PR 或 热修复分支（hotfixe）的 cherry-pick（下文简称为 CP）同master分支
- Feature 分支（功能/模块/任务分支）
feature/fix 分支是从 develop 分支中 checkout 出来的新分支，每个产品需求或测试的 BUG 对应一个 feature/fix 分支。一旦开发完成并且在本开发周期内要上线，将被要求向 develop 分支提交 PR，待 Review 通过后允许合入；（强制，已推广公司）命名为 feature-xxx/fix-xxx 关联相关产品需求或 BUG（xxx 为 Gitee 任务编号）。
- Release分支（发布/预测分支）
release 分支是每个开发周期初（如每周一）从 master 分支 checkout 出来的新分支，且 release 分支会自动构建测试版本，开发完成并且在本开发周期内要上线的 feature/fix 分支内的所有提交被允许 CP 到该分支就行测试；全部测试通过后由项目负责人向 master 分支提交 PR 合入完成上线；（建议）命名为 release-xx 关联开发周期（xx 可以为本年度第 xx 周）。
- Hotfix分支
hotfix 分支是从 master 分支 checkout 出来用于修复线上发现的严重 BUG；BUG 修复完成后将被要求向 master 分支提交 PR，待 Review 通过后由项目负责人合入，并同时要求向 develop 分支 CP 本次修复的所有提交；（建议）命名为 hotfix-xxx 关联相关 BUG（xxx 可以为 Gitee 任务编号）。
注意：这个分支只允许处理紧急bug，测试或者对接过程中的bug修复，应个人对应的开发拉取develop分支，然后再个人开发分支上进行
l 分支粒度
分支粒度分为两个维度，
- 版本
个人
分支粒度以个人为最小粒度（涵盖开发，bug修复，测试分支等）
注释:个人粒度下，每日提交需要详细到
注意：以一个小功能、小改进或一个 bug fix 为单位
- 对应的 unit test 程序在同一个 commit
- 无相关的修改不在同一个 commit
- 语法错误的半成品程序不能 commit
- 少量的无归属修改可以酌情合并commit（commit —amend命令）
- 严禁一个任务分支feature-xxx开发多个功能
- 严禁一个提交设计多个不相关功能，任务，模块等
提交管理（个人分支commit）
1.commit代码需将代码粒度区分至模块，接口，文档，注释，等。
粒度区分完毕再以做的事情来作为命名此次commit提交，见第2点
优点：有助于同事的code review，个人版本的回退等，规范化也使得提交赏心悦目
2.粒度区分完毕后，commit的信息规范如下（推荐插件Git Commit Template）
图2.1
- feat：新功能/模块（feature）
- fix：修补bug
docs：文档（documentation）- style：不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等，没有改变代码逻辑)
- refactor：重构代码(既没有新增功能，也没有修复 bug)
- perf：代码性能提升（个人建议合到refactor分支，因为性能提升往往伴随着重构）
- test：新增测试用例或是更新现有测试
- chore：构建过程或辅助工具的变动（pom新增依赖，逆向工程等）
- revert：回滚某个更早之前的提交
3.插件使用
commit消息包含三个部分，header（必需），body（可选）和footer（可选）见图2.2
作者建议：写header就好，header所包含的三个子部分，就足以涵盖提交要素 见图2.3
图2.2
图2.3（红色为必写）
图2.4：生成的commit消息
3.3.开发任务数据留存及疑难问题解决
在开发任务确定，经过开发负责人，具体开发者，其它同事等沟通讨论定稿后，需要将具体需求功能实现方式、解题思路、拆分子任务思路、以及涉及的一些开发数据等在企业文档中详细记录留存，以便于后续开发者维护。
另外如果同一个问题，经过三次开发以后还未实现客户需求，产品经理以及构架师需及时抛出问题，反馈到部门负责人，寻求外部技术支持，包括找对应技术外包公司等解决问题。
4. UI设计规范说明
4.1.UI任务管理
在Gitee中，当需求评审完成后，产品可以直接指派UI设计任务进行UI设计，在设计之前UI需要与产品充分沟通后，确定方案，最终出设计稿。
当对应开发人员完成需求开发后，需要指派对应人员进行UI审核，UI审核通过后，可以提交QA测试；
4.2.UI设计规范
- 清晰的层次和表达；
2. 遵循“简洁不简单”的设计原则；
3. 风格的一致性；
4. 视觉协调性；
5. 站在用户的角度设计。
UI审核打回规范：
如果提交UI审核过程中，发现UI还原度<60%，对应UI审核人员需将改功能驳回重新开发，记录并通知对应负责人。
4.3.UI数据留存
UI设计完成后，需要将对应的设计稿以附件或是以链接形式放到对应的企业文档需求目录下留存，如有必要，可输出UI设计思路，实现方式等留存。5. QA规范说明
5.1.测试任务管理
在开发任务完成后，产品审核以及UI审核通过后，开发将任务指派对应QA测试，测试通过后及时输出验收报告。5.2.测试规范
- 所有涉及需求测试需要准备测试点输出，如果是大版本计划要提前准备测试计划
2. 提交bug统一bug库，禅道跟踪管理
3. 测试过程如有条件采用交叉测试方式测试，一个需求至少2人跟踪测试，避免遗漏试问题
4. 提交问题需提交到具体插件版本下面【插件名称】【具体模块】XXX
5. 及时处理客户提交问题并打标，紧急问题需要紧急跟进直至解决
如有以下问题，测试可直接打回开发任务并通知对应人员：
1. 提交测试版本功能或需求涉及对应模块崩溃类不超过2个
2. 重大设计缺陷（开发最终效果图严重不符）
3. 提测版本功能或环境阻塞测试情况
测试验收通过标准：
5.3.测试数据留存及验收
整个测试完成后，QA需要将对应需求测试测试点，以及验收结果输出到对应的企业文档目录下进行数据留存。6. Gitee任务全流程示范（demo）
6.1.新增项目仓库
- Gitee中我们新增一个示范项目，并新增仓库
根据项目计划我们新增2个仓库：ShiFan_MiniProgram_Master（示范项目小程序主库）；ShiFan_MiniProgram_BackStage（示范项目小程序后台库）；
6.2.规划里程碑
根据项目规划，我们近期需求是规划到0930全部实现，那么根据里程碑规范，我们可以规划三个版本里程碑来实现全部需求：示范项目V1.1.0；示范项目V1.2.0；示范项目V1.3.0；
新增里程碑
里程碑要关联具体仓库，否则pr的数据统计关联不上
完成后，可在里程碑查看具体里程碑规划：
6.3.新增需求任务
根据我们的项目规划将新增-需求任务放入到具体里程碑下管理
产品同事在该项目中创建一个需求任务，将大致的想法在其中描述，并且把相关的同事添加为此任务的协作者。协作者可以对任务进行评论或者编辑，当然如果需求过大也可以通过子任务拆分详细子需求，目前支持无限拆分。
6.4.需求评审
- 需求确定后，新增-需求评审子任务发起需求评审，上传对应需求原型图，评审思考单。
2. 验收通过后，UEA评论给出验收反馈，评审任务状态改成已完成，评审反馈同时记录到企业文档留存。
3. 产品需求确定并验收通过后，产品在企业文档根据里程碑新增文档，将评审完成最终的产品文档以及评审思考单放到对应需求下留存。
6.5.UI设计任务
需求评审通过后即可进入UI设计阶段，产品在需求下面新增UI设计任务，或是同时增加UI设计任务和开发任务，开发任务中设置UI任务为关联前置任务（关联前置，只有完成UI设计后才可以进行开发任务），UI编辑任务增加对应负责人以及协助者等，具体想法和实现直接在任务下面评论；
产品同时新增UI设计任务以及开发任务示范，开发任务-关联任务，设置顺序为“紧前” 关系释义设置为“FS：结束->开始”，紧前的意思是UI设计为开发任务前置任务，关系FS的意思是，只有UI设计任务完成后，才可以进行开发任务。其他选项，具体释义可以直接参考界面说明。
设计完成后，对应任务附件上传对应的设计稿，同时将任务状态变为完成
数据留存，对应企业文档需求目录下上传对应附件，如果附件超过100M，也可新增文档附录对应的链接
6.6.开发任务
UI设计完成后，通知产品新增开发任务，具体开发的同事在该任务中，将大致的想法在其中描述，并且把相关的同事添加为此任务的协作者。协作者可以对任务进行评论或者编辑，最终讨论确定开发实现步骤以及拆分思路。
开发根据具体实现方式以及拆分思路，细化开发任务，开发大任务拆分子任务，支持无限拆分，子任务的颗粒度建议要到天级别，尽量要细化到0.5-1天之内，任务要有明确的产出标准，便于每天提交代码，查看工作量。
开发任务要关联对应仓库，分支
在确定需求实现步骤以及拆分思路后，需要将具体功能实现方式、解题思路、拆分子任务思路、以及涉及的一些开发数据等在企业文档中详细记录留存，以便于后续开发者维护。
6.7.产品UI审核
开发人员在本地完成自己的任务后，将代码提交到约定远程分支，然后在开发任务新增测试任务分别提交产品/UI验收
测试任务先提交产品审核，打标产品审核，具体问题评论留言
产品审核通过后，打标，提交UI审核，打标
UI审核通过后，添加标签，变更负责人，通知QA进行测试任务6.8.QA测试验收
QA进行测试之前，需要提前将测试功能点，测试思路等以评论或是附件形式上传，测试负责人需审核下在进行测试；
测试通过后，及时验收任务，验收通过打标，在评论区附验收结果，通过关闭任务
测试数据留存，完成后，需要将涉及的测试任务测试点，测试数据，验收结果等留存到对应的企业文档中
6.9.统计数据查看
当我们按照上面流程运转起来之后，就可以通过一些数据来衡量我们的效率问题，从过程指标来看，我们可以用交付的“需求/任务”数、代码量这两个指标来衡量，上面使用了“任务”来管理开发人员承担的”需求“，并且在提交代码时关联了对应的”任务“，那我们就可以在企业视图-统计中看到每个开发人员完成的任务数和提交代码量了。当然了，代码量、任务数并不是全面评估工作效率的唯一手段，但对开发人员来说是一个很重要的可量化的角度。
7. 流程的监督执行与说明
流程是死的，人是活的，规范是大家约定要一起遵守的，但是也不要为了遵守规范而去遵守规范，一切要以产品的质量和效率为重，不断的迭代和更新规范。比如当我们的流程已经可以稳定的运转了以后，我们可能开始尝试推进合作的开发部门测试前移，在需求分析时就确定需求的验收标准，在开发提测前完成主路径的单元测试及相关评测，更有利于产品的快速迭代和持续维护。当流程被长期的遵守并迭代，那么我们整个团队也会互相影响形成良好的文化闭环。
后续的流程规范形成共识统一确定后由UEA监督执行，每周安排时间对每个项目组的使用流程规范情况进行审视，不规范的地方会及时的反馈通报，好的也要及时发出大家学习。
若有收获，就点个赞吧
0 人点赞
