先行指标与滞后指标的设计要点
发布于 2024-11-05
2553
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
度量工程师认证训练营首次课程作业摘要
在度量工程师认证训练营的首次课程中,学员们被要求根据自己在公司的职位来确定有价值的管理目标,并分别给出对应的先行指标和滞后指标。以下是提交作业的点评摘要,用以展示设计度量指标的重要考虑因素。
作业点评摘要
- 质量工程师提出提高软件研发质量的目标,以缺陷逃逸率作为滞后指标,测试覆盖率和代码审查问题数量作为先行指标。点评建议考虑将“代码审查问题数量”修改为“代码审查缺陷密度”以更准确地预测缺陷逃逸率。
- 同一质量工程师还提到项目延期率来反映研发质量,但点评人提出了因果关系的疑问,并暗示测试覆盖率和代码审查问题数量对项目延期率的影响可能没有那么直接。
- 软件开发工程师关注clean code,将clean后代码行数作为滞后指标,而重复代码行数/现有代码行数作为先行指标。点评强调了重复率在重构前后的对比重要性,建议使用测试缺陷密度来作为滞后指标。
- 项目经理关注减少项目缺陷,以结项项目缺陷数为滞后指标,以目标允许缺陷数量等为先行指标。点评强调了将缺陷数改为缺陷密度可能更为合适。
- 另一项目经理想预测项目延期,以返工工作量等为滞后指标,而预估和实际工作量之间的差异为先行指标。点评提出预估和实际工作量的偏差率可能是一个更合理的先行指标。
- 管理层希望了解当月盈利,以当月盈利作为滞后指标,成本和回款额作为先行指标。点评指出,如果成本不好度量,可以用回款额预测盈利。
- 成本主管希望提高项目的利润率,以成本超支数额作为滞后指标,并考虑项目人力成本作为先行指标。点评提出利润率与超支数额之间的关系可能不够明确。
- 同一成本主管关注缩短项目交付周期,选择实际交付周期作为滞后指标,开发效率作为先行指标。点评指出单一指标无法全面预测交付周期。
- PMO想了解各项目进度,以项目验收时间作为滞后指标,项目计划合理性等作为先行指标。点评建议采用具体度量元,如计划评审问题数等。
- PMO还关注项目成本,以项目实际成本为滞后指标,预算和出差情况等作为先行指标。点评提出应该比较实际成本与预算,以及时间进度来判断成本超支情况。
- 产品开发部助理提出提升团队产能,选择需求吞吐量作为滞后指标,而在制品数量作为先行指标。点评认为这是一个良好的度量。
- 同一助理还希望提升产品质量,以产品缺陷率作为滞后指标,产品需求评审次数作为先行指标。点评同样认为这是一个良好的度量。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 567.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
成为一个好员工的七个忠告
如何成为一个好员工呢?请看以下七个忠告。
案例:需求问题的解决方案
讨论时间:2012-09-14下午13:00至14:45参与人员:EPG3人,需求开发部门负责人一名,项目经理一名 1现象与问题:(1)开发人员反映需求没有说清楚, 写的人认为需求很清楚了。(2)是写清楚,还是说清楚?以谁的意见为主?如果说清楚呢,语言没有证据,不如文字规范。将来发生了需求变更时有争议。(3)需求人员没有讲解约定俗成的,默认的东西,开发人员没有概念。(4)需求人员抱怨开发人员写的软
西安印象
来西安大概有八次了。 印象最深的就是西安的美女与羊肉泡馍。 认识西安的美女不是在西安。曾经有济南的同事、有上海的和深圳的客户、北京的同行、南京的合作伙伴都是西安美女。西安美女最大的特征是:漂亮、大气、不拘小节。1995年,上海的一个客户,西安美女曾经到公司去参观,看完我们的软件演示进行讨论时,竟高兴的坐在了我们的办公桌上,害得办公室主任过来问我,是咋回事。 认识羊肉泡馍却是在西安。2005年
还是“师徒制”吧
很多客户都面临如何培养新员工的问题,如何更好的培养开发人员也一直是我思考的问题。琢磨来琢磨去,最终发现还是“师徒制”最有效。 在学校里教授的大多是书本知识,和实践有很大差别。社会上的各种速成班仍然是停留在表面,可以让开发人员入门,但是不能深入。在公司里办各种培训,时间不可能太长久。其实以前在通软的时候已经尝试过师傅带徒弟的方式,只是我不喜欢称为“师徒制”。“师”在我心目中是比较神圣的称呼,为“师”
CMMI 3级的难点
(1) 需求、设计、代码、测试用例的质量比较差Ø 需求描述不全面、不详细;Ø 设计中错误比较多,遗漏比较多;Ø 设计与实现脱节,实现人员不看设计文档;Ø 代码中隐藏的缺陷比较多,代码的可维护性比较差,其他开发人员难以读懂代码;Ø 测试用例数量太少,对需求、设计的覆盖率比较低(2) 同行评审无法快速发现问题Ø 缺
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线