工作流

目录

说明

工作这么久，发现每家公司都有自己的工作模式，我自己想梳理下流程、节点等。也会表达我对其中一些内容的观点和想法。😅

需求排期

无论是自研项目还是外包项目，需求都是源源不断的。但是，大概率会有 优先级、需求拆分、人力安排 等考虑因素。那么如何安排和调用资源，也是非常重要的。

需求排期的目的是方便开发人员能够提前感知未来需求的方向和大致的工作量，也是 迭代研发 的一种体现。

需求评审

评审内容一般包含：需求背景、功能模块、页面交互、视觉风格、数据统计、需求时间、需求思路等。

  • 需求背景：需要告知各个资源单位满足你的需求的原因，不能是毫无可行性的、命令式的去要求别人莫名其妙的去某件事情。另外也能帮助到研发区评估整个需求中的核心需求点。
  • 功能模块：最好以列表形式呈现，因为如果只是单纯的表达，其实很容易出现漏点、扯皮。其实这样也会让测试人员非常舒服。
  • 页面交互：每一步、每个流程都需要体现在产品上，那么交互很重要，前端和后端都需要基于此判断前后端调用时机或者如何设计(例：是否异步、是否可以将多个接口收拢至一个等)。
  • 视觉风格：契合产品定位即可。非专业UI，不做过多理解。🥲
  • 数据统计：无论是UV、PV、GVM还是其他指标的数据，都是应该提出，方便研发在设计库表的时候考虑到数据统计，最好也是用列表形式呈现。
  • 需求时间：Deadline... ☠️
  • 需求思路：某些功能、交互、视觉点为什么要设计成这样，理由是什么，不是必要因素，但是是专业性的体现、更有说服力。

核心要素 ！！！

  1. 开会必须要有结论，且有落地(文档或其他)，没有结论就是浪费时间。
  2. 会上存疑或者当场无法定论的点，会后应当及时反馈，且最终输出到指定的需求文档上。
  3. 不要有部门之间的政治博弈，或者为了 Battle 而争执无关紧要的点，抓住核心要素，抓大放小。

编码实现

输出内容：接口文档、设计文档、测试分支代码。

对于旧有代码的改动，应该遵循：

  1. 尽可能遵循之前的抽象分层和代码风格。
  2. 复用之前已有的函数封装和工具类，避免重复揉轮子。
  3. 不要随意修改之前已有的代码来适应新的需求。可能别人的代码有过多的兼容。(´థ౪థ）σ

新增功能或起始项目，应该遵循：

  1. 按照指定规范进行设计和编码。
  2. 适当冗余即可，不要为了冗余而冗余，因为需求总是在变化和迭代的。
  3. 各类文档要写的完整和漂亮，好的开始是成功的一半。

代码测试

  • 根据测试用例进行功能自测。
  • 在测试环境进行初步压测。

联调

前后端在测试环境进行页面调用测试，跑通需求列表。

注意

在需求评审结束后的编码过程中，应尽量和前端开发多沟通，表述下自己的思路和能提供的API或者接口都有哪些功能，不然到这里前后端容易干仗。

用例测试

测试人员介入进行流程性功能测试，会覆盖完整的业务流程，该阶段会发现很多没有注意到的细节，我们需要根据测试结果及时修复出现的问题。如果前期 没有发现一些问题，那么会出现新增接口或者推翻之前的一些代码，那么工作量会在测试介入后有一个小的增加点。这里也能体现出需求评审时沟通的效果。

CR

开发工作完成且测试通过后，我们需要进行提交代码，让相关人员进行代码评审(code review)，这一步可以让别人站在 编码规范、封装合理、功能漏洞 等方面做出意见性修改。

注意

  1. 这里需要编码人员主导，条件可以的话，可以投屏一起讨论和讲演。
  2. 不同的开发，能力、思路、习惯等都是不相同的，CR可以帮助大家代码质量、风格等形成统一和把关。

灰度(冒烟测试)

部分用户进行测试和体验。有不好的地方，这里是正常流程中最后可以修改的节点，开发人员要格外注意。

发布

发版上线！！！🎉

复盘

围绕：研发过程中 遇到的问题、如何解决、代码亮点、产品思路 等多方面进行复盘。这里建议落地文档。

好的复盘是可以站在更高的维度来审视整个过程和产品，也是提升自己很好的方式和途径。我本人受益匪浅。

￣□￣｜｜

持续施工 🚧