xinyin025/learn.lianglianglee.com
1
0
Fork 0
mirror of https://github.com/zhwei820/learn.lianglianglee.com.git synced 2025-11-17 06:33:49 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix img

Browse Source
This commit is contained in:
by931
2022-09-06 22:30:37 +08:00
parent 66970f3e38
commit 3d6528675a
796 changed files with 3382 additions and 3382 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
专栏/微服务质量保障 20 讲-完/10 流程规范篇：高速迭代的研发过程需要怎样的规范？.md.html
View File

@@ -163,7 +163,7 @@ function hide_canvas() {
<li>售后服务阶段。它主要由客服人员或售后工程师主导，包括解答或解决用户在使用产品后产生的疑问和投诉等。</li>
</ul>
<p>产品研发阶段是指需求产生到需求上线的过程，这阶段是测试人员的“主战场”。但这三个阶段共同组成了整个业务流程，要做到全流程质量保障，需要具有全局思维。即<strong>积极影响产品研发阶段</strong>，推动流程规范的制定、建设和完善；<strong>对日常运营/运维阶段和售后服务阶段保持关注</strong>，定期收集这两个阶段中遇到的问题，做好协同和配合，思考在产品研发阶段如何预防或闭环解决这类问题。</p>
<p><img src="assets/CgqCHl87m3iAXfC1AACy09bRN3E695.png" alt="Drawing 0.png" /></p>
<p><img src="assets/CgqCHl87m3iAXfC1AACy09bRN3E695.png" alt="png" /></p>
<p>关注圈&amp;影响圈</p>
<h3>产品研发流程规范要点</h3>
<p>好的流程规范（Process specification) 能够保障业务稳步进行，使各部门各司其职。要想使产品研发阶段能够有条不紊地进行，就需要制定和执行流程规范。产品研发流程大体分为需求阶段、研发阶段、测试阶段、发布阶段等，每个阶段都需要有相应的流程规范，从而把需求变成软件产品并发布到线上。</p>
@@ -205,7 +205,7 @@ function hide_canvas() {
<p>当然，规范的制定与落地，还需要结合人员配备情况、工具建设情况协同来看。</p>
<h4>规范如何呈现？</h4>
<p>流程规范涉及多方协作，其呈现形式的第一要点应为<strong>通俗易懂</strong>，一图胜千言，建议采用流程图的方式来展现，比如使用泳道图。</p>
<p><img src="assets/CgqCHl87m6-AB5XhAAw01YGdoL8801.png" alt="Drawing 2.png" /></p>
<p><img src="assets/CgqCHl87m6-AB5XhAAw01YGdoL8801.png" alt="png" /></p>
<p>泳道图示意图</p>
<blockquote>
<p>泳道图，一种 UML 活动图，能够清晰体现出某个动作发生在哪个部门，常见工具有 StarUML、Rose、Visio 等。泳道图在纵向上是部门职能，横向是岗位（有时候横向上不区分岗位）。绘图元素与传统流程图类似，但在业务流程主体上，通过泳道（纵向条）区分出执行主体，即部门和岗位来。</p>
@@ -214,7 +214,7 @@ function hide_canvas() {
<p>基于此，产品研发阶段的流程可以包含如下内容：</p>
<h3>产品研发阶段</h3>
<p>产品研发阶段又进一步分为需求阶段、研发阶段、测试阶段、发布阶段等。</p>
<p><img src="assets/CgqCHl87m92AUVrRAAC28aNzBao783.png" alt="image" /></p>
<p><img src="assets/CgqCHl87m92AUVrRAAC28aNzBao783.png" alt="png" /></p>
<h4>（1）需求阶段：产品需求评审</h4>
<p>产品需求评审是产品研发阶段中非常重要的环节，通过它可以确保需求表述上没有歧义。需求文档通常的表现形式是产品需求文档（PRD）或市场需求文档（MRD），它们也是技术设计文档和测试设计文档的重要输入，所以这一环节是后续所有工作的基础。</p>
<p><strong>评审要点</strong></p>
@@ -229,7 +229,7 @@ function hide_canvas() {
<p>常见的需求表述问题有“同线上逻辑”“同已有逻辑”，或者一句话的概况描述，如“每种状态都需要处理”，却不说明一共有几种状态，这些都非常容易产生理解上的偏差，应该予以杜绝。</p>
<p>其中，<strong>测试人员尤其要重视需求的可测性。</strong> 早期提出可测试性方面的问题和风险，可以及早应对，从而降低项目风险。否则，到了后续的环节才发现需求不可测，这可能会导致需求变更或技术实现方案的变更，这对质量和效率的影响就太大了。</p>
<p><strong>测试人员如何参与需求评审？</strong></p>
<p><img src="assets/CgqCHl87m7qAQWKQAAE2Bwd7NNk811.png" alt="Drawing 3.png" /></p>
<p><img src="assets/CgqCHl87m7qAQWKQAAE2Bwd7NNk811.png" alt="png" /></p>
<p>对于测试人员来说，在要进行需求评审或技术设计评审时，通常情况下还在另外一个需求的测试执行过程当中。测试执行过程通常需要投入较高的专注度，所以很多测试人员最最容易出现的情况是，<strong>弱化需求评审或技术设计评审环节，投入度较低，等其他需求测试完成了再花精力去熟悉它。</strong> 殊不知，这就造成了长期的恶性循环。<strong>正确的做法是，强化需求评审或技术设计评审环节，投入较多的精力，前置思考好一个需求中的重点、难点、风险点，提前应对</strong>。如果与测试执行时间有一定的冲突，则可以优先投入更多的个人时间来化解，同时在后续的测试执行过程中留有一定的 buffer，几个需求过后，你就会进入一个良性循环。对其他关键的评审环节，如技术设计评审也同样适用。</p>
<h4>（2）研发阶段：技术设计评审</h4>
<p>技术设计主要评审是否满足业务需求的功能和非功能质量属性，以及发布方案是否完备。</p>
@@ -256,7 +256,7 @@ function hide_canvas() {
<p>如果前面的阶段完成得较好，测试执行阶段和发布阶段就会轻松很多。在这两个阶段，只需要按计划执行，出现风险时要及时并充分地暴露出来。</p>
<p>其中，测试执行阶段会涉及缺陷管理、测试总结与分析、测试报告编写等工作，这些是测试人员的看家本领，此处不再赘述。发布阶段需要前置准备发布内容、采用既定的发布策略，发布完成后实时观察线上日志、并进行线上回归。发布过程如果出现问题，切忌不要在线上解决问题，应立即回滚。线上回归完毕后，需持续关注监控指标，对告警进行及时响应。</p>
<p>这里给出了产品研发的流程图，从该图中可以看出来各个职能角色的关键活动和活动状态流转。其中，所有的“菱形”环节都是需要 PM、RD、QA 三方参与的。</p>
<p><img src="assets/Ciqc1F87m_yAVZrZAAEicbx-lP4999.png" alt="Drawing 4.png" /></p>
<p><img src="assets/Ciqc1F87m_yAVZrZAAEicbx-lP4999.png" alt="png" /></p>
<p>产品研发阶段流程规范</p>
<h3>实践经验和认知</h3>
<p>好的流程规范能够保障业务稳步进行，使各部门各司其职。但它也不是万能的，这里给出一些实践经验和认知，供你参考：</p>