欢迎来到例解:目标驱动的度量元识别方法
发布于 2024-10-03
2292
版权声明
我们非常重视原创文章，为尊重知识产权并避免潜在的版权问题，我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容，访问作者的公众号页面获取完整文章。
查看原文：例解:目标驱动的度量元识别方法
文章来源：
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
服务管理改进摘要
识别需求: 服务经理需要提升客户请求的处理速度。
管理目标和问题: 目标是减少待处理客户变更请求的数量和所需工作量，问题是当前处理速度不足。
量化目标: 通过监控待处理的变更请求数量和计划工作量来量化。
- 对象：待处理的客户变更请求。
- 属性：变更请求的个数和计划工作量。
展示度量数据: 使用双轴折线图表现每天未处理变更请求的数量和工作量。
使用度量数据: 服务经理每天根据图表跟踪进展。如果数据在可接受范围内，则正常；否则，标示异常。
度量元详细刻画:
| 度量元 | 个数 | 计划工作量 |
|---|---|---|
| 计量单位 | 个 | 人时 |
| 采集或计算方法 | 统计个数 | 统计工作量 |
| 验证方法 | 抽检重算 | 抽检重算 |
| 采集周期、时间点 | 每天下班前10分钟 | 每天下班前10分钟 |
| 优先级 | 高 | 高 |
| 采集人 | 部门助理 | 部门助理 |
| 数据验证人 | 服务经理 | 服务经理 |
| 数据分析人 | 服务经理 | 服务经理 |
| 使用该度量元的指示器 | 统计表 | 统计表 |
| 基本/派生度量元 | 基本 | 基本 |
| 刻度类型 | 定比 | 定比 |
影响目标的因素:
- 变更请求数量影响因素：软件质量和运行周期。
- 计划工作量影响因素：文档完备度、维护人员技术水平和变更请求数量。
度量元与目标关系: 2-3级企业只需执行到步骤6，而3级以上企业应执行步骤7和8，以积累数据建立过程性能模型。
麦哲思科技任甲林
查看原文：例解:目标驱动的度量元识别方法
文章来源：
麦哲思科技任甲林
扫码关注公众号
相关推荐
问题说明springboot项目中用到如下代码读取自定义配置：String path = Thread.cu
2385十年之约第25篇\x0a\x0a流程经历的审批环节越多，流程上运行的效率就越低。\x0a\x0a审批活动，是指在业务流程中，由一个或多个审批者对某项业务活动进行审核，审批活动可以是一个简单的审批过程，也可以是一个复杂的审批流程，其中包括多个审批步骤和多个审批者。
麦哲思科技（北京）有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员，中国分部主席
471 篇文章
浏览 1267.6K
还在用多套工具管项目？
一个平台搞定产品、项目、质量与效能，告别整合之苦，实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
小团队靠人治，大团队靠法治
何谓人治?依赖于管理者的人格魅力、经验与能力管理一个团队，而非依赖制度管理一个团队即为人治。
何谓法治？依赖于制度管理一个团队，而非依赖于管理者个人的魅力、能力管理一个团队即为法治。
人治与法治是否对立的呢？非也。其实人治与法治是互补的，是缺一不可的。正如做人，德才兼备才可以大用，有才无德，是要做坏事的，正如企业有法治没有人治，这种企业是没有人情味的，员工会离心离德的。有德无才，是做不成大事的，正如企业靠人治是无法壮大起来一样。
小团队以人治为主，法治为辅。大团队
例解：集成测试用例与单元测试用例的区别
函数一： getMaxInTwo(int a,int b) { if a>=b return a; else return b; } 函数二： getMaxInThree(int a,int b,int c) { a=a+1; int max=getMaxInTwo(a,b); max=getMaxInTwo(max,c); } 单元测试用例的设计： getMaxInTwo的UT用例： （3，2）
组织过程财富库中究竟包含什么？
1 过程财富库的含义CMMI中提到的organizational process assets 通常翻译为组织过程资产或者是组织过程财富，可以简写为OPA。 什么是OPA呢？按照V1.3中的术语定义： Artifacts that relate to describing, implementing, and improving processes. Examples of these artifacts include policies, measurement descriptions,
CMMI V2.0 时代即将来临
CMMI V2.0
系统测试缺陷检出密度越大越好吗？
这是一个很有意思的话题。很多人对此困惑。困惑在什么地方呢? 从开发的角度看，是希望系统测试发现的缺陷越少越好，那意味着在开发阶段都把缺陷找干净了。 从测试的角度看，是希望系统测试时把缺陷找干净了，不要遗留给客户去发现。在潜在的缺陷数恒定的前提下，找到的缺陷越多越好。 在组织级确定质量目标时，这个系统测试缺陷检出密度到底是定义为越高越好，还是越小越好呢？系统测试缺陷检出密度的大小能代表产品质量吗？ 产品质量只能通过上线后的缺陷多少来衡量，上线后的缺陷密度越小越好...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线
-
联系我们
电话：4006 8899 23 邮箱：beining@chandao.com -
融实践库
关于我们 加入我们立即学习
微信号：rongpmcom
-
微信公众号
-
微信视频号
-
社区微信群
