为什么必须首先做规模估计?
发布于 2024-10-04
1127
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
文章探讨了在项目管理中,为什么需要先进行规模估计再进行工作量估计的必要性。作者提出了几个理由支持规模估计的重要性,包括使用规模来估计成本、规模估计的客观性、以规模来度量开发效率、通过规模细化需求、规模实现度量项目进展、规模用来度量缺陷密度和质量设计,以及规模估计用于与标杆数据进行比较。
然而,作者也指出了这些理由并不是最根本的,而且存在一些反对意见。例如,工作量和成本可以不通过规模直接估计;如果项目组成员熟悉且配合默契,直接估计工作量是可行的;项目开发效率可以通过跟踪实际规模和工作量来统计;需求细化不必依赖规模估计;项目进展可以用EV值度量;缺陷密度可以通过实际规模设定质量目标来测量;而与历史项目的比较可能更具可行性。
作者在探索这个问题时,虽然列出了支持规模估计的理由,但也提出了一些对这些理由的质疑,并没有提出最根本的原因。文章结尾留下了悬念,没有明确提出最根本理由是什么,暗示需要进一步的讨论和探索。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 850.1K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
AI编程之需求分析与描述
文章浏览阅读508次,点赞3次,收藏5次。本文探讨了AI编程时代需求分析与描述方式的变革。传统编程中需求描述可保留模糊性,依赖人工沟通完善细节;而AI编程必须将模糊需求转化为精确、完备的规格说明,因为AI无法主动追问模糊点。文章通过对比传统模式与AI模式的需求处理差异,指出开发人员需扮演"翻译官"角色,将业务需求转化为AI可理解的结构化规格。重点提出了5项规格检查标准以确保无歧义,并通过购物车案例演示了从模糊需求到精确规格的转化过程。最后构建了从需求到设计的完整链路,强调业务事件、能力和规则的结构化描述是
CMMI 3级的难点
(1) 需求、设计、代码、测试用例的质量比较差Ø 需求描述不全面、不详细;Ø 设计中错误比较多,遗漏比较多;Ø 设计与实现脱节,实现人员不看设计文档;Ø 代码中隐藏的缺陷比较多,代码的可维护性比较差,其他开发人员难以读懂代码;Ø 测试用例数量太少,对需求、设计的覆盖率比较低(2) 同行评审无法快速发现问题Ø 缺
我说CMMI之三:CMMI的构件
我说CMMI之三:CMMI的构件 CMMI中的内容是按照成熟度等级或过程域类别、过程域、目标、实践、子实践的方法来进行分类管理的,这些概念之间的整体部分关系可以参见下图。 过程域的概念我们前面讲过了,这里不赘述。每个PA都有一个目的,在英文里明确区分了Purpose与goal这两个单词,我们翻译为了目的与目标。在中文里这2个单词病没有特别明显的区别。Purpose是一种抽象的,宏观的期望,goal是一种具体的,微观的期望。 PA之间有一定的关联性,互相影响,比如RD的输出为TS的输入,TS的输出又影
图解APH之engaging合弄
图一:Engaging合弄的目的与性能等级图二:Engaging合弄的活动 图三:Engaging合弄使用的敏捷仪式与技术
两个浪漫的人,一本理性的书
“两个浪漫的人,一本理性的书”是我对《重构极限编程》一书的评价。 书买了有一段时间了,浏览过一遍,感觉很受启发。今天是第2遍读,边读边乐边反思。 两位作者很浪漫,每个章节的开头,都改编了一首歌曲作为前言; 两位作者很幽默,在文章里轻松、犀利地调侃极限编程的缺点; 两位作者也很理性,对极限编程的某些优点也进行了充分的肯定。 第一次读此书时,只注意了作者的理性,没有去读书里的歌词与调侃,第二遍读时,仔
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线