这是我在总结 团队研发流程探索思考 后，对团队研发流程改进的实践总结。
最开始的团队研发流程
- 沟通工具：slack
- 项目管理工具：tapd、腾讯文档
- UI交互：蓝湖
大致的研发流程：
- 产品出需求，给出需求文档和交互原型，需求文档使用腾讯文档或者写在tapd里面，交互稿和UI使用的是蓝湖
- 产品在出完需求，UI/UX出完交互UI稿之后，会直接拉上开发进行需求评审，评审会针对需求、UI中的问题进行沟通协商
- 不管有没有问题，开发都会开始进行需求开发，因为时间不等人，而在需求评审中存在的问题，需求文档、UI、交互稿都需要修改，开发过程中，也可能会发现问题，此时则是通知产品UI交互他们进行沟通并修改。
- 开发完毕后，通知测试人员进行测试，测试发现的缺陷会放到tapd中
- 测试完成后，会通知开发，开发进行缺陷修复，如此反复，直到缺陷为0，通知产品
- 由产品通知，准备发版
存在的问题：
- 产品需求文档不规范，没有固定格式，且需求文档没有体系的进行整合
- 产品出需求、UI/UX出交互UI稿，然后直接拉上开发进行评审，由于开发没有提前了解需求，也没有和开发提前沟通需求，导致评审过程中可能会发现需求中的较大问题，以至于整个评审的时间以及评审后的需求、UI/UX返工可能会比较大，白白浪费时间。
- 没有具体的流程流转，比如需求到正式开发，以开完会为主，开发完成到测试，是以沟通工具中的通知为主的，且测试完成也是以通知为主，通知作为流程控制很难规范，不同人的通知可能有差异，而且，作为项目状态很难被重复确定（难道每次都要翻记录去看看测试有没有说测试完成吗？）并且，消息容易被人忽略，或者别人忘记了。
- 整个研发都没有较为完整的信息记录和具体的步骤，对于某个需求、某个迭代的所处的研发状态无法很好的追踪，也就是研发流程开起来会很混乱，谁在做什么，做到哪一步了都无法很好的追踪。
上面的研发流程，存在如此多的问题，而且还会有一些细节没有展露出来，比如临时需求问题等。面对较为不规范的研发流程，我们自然需要去探索和优化我们的研发流程。
改进的研发流程
- 沟通工具：飞书
- 项目管理工具：pingcode、飞书文档
- UI交互：蓝湖
研发流程阶段定义
需求阶段
此阶段通常是产品进行需求调研、需求分析的阶段，通常其会输出需求文档和需求原型到飞书的知识库中（每个项目在知识库中都存在一个子项）。通常，这个阶段除了确定需求，产品还会考虑需求的排期，产品需要了解现在开发在做哪些需求，什么时候完成，并且需要评估需求的优先级，而需求划分之类的产品工作细节这里就不再赘述了。
待需求文档完成后，通常会进入预评审阶段。
该流程的具体体现为：按照需求分级，在项目管理工具中建立相关的需求项。
需求预评审阶段
这个阶段主要是让产品将需求文档和需求原型同开发以及UI/UX过一遍，其作用是为了提前将需求和他们过一遍，以防止有明显的需求不合理和需求无法实现的问题，导致在正式需求评审后的大范围修改，当大致功能过了一遍，且一些细节上没有问题之后，才会进入UI/UX的设计阶段。
这里也是为了让开发和UI/UX可以先一步针对一些UI和交互上的问题进行提前沟通，防止后续的返工。
这个阶段，通常不是所有的开发人员，而是相关的项目负责人去参与即可，不过在预评审通过后，会将相关需求给到相应的开发组，他们可以提前了解需求。
该流程的具体体现为：产品会组织一个需求预评审的会议，并邀请相关人员参与。
UI/UX阶段
当产品输出需求文档和需求原型并经过预评审之后，UI/UX会针对需求进行详细沟通以便理解需求，之后UI/UX会基于需求输出UI稿和交互稿。这个阶段所产出的UI/UX产品会先过一遍，以确定需求没有理解错误以及UI/UX的合理性。
该流程的具体体现为：当确认完成后，会由产品预订需求评审会议，并通知相应的：开发、测试等，并将产品需求文档、UI和UX稿发给他们，让他们提前先过一遍，为正式需求评审做准备。
需求评审阶段
这里是正式的需求评审阶段，产品会拉上相关人员，比如开发、测试、UI/UX等来对接整个需求，同时也会对UI/UX进行评审。即使存在预评审，仍然无法保证需求、UI/UX没有问题，但是索性经过预评审，需求的大框架基本不会有问题，更多的只是细节上的确认，如果相关的人员对需求或者UI/UX有疑问，会在评审会议上提出来并进行沟通解决。
评审完成后，开发会给出该功能的大致开发时间，测试也会给出大致的测试时间，然后，基于现有任务和需求优先级，进行排期。
如果需求评审过程中，发现需求过大，那么会考虑将需求拆分为迭代。
该流程的具体体现为：产品会组织一个需求评审的会议，并邀请相关人员参与，待需求评审结束后，产品会为此次评审的需求建立迭代，并填写相关的时间。
开发阶段
这个阶段自然就是开发根据需求、UI/UX进行真正的业务开发了。按理来说，开发在需求评审阶段过后进行业务开发，而测试在需求评审阶段过后，会编写测试用例。不过如果是需求比较大或者存在一些技术问题或者难点，那么开发会预留时间进行技术评估和讨论实现方案。如果是较小的需求，以及一些业务逻辑改动，则一般会直接进入到实际开发阶段。
通常开发在理解完需求之后，后台会针对需求给出接口定义文档，前端基于接口文档进行业务开发，待后台接口具体实现之后，再进行接口联调，以达到前后端并行开发的目的。
如果在开发过程中仍然发现存在问题，会和产品、UI/UX再次进行沟通和确认，然后会通知其他所有需要知道改动的人员，比如测试、其他开发等等，以确保信息的同步。但基本上在这个阶段不会出现很大的问题。
在这个阶段也可以进行代码Review
测试阶段
当开发完毕后，会由开发提交测试，此时进入测试阶段，测试会进行功能测试、UI/UX还原性测试，如果存在缺陷，则录入缺陷然后交由开发修复，此过程可能会重复1到2轮。
该流程的具体体现为：
- 当开发完成业务开发且自测通过后，会通过一个
提测文档，将需要提测的内容和相关信息（比如url、账号密码等等）填写到提测文档中，然后通知相关的测试人员，而测试在收到该提测文档后，会对项目进行测试。 - 当测试不通过（存在缺陷）时，会填写一份
测试报告通知相关人员（开发）测试不通过，需要对缺陷进行修复。而测试如果通过，则会填写一份测试通过的报告，提交给产品，产品确认无误，会将pingcode中的迭代标记为已完成。 - 至此整个需求算是开发完毕，开发在收到测试通过报告后，会将相关代码合并到待发布分支，等待产品通知发布。
版本发布
当一个功能开发完毕，产品觉得可以发布时，可能立即发布，也可以后续和其他功能一起发布，这个由产品决定，且在最后确定版本时确定需要发布的功能。
该流程的具体体现为：
- 产品在确定版本发布时，会选择需要发布的迭代，在pingcode中建立一个版本，并通过邮件的形式通知开发在何时发布哪个版本，并通知相关的销售、运营人员。
- 开发在收到邮件通知后，查看相关待发布的版本中包含哪些功能，并准备发版：版本号更新，代码合并，tag标记等等。通常发布这一步由相关的前后端核心开发人员完成。
- 开发正式发布完成之后，会在邮件中回复版本已发布完成，此时，测试和产品会去生产环境做回归并确认。
- 待产品确认完成后，会在pingcode中的版本标记为已发布。至此，该需求迭代已全部完成。
其他优化
产品、UI/UX文档规范
在之前，我们也提到了产品文档的规范问题，不同产品之间如果输出的文档不规范，那么会给其他所有部门理解需求上带来较大的心智负担，而且对于后续的新人也会带来不小的麻烦。所以，相应的文档规范是非常有必要的，具体的细节这里就不展开了，这里只是作为一个需要注意的点提一下。其实不止是产品、UI/UX文档，后台的接口文档、开发文档、项目文档都是一样的，都需要进行规范编写。
需求文档、交互文档、UI文档都包含不同细节
在整体的研发流程中，存在了三个不同的文档：需求文档（产品文档）、交互文档、UI文档，这三个文档分别包含了不同细节，需求文档描述需求，交互文档体现交互逻辑UX，UI文档描述UI，而三者可能存在不一致：比如需求评审过后，或者后续开发过程中，存在需求或交互不合理时，需要进行改动，他们不一定同时修改完成，这里存在一个信息同步问题。而且，开发（比如前端和测试）需要查询3个文档才能知道所有的需求和功能细节，且他们如果不一致，则以谁为主也很难确定，这会导致不同开发的理解、测试的理解都很难统一。
目前，还感觉没有一个能在清晰的表述各自文档的不同部分细节的同时，还能将文档合并为一份的办法。我们目前的一个方案就是做一个约定：需求理解以产品需求文档为标准，交互逻辑以交互文档为标准，UI展示以UI文档为标准。而他们不一致的问题，只能加强沟通了。
实践中的问题
以上只是研发流程的制定，在真正推行过程中收集到的反馈来看，还是存在一些问题：
- 测试根据需求文档和原型进行测试用例的编写，一些功能上的细节和产品边界是无法体现在需求文档和交互中的。可能只有开发知道一些细节，很有可能导致测试无法对功能测试全。
- 开发过程中的需求、UI/UX更改时，其通知的及时性该如何保证
- 提测流程较为麻烦，需要填写提测文档，而如果只是单纯的缺陷状态修改，那么会存在如下问题：测试何时测试完成？开啊何时缺陷修复完成，测试何时进行下一轮测试？单纯的缺陷状态无法体现这一点。
- 实际过程中的发布流程：如果是稳定的项目且拥有了CI/CD流程的项目还好，只需要项目的负责人或者核心开发者可以完成项目的发布流程，但是如果是一些小项目或者项目的开始之初，则需要提前考虑项目部署问题。
问题1和2目前只能通过加强沟通的方式来解决
而问题3的话，我认为只能简化提测流程本身，因为提测和缺陷修复本身并不是单纯的单向状态流程，他会重复几轮，且最好是：一次测试、一次缺陷修复、一次测试这种一整个状态流转，所以，单纯的缺陷流转我认为不太满足需求，因此，最好的办法只能简化提测文档的格式和提测复杂度了。
对于问题4，我认为标准成熟的CI/CD是最好的解决方案。
临时需求和任务：防止开发被打扰
有时候，产品和销售、运营有一些临时的任务需要开发处理，他们可能会直接找到相应的开发人员去解决，此时就可能打断开发当前的任务进度，这种临时插入的任务很多时候都不是最急和最重要的，但是这可能很影响开发和开发进度。
解决方案：如果开发有任务排期，那么有了新需求或者一些临时任务，不应该直接找开发，而是找相应负责人，由他安排和过滤并考虑需求任务的优先级，将任务延后或者安排给其他没有任务安排的人，只有出现真正重要且紧急的任务时，不得已才去打扰开发人员，但此时也需要做好需求安排。
并非所有需求都适合这个完整流程
这个流程属于公司研发流程的规范步骤，按理来说，所有需求开发都应该按照这个流程去走。但是也是因为它是所谓的规范，所以整体流程的步骤较多且较为完整，涉及的部门、角色也比较多，如果是一些小需求和临时需求，或者说缺陷修复，如果依然走这个流程，那么其所太过繁琐，且时间上也无法满足，所以，我们应该灵活的对待这个研发流程，在一些场景下可以适当简化，比如：
- 如果是临时小需求，且非常简单就能理解的，那么直接由产品建立需求，通知相关负责人进行安排，快速完成即可，然后走提测，基本上只需要一轮就能完成。
- 如果是生产环境的缺陷修复，那么直接由产品或者测试建立缺陷，由开发完成缺陷，测试进行测试，然后由产品决定何时发布即可。整个过程可以通过沟通工具完成。
其他尝试
- 完全通过需求和缺陷状态来进行状态流转，但这样发现其维护麻烦，且无法体现阶段性的状态流转
- 使用流程审批来完成需求和迭代的状态流转，这个就更加繁琐了。
- 使用表格来将项目和需求记录下来，并以此来记录需求的状态流转，但是这种形式其维护很难辐射到所有人，且无法记录工作内容，只能记录需求状态。太过原始。
总结
就如在 团队研发流程探索思考 中所说的一样，研发流程不是一成不变的，它需要根据公司实际情况来制定，以上的流程是根据实际中所接触和实践到的研发流程制定的一个总结，它不一定能适应所有场景，但是我希望总结出来能带给一些人作为参考。