案例:分类建立过程性能基线以提高其实用性!
发布于 2024-10-01
2116
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
一家公司在分析其27个项目的历史生产率数据时,旨在建立一个过程性能基线。项目分为大型、中型和小型,各自的生产率(Loc/人天)数据不同,大型项目生产率范围在130.41至175.42之间,中型项目在211.90至272.94之间,小型项目则在236.81至295.38之间。
最初的过程性能基线未分类,所有项目一起考虑,结果显示上限为317.86,下限为69.77,中位数为235.61。这个基线分布极为离散,上下限相差超过4倍,指导意义不大。进一步的探索性数据分析表明,基线应根据不同项目级别分类建立。
通过单因子方差分析,验证了大型、中型和小型项目之间的生产率存在显著差异。分析的结果如下:
- 方差分析显示项目级别对生产率有显著影响(F值为48.17,P值为0.000),表明至少有一个项目级别的生产率均值与其他级别不同。
- 模型总结显示调整后的R方值为78.40%,预测的R方值为75.23%,说明模型质量较好。
- 各项目级别的平均生产率及其95%置信区间为:大型项目157.56(140.10, 175.03),小型项目264.29(250.03, 278.55),中型项目229.27(216.92, 241.62)。
结论是,为了提高过程性能基线的实用性和准确性,应当针对大型、中型和小型项目分别建立基线。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1071.2K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
案例:需求问题的解决方案
讨论时间:2012-09-14下午13:00至14:45参与人员:EPG3人,需求开发部门负责人一名,项目经理一名 1现象与问题:(1)开发人员反映需求没有说清楚, 写的人认为需求很清楚了。(2)是写清楚,还是说清楚?以谁的意见为主?如果说清楚呢,语言没有证据,不如文字规范。将来发生了需求变更时有争议。(3)需求人员没有讲解约定俗成的,默认的东西,开发人员没有概念。(4)需求人员抱怨开发人员写的软
还是“师徒制”吧
很多客户都面临如何培养新员工的问题,如何更好的培养开发人员也一直是我思考的问题。琢磨来琢磨去,最终发现还是“师徒制”最有效。 在学校里教授的大多是书本知识,和实践有很大差别。社会上的各种速成班仍然是停留在表面,可以让开发人员入门,但是不能深入。在公司里办各种培训,时间不可能太长久。其实以前在通软的时候已经尝试过师傅带徒弟的方式,只是我不喜欢称为“师徒制”。“师”在我心目中是比较神圣的称呼,为“师”
项目回顾案例
某公司从2015年6月下旬开始启动了一个敏捷开发的项目,截止到8月中旬结束,投入的开发人员、测试人员、管理人员达到60多人,2015年8月31日,由咨询顾问作为主持人带领该团队的10多名核心人员,对整个项目进行了系统回顾总结,整个回顾总结的过程如下: 1 咨询顾问花了1小时的时间,讲解了进行项目回顾的方法。强调了回顾的目的、方法、步骤、注意事项等,给出了一些公司的总结样例。对本次总结的会议制定
维护项目的管理策略案例
维护类项目的定义: (1)在已交付的软件基础上增加少量功能; (2)对已交付的软件进行局部的需求变更; (3)修改已交付软件的bug;维护类项目的特点: (1)工期短,客户要求相应快; (2)对已有的软件进行局部修改,投入的人力少; (3)变更容易对已有的功能造成影响,容易注入新的bug; (4)需求沟通、设计方案的确定、测试的
时间箱管理
时间箱管理是敏捷方法中的一条实践,其含义是在项目中的某些活动的完成时间必须在规定的时间内完成。该实践有助于提高整个项目的工作效率,避免帕金森现象。
在敏捷方法里时间箱管理的具体体现包括:
(1) 每次迭代必须在固定的时间内完成,比如2周或1个月等,本次迭代必须交付一个质量得到充分检验的、可以运行的软件版本,如果有些需求不能在本次迭代内完成,则推迟到下一个迭代中完成。
(2) 项目的策划会议必须在4个小时内完成,某次迭代的策划会议必须在4个
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线