聊聊敏捷研发度量（合辑共11篇）

这是鼎叔的第一百三十四篇原创文章。行业大牛和刚毕业的小白都可以进来聊聊。欢迎关注公众号《敏捷测试转型》星标收藏大量原创思考文章陆续推出。一年多前开始写这个专辑文章正逢大模型火爆时期中间乱入了大量AI及其他主题的文章合辑一直拖到现在才收尾。尤其是最后一篇“岗位兵力配比”的思考文章没有找到时间完成话题也比较敏感将来再输出吧。Part1 度量需求的工作量和价值聊聊需求的工作量估算度量交付需求的数量和时间相对容易但度量每个需求的大小则比较难落地我们需要统一的方法来度量各个团队的需求交付规模它有利于精细化的组织改进推动团队以比较舒服的节奏完成承诺还能稳妥处理紧急需求插入潜在收益远大于成本。聊聊需求的价值如何度量度量需求的数量和时间比较容易度量需求大小颗粒度要麻烦些那么度量需求的价值呢outcome比output重要价值比需求规格重要我们最终给用户交付的是具体的价值而不是平台统计的需求个数。度量需求价值的方法很简单但要落地不容易来自产品团队的阻力可能会很大需要高级管理者的支持。Part2 研发生命周期的度量聊聊研发效能的可视化在一个大型研发组织效能度量和汇报的成本要降到最低第一步是能随时看到关键指标第二步就是汇报框架非常简单和稳定。效能可视化建设首先要明确核心用户是谁他的需求是什么其次再明确唯一的北极星指标是什么围绕它来建设质效可视化大盘切忌不让其他指标喧宾夺主。聊聊软件生命周期中的度量指标我们继续聊聊在整个软件生命周期中以及各个主要阶段我们选取哪些关键拆解指标做好研发过程的提效治理。Part3 敏捷研发的质量工程师须知聊聊质量管理工程师的郁闷在传统技术行业质量管理是一个专业的独立角色它代表管理层起到了重要的过程量化和纪律督促作用。但是在敏捷研发时代专职的质量管理人员经常走到了研发效能的对立面尽管做得很辛苦但频频被吐槽缺乏成就感。聊聊传统质量观VS敏捷质量观传统研发质量的管理体系一直有比较大的局限性在敏捷团队中推动度量常常缺乏成就感。质量管理如果作为独立处罚型部门难以产生推动质量内建的文化。两种环境下的质量观有哪些关键的差异质效改进的工具和看板应该是迭代演化出来的像产品一样简洁明了它应该适应一线团队的阶段性发展而不是大幅增加一线团队的认知负担。聊聊效能度量的作弊经济学从本能上工程师会遵循经济学的规律。没有任何一个单一简单的指标经得起各种推敲聪明的工程师一定有办法把他变成“虚荣指标”——看着很好看但是没有起到促进效益的作用。尤其当我们把度量指标和绩效挂钩时它很容易被人扭曲成让人误导的解释以便获得更多的利益。聊聊基于敏捷的度量指标设计上文列举了传统度量的问题和对于度量的种种误解让我们结合敏捷理念的深入理解看看该如何设计基于敏捷的度量指标体系。Part4 敏捷成熟度聊聊阿里巴巴的卓越工程软件生命周期各个阶段的系列指标是从需求研发事的角度来开展度量改进活动还不能满足管理层的所有需求我们还可以从管理者角度来度量团队人的健康度。我们这篇具体聊聊研发工程成熟度参考阿里巴巴的卓越工程度量经验每个公司可以裁剪适合自己的度量公式。聊聊AMM-敏捷成熟度模型如果我们把视野再扩大一些如何针对产研团队整体敏捷状态进行准确的评估呢只有找准团队敏捷短板的指示器才能找对自我提升的好策略持续实施正确的敏捷动作。聊聊敏捷团队调查问卷敏捷团队从转型初始期到完全成熟期的发展并不是一蹴而就的。除了理解成熟度评估指标敏捷团队也要分阶段把控提升的侧重点逐步向高成熟度靠拢。本文也针对一线特性团队Scrum team)的敏捷管理成熟度提供了一套调查问卷。结语基于敏捷价值观我们需要重新梳理敏捷度量指标的价值牵引警惕伪敏捷的虚假繁荣因素让投入敏捷度量的成员能够真正获益。本专辑也推荐了整个研发生命周期各阶段的核心敏捷度量指标介绍了基于团队敏捷成熟度模型的评估方案从管理、技术和产品三个维度梳理出敏捷要点进行问卷评分但每个团队还是应该根据自己的敏捷阶段和现状挑选当前合适的驱动指标。质量工程师可能还是会困惑未来自己的具体工作风格该如何转变以满足敏捷团队日益发展的需求避免成为不大受成员欢迎的“监工”难道自己的价值就是输出一系列的度量指标并给出度量治理报告么将来本公众号会给出进一步思考的答案。