研发流程不只是一个流程
<p>以人治天下，贤则大治，不贤则大乱。</p><p>以术知天下，术高多宵小。</p>
<p>以法治天下，法令莫不从，民生定。</p>
<p><img src="https://img2023.cnblogs.com/blog/603942/202306/603942-20230621162905380-896674756.jpg" alt="image" loading="lazy"></p>
<h1 id="一总要有个流程">一、总要有个流程</h1>
<p>作为一个研发，你最讨厌什么？</p>
<p>"小功能，十分钟能搞定吧！"</p>
<p>"需求都清楚了吧，明天老板要看效果！"</p>
<p>"有个急事，插一下！"</p>
<p>"这个地方，还要调整下，稍后给你更新的文档！"</p>
<p>"这个当初肯定不是这样定的，是你们的问题"</p>
<p>"代码怎么被覆盖了？"</p>
<p>"测过的代码怎么没上线？"</p>
<p>"这个线上问题是谁谁的变动引起的。"</p>
<p>"这个为什么没测到？"</p>
<p>... ...</p>
<p>需求张口就提，说变就变；开发时间不明确，无法控制；测试不规范，不全面，质量无法保障等等，不一列举。</p>
<p>没有规范约束，没有流程限制，没有章程遵循。 可能对于某些场景会很高效，但问题也是层出不穷。</p>
<p>一个公司成长到了一定的规模，如果还是如上这种，那么唯一的结果只有：混乱。</p>
<h1 id="二需要一个怎样的流程">二、需要一个怎样的流程</h1>
<p>一个完整的研发过程包括哪些活动？</p>
<p>需求 => 开发 => 测试 => 上线。</p>
<h3 id="1需求怎么提">1、需求怎么提？</h3>
<h4 id="a需求阶段需要做什么">a）需求阶段需要做什么？</h4>
<p>确定要做什么 + 做成什么样 + 怎么做</p>
<p>比如：</p>
<p><strong>要做什么：</strong>发表文章的功能页面要改版，以更好的适应用户的操作习惯。</p>
<p><strong>做成什么样：</strong>新的功能布局 + 新的编辑器支持 + 表情符号支持 + 话题插入支持 + 图片编辑支持 + 自动实时保存支持。</p>
<p><strong>怎么做：</strong>输出详细的 prd 需求文档 + 需求评审 + 资源调配 + 排期 + 进度控制。</p>
<p>相对来说，前两步多是产品自身范围内的工作活动，是需求的基础。最后一项则是和关联研发人员的协作，支持。以成品 prd 文档作为媒介，进一步展开后续的流程。</p>
<h4 id="b需求优先级界定">b）需求优先级界定</h4>
<p>一个公司会有很多个产品，每个产品负责不同的业务范畴，那么便会衍生出不同方向的需求。</p>
<p>需求有大有小，重要性也不尽相同，所以需要有一个排序的流程。</p>
<p>将所有的需求都摆在桌面上，由上层来结合公司发展方向及公司战略来筛选哪些需要做，每一项的优先级。</p>
<h3 id="2需求评审">2、需求评审</h3>
<p>产品形成成熟的需求文档后，则要进行需求的宣讲，评审。也就是把上述的过程内容阐述给后续流程的研发人员（包括开发和测试等）。</p>
<p>所谓评审，既要评，又要审，也并不会是一锤定音，一遍过。 对需求内容的整体方向，产出，roi等综合进行考评，合适的的方保留，不合适的去掉，可以改进的继续改进。</p>
<p>对于比较大的，比较重要的或者比较复杂的需求，项目，可能需要经过多次评审，多次改进才能最终定稿。</p>
<p>这一流程节点产出是要作为整个研发流程的指导性文件，应该做到不厌繁琐，力求能够尽善尽美。否则越是往后流程的返工，成本越大。</p>
<h3 id="3排期">3、排期</h3>
<p>我们讲一个需求或者项目，即为在特定的资源条件下实现特定的目的。</p>
<p>既定的资源包括时间，人力及设备成本等。</p>
<p>需求周期一般是既定的，比如，老板说下个月什么功能上线，你就得上线，转圜余地不大。</p>
<p>所以涉及到人力需求则要在如上既定时间周期下去安排，调配人力资源。包括开发及测试等。</p>
<p>其它成本包括服务器，网络，外部付费技术资源（安全、校验）等，是不是需要采购新的服务器，是不是需要拓宽网络，是否是需要引入外部的校验API等。</p>
<p>这一阶段，主要是确定每个流程节点的时间需求，确保每个流程能够在合适的时间开始和结束。</p>
<h3 id="4技术方案评审">4、技术方案评审</h3>
<p>需求确定后，流程流转至开发人员，此时，开发人员应根据既定的 prd 需求文档，产出详细的技术方案文件。</p>
<p>闻道有先后，术业有专攻，每个人都有自己擅长的领域。单人主导的技术方案至少要经过交叉人员评审后方可定档实施。</p>
<p>比如，</p>
<p>数据怎么存储？表字段设计的合不合理？需不需要分表？</p>
<p>需不需要介入缓存层？需要哪种形式的缓存？</p>
<p>系统间怎么交互？交互方式？</p>
<p>接口设计是否合理？前后端交互流程？</p>
<p>哪些是核心业务逻辑？哪些业务可以拆分异步处理？</p>
<p>需不需要引入新的技术？</p>
<p>... ... 等等。</p>
<h3 id="5编码开发">5、编码开发</h3>
<p>编码开发其实占用的时间并不多。</p>
<p>就好像炒菜一样，菜品的清洗，准备往往是最耗时的，反而入锅翻炒也就一会儿的事。</p>
<h3 id="6code-review">6、Code Review</h3>
<p>我一直秉信 Code Review 是能够极大保障代码质量的。</p>
<p>Code Review 关注点包括：代码设计、功能实现、复杂性、测试友好性、代码风格、命名、注释、文档等。</p>
<p>Code Review 的形式可以采取代码库流程，或者集体拉会形式等。</p>
<h3 id="7提供测试">7、提供测试</h3>
<p>开发流程结束后，流程流转至测试。</p>
<p>研发环境一般要提供完整的开发、测试、灰度、线上环境区分，以供不同阶段不同流程需要。</p>
<p>这一阶段，开发人员需要将开发结果部署到测试环境，提供给测试人员。</p>
<p>如有必要，也需要提供相关测试数据支持。</p>
<h3 id="8测试用例评审">8、测试用例评审</h3>
<p>测试用例输出及评审通常和开发并行，由技术方案流程确定后起始。</p>
<p>测试人员根据既定的需求及技术方案文档设计测试用例，包括新功能、变动功能及回归功能等。</p>
<p>测试用例完结后，需要和开发人员进行沟通评审，确保测试用例的完整性。</p>
<h3 id="9测试">9、测试</h3>
<p>测试环境及测试用例就绪后，开始流转测试流程。</p>
<p>测试包括功能测试、集成测试、回归测试、灰度测试、线上验证等。</p>
<p>由此节点开始可能需要横跨所有后续流程。</p>
<p>测试往往是产品质量的最后一道防线。</p>
<p>及早发现问题、提出问题应为首要，尤其不要试图掩盖问题。</p>
<p>上线前一秒发现问题都是居功至伟。</p>
<h3 id="10上线验证">10、上线、验证</h3>
<p>功能上线，不同公司可能操作方会略有不同，开发、测试、SRE人员都有可能操作这一流程。</p>
<p>上线后功能验证必不可少，由测试或者产品执行，确保产出和目标相符。</p>
<p>流程至此完结。</p>
<h1 id="三附加订阅">三、附加订阅</h1>
<p><img src="https://img2023.cnblogs.com/blog/603942/202305/603942-20230517142514967-264202955.jpg" alt="订阅" loading="lazy"></p>
</div>
<div id="MySignature" role="contentinfo">
<div id="NJLSig" style="display: block;"><div class="autor">作者：WindWant</div>
<div class="source">出处：https://www.cnblogs.com/niejunlei/p/17496599.html</div>
<div class="copyright">著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。</div></div><br><br>
来源：https://www.cnblogs.com/niejunlei/p/17496599.html
頁:
[1]