郑州市二七区建设局网站软件培训网站建设

当前位置： 首页 > news >正文

郑州市二七区建设局网站,软件培训网站建设,wordpress表单代码,网站建设参考文献英文书籍思码逸企业版 4.0 的部分功能已进入内测阶段✨近期我们会用几篇文章#xff0c;浅剧透一下 4.0 的新鲜功能。 最近几篇的主题将是 4.0 版本中的 GQM 看板——GQM 代表 Goal-Question-Metric#xff08;目标-问题-指标#xff09;#xff0c;是一套构建软件研发效能度量的系…思码逸企业版 4.0 的部分功能已进入内测阶段✨近期我们会用几篇文章浅剧透一下 4.0 的新鲜功能。 最近几篇的主题将是 4.0 版本中的 GQM 看板——GQM 代表 Goal-Question-Metric目标-问题-指标是一套构建软件研发效能度量的系统方法。简单来说GQM 方法强调面向清晰具体的目标自上而下拆解通过问题建立研发的度量模型 基于量化数据分析来回答问题自下而上解读并达成目标。更多解读可以查看《GQM 概述构建研发效能度量体系的根本方法》。 相比大多数所谓『数据看板』GQM 看板的进化在于数据不再是简单罗列、看得人一头雾水而是先将具体场景下的具体度量目标拆解成问题再由问题引出指标图表以递进的方式传递信息并引导用户适时下钻探索。 我们认为优秀的效能度量一定不会是难懂的。我们希望即使是不太了解研发效能领域知识的一线研发管理者也能低成本理解每个指标的含义和指标给出的信息实实在在将度量用起来解决他们在研发管理中的遇到的各类“看不清”“说不明”。 上一篇文章中我们介绍了我们将介绍 GQM 看板中的『项目交付效率看板』这一篇将继续介绍『项目人效看板』。 0. 研发人效度量为什么如此尴尬? 上一篇文章我们提到过研发效率最终应当体现在交付效率或者叫流动效率上让价值接收方感到交付物更多、响应更及时、研发目标更快速达成。 而与交付效率相对的人效或者叫资源效率虽然常备诟病但依然是研发效效率中的绕不开的话题。 何勉《阿里如何定义团队的研发效能》 一方面人效的度量与改进确实有存在的必要。 仅在交付效率上下功夫的改进例如加强跨部门沟通协调、减少等待确实能使交付更快例如调整研发投入重心与业务方向匹配确实能使交付的软件功能更符合市场期望。但本质上这些措施都是在产能不变情况下优化产能分配。如果产能本身处于偏低水平不论如何优化分配改进效果可能都是有限的。因此人效的提升是交付效率提升的重要手段之一。 另一方面人效度量又因常常跑偏到强管理导向和“反人性”而饱受争议。 对于管理者尤其是没那么懂技术的管理者来说工时、工作饱和度执行任务的时长/总工时、代码行数这样的指标更容易理解因此常常被用来度量研发的人效。这些指标似乎给管理者提供了一种“监督员工们没摸鱼没划水工资才算没白给”的安全感。 但软件研发毕竟是脑力劳动开发者们不是生产代码的机器不可能每天从早到晚精神抖擞全速运转。这就导致开发者和管理者之间痛苦且双输的博弈开发者或想尽办法来绕过度量或在高压下忙忙碌碌变得疲惫、麻木和缺乏创造力部分成员因此离开管理者们可能如愿以偿看到人效指标上升最后才发现这个数字和真正的效率提升并没有必然联系可能还是负相关的。 再热爱工作连轴转太久也只能交付bullshit 研发人效度量如此尴尬背后是常常跑偏的度量设计和使用。这也是思码逸希望提供更加可靠、有正向引导作用的人效看板的原因。 1. 人效度量先选对指标 交付效率侧重于刻画端到端的交付表现业务、产品、研发、测试各环节内部和它们之间的流转协调都会造成影响。而人效度量侧重于内部评估研发团队的交付能力研发 Leader 们需要的是仅与研发环节相关的指标。 前面提到常见的工时、工作饱和度指标多把开发者作为需要时时刻刻运转的资源而非有创造力的人因此广受诟病而代码行数指标则很可能错误地引导开发者们多敲空行、多写不必要的复杂函数来造数据进而导致代码可读性和可维护性急剧下降本质上使研发效率更加恶化。 思码逸选择人均代码当量和人均事务吞吐量作为北极星指标来表示项目组的人效水平。

• 代码当量和代码行数一样是基于代码的工作量指标但排除了代码风格、换行习惯等噪音干扰且调整了移动、粘贴、数据修改等修改的权重因此更鼓励重要且有创造性的工作。
• 事务吞吐量则是基于任务的工作量指标能够更好地与项目交付进度相关联但可能会受到事务颗粒度大小不一的影响。 因此两个指标同时使用能够可靠简洁地说明各项目的人均开发效率及时挖掘内部最佳实践或及时发现状态不佳的项目再到其他图表进一步了解问题的原因。 项目人效四象限图 如果需要深入了解某一项目人效的具体信息思码逸支持下钻分析呈现项目人效趋势并自动识别偏高或偏低的潜在异常点。如果贡献者人数频繁波动则可能需要重点关注开发者专注度我们会在第三部分介绍。 在此基础上思码逸也将工时指标纳入分析。但工时不代表任何产出或工作量而是研发团队和开发者的资源投入。将代码当量和事务吞吐量与工时交叉分析则可以量化研发团队内部的投产比。这样的度量也有助于开发者们更专注于交付结果而非磨洋工凑时长。需要留意的是不同职能团队、不同类型项目的工时投产比可能相差很大不经筛选的横向比较可能是欠妥的。 2. 参考行业基线客观评估人效水平 代码当量和事务吞吐量两个指标量化了项目人效但对于研发团队而言数字的理解是有门槛的这些数字代表了什么四象限图表明某个项目的人效在公司内处于上游那么与行业对比如何 根据项目语言和团队规模属性思码逸能够自动匹配行业近似项目为人效数据的解读提供参考基线帮助团队客观认知当前人效水平合理制定提效目标。 但这里也需要提醒一句项目的发展阶段、业务属性等也会对人效造成影响。例如成熟期的项目其人效可能会低于起步期的项目一方面是任务比后者少另一方面是“历史包袱”也更重改动需更小心谨慎。因此在判断项目人效时还是结合项目的实际需求进行分析。 3. 深入分析项目的贡献分布与专注度 接着前面的例子项目到了成熟期人效下降Leader 们开始考虑本项目是不是不需要那么多人参与了是否可以把部分研发人力分到别的项目上毕竟研发人力成本如此昂贵自然不希望空转导致浪费。 今日分工90%项目成员等着10%成员完成任务 这时候就需要更精细的项目人效分析登场了。 首先可以先通过项目贡献均衡度图表判断有多少开发者是作为项目主力军工作。贡献均衡度的定义是贡献80%工作量的开发者比例。如果均衡度较低则项目大部分人力可能都是辅助角色如果转移到新项目上需要交接的工作也不会太多。 接着我们可以下钻到某一项目内继续验证均衡度是否走低并通过产出分布帕累托图来判断工作是否逐渐集中在少数几位核心开发者谁是核心开发者。 那么非核心开发者们是还参与着其他项目还是处于空转状态呢人力专注度指标可以帮助我们直观了解。 如果许多非核心开发者仅专注于此项目但代码产出和事务吞吐数又不高则可能正处于空转状态。如果许多非核心开发者同时在开发其他项目则需要结合新旧项目之间的关联来判断开发者同时参与多个项目是否合理若新旧项目之间关系不大则可以考虑帮助开发者交接剩余工作并完全转移到新项目上减少上下文频繁切换造成的浪费。 另一种情形是项目加班严重却频频延期贡献高度集中于几位核心开发者。这种情况则可以结合产出分布的详情和专注度数据辨别是项目人手确实不足需要频繁抽调其他项目人员支持或是任务太过耦合核心开发者超负荷工作而其他成员帮不上忙亦或是项目人员结构不恰当导致部分人员没有任务可做。 需要提醒的是数据分析更多起到的是客观度量、提供建议、排除部分可能性、并引导层层下钻的作用其本身往往难以直接得出行动项。排查项目人效问题的过程中由开发者参与的复盘和讨论是必不可少的。 我们可以将贡献均衡度和人力专注度理解为人效的健康指标持续超负荷工作、贡献过于集中、成员同时投入在多个不相关项目都是不健康的。不健康的情况下人效可能依然很高但大概率是不可持续例如团队加班累垮或风险巨大例如核心成员离职的。 总结 项目人效度量的是研发内部的研发产出尽管这些产出不直接等同于业务侧和终端用户感受到的价值但它代表了研发部门支持价值交付的带宽。在以提升交付效率为最终目的的改进中提升研发人效是必不可少的路径之一。而人效度量的尴尬则常常源于混淆了路径和目的。 在厘清概念的基础上谨慎选用具有正向引导作用的度量指标在合适的参考系下进行解读在关注人效数字的同时重视健康度并适时下钻到关键单点内通过案例复盘来排查人效的影响因素。这样的度量和解读的方法能够帮助研发团队避免掉进数字的陷阱而是去发现和追问真正的问题。 聊完了交付效率和人效下一篇我们会聊聊项目的质量控制。