扫码阅读
手机扫码阅读
需求交付周期的分析
211 2024-10-01
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:需求交付周期的分析
文章来源:
麦哲思科技任甲林
扫码关注公众号
需求交付周期数据分析摘要
本文介绍了针对某公司的需求交付活动的四个阶段:需求确认、等待开发、需求研发、需求验收的管理与分析过程。公司的管理目标是50天内交付需求,为此,收集了316个需求的交付周期数据进行分析。
数据清洗
首先,对包括尚未交付的需求在内的数据进行清洗,删除了12行数据,包括有缺失值或者处理时长为0的记录。
方差分析
通过箱线图观察和单因子方差分析,发现需求交付周期与产品线类型无显著差异,P值大于0.05,说明不相关。
分布分析
对每个阶段的工期占比建立性能基线,分析各阶段的占比情况。结果显示研发阶段的工期占比最高,建立基线时剔除了异常点。
敏感性分析
敏感性分析表明,不同阶段对总工期的影响程度不同。通过秩相关系数计算并归一化,发现需求确认阶段最具敏感性。
综述
综合以上分析,得出以下结论:
- 需求交付周期与产品线类型无关。
- 需求等待阶段虽然工期占比和敏感度分析均较低,但作为非增值活动,应当优先缩短。
- 需求确认周期是除等待阶段外最应缩短的阶段。
- 各阶段工期占比的异常点分析有助于识别特殊情况和原因。
想要了解更多内容?
查看原文:需求交付周期的分析
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 136.6K
麦哲思科技任甲林的其他文章
我所知道的富士康之四:培训
富士康是我咨询过的几十家企业中最重视培训的。集团有十几个技术委员会,简称技委会,会定期举办各种培训活动,包括邀请专业培训机构来厂进行企业内训,或是举办各种行业交流会,或是结合国内高校进行学历教育等等,也有些课程是通过录像来进行培训的。富士康集团内部有政策:陆干(即大陆的干部)每年必须接受288个工时的培训,台干(即来自台湾的干部)每年必须接受144个工时的培训,否则无法晋级。当然不同的事业群对此政策的执行严格程度不同。有个事业群的副总对我讲:“我要让员工一半的时间提高,一半的时间工作”。有个事业群的楼层过
案例:建立工作量分布过程性能基线
某应用软件开发公司积累了最近3年的29个项目的工作量分布历史数据,试图建立工作量分布的过程性能基线。在该公司内对项目从3个维度做了项目分类:规模:大,中,小;开发方法:全新开发,修改;类型:常规,紧急,优化,外包。 原始数据如下表: 对工作量分布的数据与项目类型做了方差分析,发现:对这些原始数据采用箱线图的方法进行分析后得到如下的结论:
测试投入度量元的选择
很多项目在讨论测试是否可以结束的时候,往往是只关注了测试发现的缺陷有多少?缺陷的严重级别分布如何?测试发现的缺陷关闭情况如何?而忽略了一个前提,即测试的投入是否充分? 如何量化测试的投入呢?我们可以从测试用例的密度,测试投入的工作量,测试的工期,测试的人数等多个方面来度量测试的投入,可以参见图一中候选的测试投入的度量元。 图一:测试投入与产出的候选度量元 哪个度量元更合适呢?如何判
不可重现的BUG的应对策略
问题场景:有一些比较严重的BUG随机发生,难以查找规律的,测试工程师提交上去后,有可能会出现以下三个情形:1.开发人员试图重现,重现不出,Reject回来;2.开发人员找不到规律,所以不去解决,问题一直处于Open状态;3.开发人员因为问题难以解决,所以直接Resolved回来,觉得反正是偶发的,先改成解决状态再说。对开发人员、项目经理和测试工程师来说,正确的处理方法应该是怎样的?解决方案:1 缺
做事模式的思考:想、说、写、做
模式一:边做边想没有事先的计划,没有思虑周全,在做的过程中再去寻找好的方法,造成的后果就是质量差或返工多,浪费了时间。很多初级的开发人员在编码时就采用了这种工作模式。磨刀不误砍柴工,先想清楚,再动手做,看似慢,实际快!模式二:想->做 想清楚了总比不想好。此种模式没有和别人沟通,没有文档化,这种模式很可能想的不周全,导致在做的过程中存在问题。三思而后行,如何保证三思的质量呢?沟通与文档化。模式三:想->写->做 想了以后文档化,文档化可以促进自我反思,但是没有其他人进行评审,然后去实现,没有其
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线