这是鼎叔的第一百三十四篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

一年多前开始写这个专辑文章，正逢大模型火爆时期，中间乱入了大量AI及其他主题的文章，合辑一直拖到现在才收尾。尤其是最后一篇“岗位兵力配比”的思考文章没有找到时间完成，话题也比较敏感，将来再输出吧。

Part1 度量需求的工作量和价值

聊聊需求的工作量估算

度量交付需求的数量和时间相对容易，但度量每个需求的大小则比较难落地，我们需要统一的方法来度量各个团队的需求交付规模，它有利于精细化的组织改进，推动团队以比较舒服的节奏完成承诺，还能稳妥处理紧急需求插入，潜在收益远大于成本。

聊聊需求的价值如何度量

度量需求的数量和时间比较容易，度量需求大小（颗粒度）要麻烦些，那么，度量需求的价值呢？

 outcome比output重要，价值比需求规格重要

我们最终给用户交付的是具体的价值，而不是平台统计的需求个数。度量需求价值的方法很简单，但要落地不容易，来自产品团队的阻力可能会很大，需要高级管理者的支持。

Part2 研发生命周期的度量

聊聊研发效能的可视化

在一个大型研发组织，效能度量和汇报的成本要降到最低，第一步是能随时看到关键指标，第二步就是汇报框架非常简单和稳定。

效能可视化建设，首先要明确核心用户是谁，他的需求是什么，其次再明确唯一的北极星指标是什么，围绕它来建设质效可视化大盘，切忌不让其他指标喧宾夺主。

聊聊软件生命周期中的度量指标

我们继续聊聊在整个软件生命周期中，以及各个主要阶段，我们选取哪些关键拆解指标做好研发过程的提效治理。

Part3 敏捷研发的质量工程师须知

聊聊质量管理工程师的郁闷

在传统技术行业，质量管理是一个专业的独立角色，它代表管理层，起到了重要的过程量化和纪律督促作用。但是在敏捷研发时代，专职的质量管理人员，经常走到了研发效能的对立面，尽管做得很辛苦，但频频被吐槽，缺乏成就感。

聊聊传统质量观VS敏捷质量观

传统研发质量的管理体系一直有比较大的局限性，在敏捷团队中推动度量常常缺乏成就感。质量管理如果作为独立处罚型部门，难以产生推动质量内建的文化。两种环境下的质量观有哪些关键的差异？

质效改进的工具和看板，应该是迭代演化出来的，像产品一样简洁明了，它应该适应一线团队的阶段性发展，而不是大幅增加一线团队的认知负担。

聊聊效能度量的作弊经济学

从本能上，工程师会遵循经济学的规律。没有任何一个单一简单的指标经得起各种推敲，聪明的工程师一定有办法把他变成“虚荣指标”——看着很好看，但是没有起到促进效益的作用。尤其当我们把度量指标和绩效挂钩时，它很容易被人扭曲成让人误导的解释，以便获得更多的利益。

聊聊基于敏捷的度量指标设计

上文列举了传统度量的问题和对于度量的种种误解，让我们结合敏捷理念的深入理解，看看该如何设计基于敏捷的度量指标体系。

Part4 敏捷成熟度

聊聊阿里巴巴的卓越工程

软件生命周期各个阶段的系列指标是从需求研发（事）的角度来开展度量改进活动，还不能满足管理层的所有需求，我们还可以从管理者角度来度量团队（人）的健康度。我们这篇具体聊聊研发工程成熟度，参考阿里巴巴的卓越工程度量经验，每个公司可以裁剪适合自己的度量公式。

聊聊AMM-敏捷成熟度模型

如果我们把视野再扩大一些，如何针对产研团队整体敏捷状态进行准确的评估呢？只有找准团队敏捷短板的指示器，才能找对自我提升的好策略，持续实施正确的敏捷动作。

聊聊敏捷团队调查问卷

敏捷团队从转型初始期到完全成熟期的发展并不是一蹴而就的。除了理解成熟度评估指标，敏捷团队也要分阶段把控提升的侧重点，逐步向高成熟度靠拢。本文也针对一线特性团队（Scrum team)的敏捷管理成熟度提供了一套调查问卷。

结语：

基于敏捷价值观，我们需要重新梳理敏捷度量指标的价值牵引，警惕伪敏捷的虚假繁荣因素，让投入敏捷度量的成员能够真正获益。

本专辑也推荐了整个研发生命周期各阶段的核心敏捷度量指标，介绍了基于团队敏捷成熟度模型的评估方案，从管理、技术和产品三个维度梳理出敏捷要点进行问卷评分，但每个团队还是应该根据自己的敏捷阶段和现状挑选当前合适的驱动指标。

质量工程师可能还是会困惑，未来自己的具体工作风格该如何转变，以满足敏捷团队日益发展的需求，避免成为不大受成员欢迎的“监工”？

难道自己的价值就是输出一系列的度量指标并给出度量治理报告么？

将来本公众号会给出进一步思考的答案。