扫码阅读
手机扫码阅读
和需求的提供者达成一致
72 2024-10-03
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:和需求的提供者达成一致
文章来源:
麦哲思科技任甲林
扫码关注公众号
在一次访问客户并检查项目组周报时,发现项目组有大量未计划的任务。为此,项目助理被要求统计计划外工作量占计划内工作量的比例。为确保任务明确,周报内容被投影出来,并在白板上明确了统计标准,包括排除周期性任务、统计实际工作量、限定本项目组任务,并要求按周次、计划内外工作量三列进行统计。
通过现场演示,一个周的数据统计方法被展示。然而,一个小时后,项目助理提交的数据与之前的统计不一致。调查后发现,助理统计的是计划的而非实际工作量。尽管任务要求似乎已经很清晰,但实际上并没有确认助理是否真正理解了这些要求,从而导致了返工。
这一错误违反了需求管理的特定实践REQM SP1.1,即没有与需求提供者达成对需求的一致理解。这种情况在实践中可能相当普遍。因此,在布置任务时,应要求任务承担者重述要求,以确保他们确实理解了所要求的。
想要了解更多内容?
查看原文:和需求的提供者达成一致
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 103.4K
麦哲思科技任甲林的其他文章
头脑风暴会议的注意事项
在组织内会经常召开头脑风暴的讨论会,如何举办一个成功的讨论会议呢,请看如下的30个要点。
实例:评审速度与缺陷密度之间的相关性
某公司的项目分为两类:MIS类软件开发与嵌入式软件开发,对这两类项目的需求评审的速率与需求评审发现的缺陷密度分别积累了度量数据,分别见表一和表二,共计52次的需求评审数据。 表一:MIS软件开发项目的需求评审度量数据 表二:嵌入式软件开发项目的需求评审度量数据 对这两类项目的需求评审的速率与缺陷密度分别画散点图如图一和图二所示。 图一:MIS软件开发项目需求评审的缺陷密度
硝烟中的Scrum和XP读书笔记
CH1-1 Scrum不是方法学,它是一个框架。CH1-2 Scrum 的强大和令人痛苦之处就在于你不得不根据自己的具体情 况来对它进行调整;CH2-1 产品Backlog中包含了:故事、特性、需求+优先级并且是用用户的术语的表达;CH2-2 how to demo实际是对用户故事的细化,是设想的用户操作场景,可以作为用户故事的验收准则。CH2-3 指出如何解决问题的应该是...
为什么无法建立过程性能模型?
在CMMI四五级的软件公司中,建立过程性能模型是一个重点也是一个难点工作,很多公司无法建立过程性能模型,为什么呢? 1)数据不准 比如: Ø 对于评审的会议,评审的参与人有的是来学习的,在统计人数、工作量时就不应该统计在内。 Ø 有的数据当时没有采集,而是靠时候回忆采集上来的。 Ø 有的代码行数不是通过工具统计上来的,而是靠
需求交付周期的分析
需求交付周期的分析
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线