fix img

专栏/微服务质量保障 20 讲-完/17 度量与运营篇：如何度量与运营效率和价值？.md.html

@@ -162,7 +162,7 @@ function hide_canvas() {
 <p>因为交付效率有非常强的相对属性，所以，去度量某一个团队或阶段的效率似乎没有太大意义，投入产出比很低，不如采用相对的方式查看不同团队或阶段的相对效率。因此，可以通过如下维度进行度量。</p>
 <h5>1. 交付周期比、工时比</h5>
 <p>交付周期指一个需求从想法提出到发布到线上的周期跨度，这其中，按阶段又可以分为需求阶段、开发阶段、测试阶段，等等，它们属于交付周期的子集。通常使用周期比、工时比两个指标来衡量效率。其中，周期比是指交付周期中日期的实际跨度（排除节假日），工时比是指实际投入的工时，一般以 PD（Person Day 即人日）为单位。</p>
-<p><img src="assets/Ciqc1F9aBdqAbxgcAAByrfGDeno440.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F9aBdqAbxgcAAByrfGDeno440.png" alt="png" /></p>
 <p>如上图，需求阶段从想法提出、产出需求文档到完成需求评审共跨越了 10 天，因此周期为 10 天。而在这 10 天时间里，共投入了 15 PD。随后，研发人员开始进行技术设计和评审、编码、联调、自测等环节，共跨越 15 天，总投入 60 PD。与此同时，测试人员开始进行测试设计，投入 2 PD。研发人员提交测试后，测试人员开始测试执行，跨越了 5 天，投入 10 PD人力。需要特别注意的是，测试设计阶段的周期是 0 天，这是因为测试设计阶段的周期在开发阶段的周期内，从交付视角看，测试设计并没有占用额外的周期。</p>
 <p>所以，对于这个需求来说，三个阶段的总周期是 10+15+5=30 天，工时投入是 15+60+2+10=87 PD。从周期上看，需求阶段、开发阶段、测试阶段的周期比为 10:15:5，从工时比维度看，需求阶段、开发阶段、测试阶段的人日比为 15:60:12。</p>
 <p>通过上面的数据还可以知道，如果每个阶段只有 1 个人力投入到项目中，那么该阶段的周期数应等于工时数。周期数大于工时数时，意味着在项目交付过程中有挂起或等待的时候。工时数大于周期数，意味着利用周期内的节假日进行了赶工（也就是加班）。无论是等待还是加班，都属于非正常情况，需要深入分析，使项目交付过程正常化。同样，每个阶段有多人投入的情况也是如此，只不过涉及多人时，需要弄清楚在每个阶段，多个人是如何参与和协同的，分析复杂度也将有所提高。</p>
@@ -171,7 +171,7 @@ function hide_canvas() {
 <blockquote>
 <p>累积流量图由精益思想的创始人 Don Reinertsen 和 David Anderson 引入。它是一个综合的价值流度量方法，通过它可以得到不同维度的信息，反应 WIP 的状态、项目的步调、并且快速识别出交付时间存在的风险以及瓶颈。它是追踪和预测敏捷项目的重要工具。它从不同方面描述工作：总范围、进行中和已完成的。</p>
 </blockquote>
-<p><img src="assets/CgqCHl9aBeSAGULSAABY0WhIW08217.png" alt="image" /></p>
+<p><img src="assets/CgqCHl9aBeSAGULSAABY0WhIW08217.png" alt="png" /></p>
 <p>如上图，黑线代表不同时间点，需求评审完成进入开发阶段的需求个数；红线代表不同时间点，开发人员提交给测试人员进行测试的需求个数；绿线代表测试人员完成测试，等待发布到生产环境的需求个数。同一时刻，黑线和红线的差值表示待开发任务的“堆积”，红线和绿线的差值表示待测试任务的“堆积”，反映了交付过程中的开发和测试效率瓶颈。</p>
 <h5>2. 吞吐率</h5>
 <p>吞吐率是单个阶段的效率衡量，它表示单位时间内，团队能够交付多少产出。产出这个词听起来比较“虚”，软件产品交付不是计件工作制，因此很难完全标准化。比如，同一个人，一天时间编写了 500 行代码，第二天编写了 300 行代码，那么它哪一天的效率更高？两个人，一天的时间分别编写了 500 行代码和 300 行代码，哪个人的效率更高？很难判断。</p>
@@ -206,21 +206,21 @@ function hide_canvas() {
 <li>测试团队视角</li>
 </ul>
 <p>测试团队视角主要查看团队人数、团队内分工、测试技术建设和测试团队的需求吞吐率等信息。</p>
-<p><img src="assets/Ciqc1F9aBfmACNNeAABebK14DKQ976.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F9aBfmACNNeAABebK14DKQ976.png" alt="png" /></p>
 <ul>
 <li>测试人员视角</li>
 </ul>
 <p>测试人员视角主要查看测试人员本身的问题。</p>
-<p><img src="assets/CgqCHl9aBgOABXVLAACFQBPPpf4829.png" alt="image" /></p>
+<p><img src="assets/CgqCHl9aBgOABXVLAACFQBPPpf4829.png" alt="png" /></p>
 <h5>3. 项目组视角</h5>
 <p>分析了测试人员的效率瓶颈外，还可以扩大关注圈到产品交付过程视角，针对每个阶段进行区别分析。因为测试阶段之前的阶段出现问题，会导致测试团队花更多的力气去调整和适应，且更容易在过程中出现各种各样的非预期问题，遗患无穷。</p>
-<p><img src="assets/Ciqc1F9aBg2AP2suAACqSl_5IF8597.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F9aBg2AP2suAACqSl_5IF8597.png" alt="png" /></p>
 <p>这里说一下我自己的经历，我分析过比较多的反馈测试人员资源不足类的实例，最后发现根本问题有两个：一是测试人员的效率的确可以再提升，二是由于项目规划导致，项目规划时没有把测试人员当作是一种必备资源进行整体考虑和预排期，而是直接按顺序排时间，等到了测试人员排期时才发现不符合预期，于是想当然地产生了“测试人员人再多一些就好了”“测试人员效率再高一些就好了”的诉求。当然，每个项目和团队的问题总是千差万别，建立起分析框架，遇到问题时多维度分析，以不变应万变。</p>
 <h3>价值度量与运营</h3>
 <p>无论是保障质量还是提升交付效率，都是在“如何正确地进行产品交付”这个维度上，那么如何确保产品本身是正确的呢？即，产品本身传递了正确的价值，这就需要对价值进行度量。</p>
 <h4>价值度量指标</h4>
 <p>无论产品形态是怎样的，产品价值不外乎是业务层面的价值体现和技术方面的价值体现，如图所示：</p>
-<p><img src="assets/CgqCHl9aBhuAZAG1AAFF3SLG8Pg504.png" alt="image" /></p>
+<p><img src="assets/CgqCHl9aBhuAZAG1AAFF3SLG8Pg504.png" alt="png" /></p>
 <p>产品价值度量指标</p>
 <p>这些指标不难理解，这里不再赘述具体含义。</p>
 <h4>价值闭环运营</h4>