86 lines
8.1 KiB
Markdown
86 lines
8.1 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
135 钮博彦：软件研发度量体系建设（一）
|
||
你好，我是美团高级技术经理钮博彦，主要负责美团点评研发工具栈的建设。我今天想跟大家分享的内容是，我们作为平台团队与业务线团队在软件研发度量中的实践及思考。我将从三个方面展开内容，第一，度量的意义；第二，研发度量体系；第三，度量平台建设。
|
||
|
||
度量的意义
|
||
|
||
为什么需要度量呢？因为我们在研发过程中总会遇到各种各样的问题，比如下面这三个典型问题：
|
||
1.为什么我们做的产品与用户的期望总是存在差异呢？
|
||
2.市场需求日新月异，这个功能可能还没开发，需求就已经变化了，对此，我们该如何提高团队的反应速度呢？
|
||
3.现在的产品质量到底怎么样，为什么bug永远修不完？
|
||
|
||
这些问题都是我们在研发过程中经常遇到的，那我们应该如何解决这些问题，使团队更专注、更有效率、更有质量呢？这就是度量的意义所在，我们可以将它总结为三点。
|
||
第一，让目标更明确，比如让大家在项目开始时、研发过程中、项目结束后，对目标有共同的认识。
|
||
第二，让现状更清晰，度量可以告诉我们现状如何、效率如何、质量如何、流程如何以及问题所在。
|
||
第三，让改进更精准，关于如何完善质量流程、体系化研发过程的方法，我们并不缺乏专家学者与著作观点，那怎样找到适合自己团队的观点呢，就需要通过度量来实践。
|
||
|
||
研发度量体系
|
||
|
||
整体的研发度量体系可以从三个维度来考量：即价值、效率、质量。
|
||
|
||
一、价值
|
||
|
||
这里的价值，指的是我们要做正确的事，而不是有效率的做一些错误的事情。以此为出发点去架设研发度量体系，我们就可以思考三个问题，第一，怎样度量我们的团队正在做正确的事？第二，既然明确了正确的事情，我们怎样以最高效率交付它？第三，我们既做了正确的事，又很有效率，那交付是否符合我们的预期，符合用户的预期呢？
|
||
|
||
可能每个公司都有自己的价值指标体系，但整体可以分成两大类，就是商业价值和技术价值，每一类又可以细分为可度量价值与不可度量价值。
|
||
|
||
|
||
商业价值的可度量价值包括钱、订单量、DAU、转化率、停留时间等；不可度量价值则包括影响力、美誉度等。
|
||
技术价值的可度量价值包括QPS、可用性、响应时间、故障恢复时间等；不可度量价值则包括技术竞争力等。
|
||
|
||
|
||
总而言之，不论是宏观的项目还是微观的产品，都会根据不同场景制定不同的度量指标，再根据这些指标，开始研发流程，并在过程中不断迭代，使交付结果越来越好。
|
||
|
||
举个例子，我们要做一个产品，开始立项时，定了一堆项目目标，比如DAU增长目标、订单量目标、技术目标等，跟上面提到的价值度量指标相关联。然后进入功能设计阶段，为这个产品设计了N个功能，以其中的某个功能X为例，接着就进入到功能X的研发流程阶段，包括评估与设计、开发与测试、发布上线、反馈与复盘等。
|
||
|
||
我们在流程实践上的创新之处在于，我们会把项目目标和需求目标相关联，将项目目标作为需求设计的目标之一，从实际结果看这个需求为整个项目目标分担了多少指标，比如做完这个需求，我们可以增长多少的订单量等。
|
||
|
||
其中，反馈与复盘特别重要，在需求上线之后，可能一周或一个月，我们就需要进行复盘，来判断它到底有没有达到预期。我接触的很多团队都会将复盘放到项目结束后，但我觉得在需求设计过程中进行复盘也很重要，相当于定期追踪。
|
||
|
||
因此，我们可以把整个项目流程分为三个阶段，即事前计划、定期追踪、事后复盘。这样做能带来什么价值呢？第一，我们所有的需求都是从价值出发，项目的所有参与人都明确目标，能够提升成就感；第二，拆解高价值需求，更早交付，提升ROI；第三，把控需求质量，减少“三拍”需求，降低部门浪费。
|
||
|
||
二、效率
|
||
|
||
当我们确定价值以后，就需要考虑如何有效率的交付这些价值，我们来看下面这张交付周期图，这是一个非常典型的技术研发流程，包括需求评估、需求设计、待开发、开发、联调、待测试、测试、发布等环节。
|
||
|
||
|
||
那我们如何度量效率呢？有两个核心指标，一是吞吐率，二是交付周期。
|
||
|
||
首先来看吞吐率，吞吐率就是在单位时间内，团队能够交付多少产出。而对于产出的衡量，大家也是各有各的看法，有些团队以需求个数或故事点数来衡量，有些团队以价值来衡量，比如这个团队在一季度内为公司增收的盈利等。
|
||
|
||
我们可以从多个纬度出发综合衡量产出，因为单个纬度衡量可能会有不准确的情况。举个例子，假设张三一年写了1000行代码，李四一年写了800行代码，那张三一定比李四的效率高吗？不一定。再假设李四做了20个需求，张三做了10个需求，李四的效率一定比张三高吗？也不一定。所以，通过综合纬度衡量，可以更加确保对于吞吐率的度量结果的准确性。
|
||
|
||
再来看交付周期，顾名思义，就是一个需求从提出到上线所用的时长，可能有版本交付周期、需求交付周期、故障修复周期等等，这些都属于交付周期的范畴。
|
||
|
||
明确了效率的两个核心指标，下面我们来看如何操作能够帮助我们更好地度量效率。
|
||
|
||
我们在交付周期的衡量中用了两个典型的项目管理工具，一是累计流量图，帮助我们定位瓶颈。如下图：
|
||
|
||
这张累计流量图的横轴是时间，纵轴是需求个数，我们可以对照某一个切片来看这一天处于各个状态的需求个数，而红色区域和蓝色区域就是我们团队的瓶颈，我们大部分需求都是卡在这样的阶段。
|
||
|
||
二是价值流程图，它可以告诉我们，需求卡在每个阶段的平均时间。如下图，从这张图中可以看到，我们在待处理阶段与开发阶段停留的时间比较长。
|
||
|
||
综合累计流量图与价值流程图，我们能够得知几个常见问题：
|
||
1.需求阶段，需求质量差，需求评估设计时间过长等。
|
||
2.测试阶段，测试数据、环境准备成本较高，自动化测试率低等。
|
||
3.开发阶段，手工重复的工作很多，联调时间长，代码质量差等。
|
||
|
||
除了上述3个问题，可能还有一些整体的人员瓶颈，比如开发人员少，待开发排序的时间就长，类似这样的问题我们可能会在人员结构上进行调整，或者是提高大家的技术能力等等。
|
||
|
||
总而言之，从效率这个维度来看研发度量体系，我们主要可以获益三点：第一，识别团队瓶颈，优化短板，减少资源浪费；第二，缩短交付周期，提高吞吐率，提升市场反应速度；第三，对团队产能预估更准确，提高团队工作幸福度。
|
||
|
||
最后，由于篇幅受限，今天就主要分享度量的意义和研发度量体系的前两个维度，即价值和效率，关于研发度量体系中的质量指标以及度量平台建设，我会在下一篇文章中继续分享。欢迎持续关注。
|
||
|
||
感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。
|
||
|
||
作者简介
|
||
|
||
钮博彦，美团高级技术经理，负责美团点评整体的研发工具栈建设。曾就职于微软中国、雅虎北研、唱吧等公司，从事系统开发、DevOps和质量保障等相关工作。一直专注于提升研发整体质量与效率，及其流程和平台建设。
|
||
|
||
|
||
|
||
|