案例:需求问题的解决方案
发布于 2024-10-02
1275
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
会议摘要
讨论时间:2012-09-14下午13:00至14:45
参与人员:EPG3人,需求开发部门负责人一名,项目经理一名
1. 现象与问题:
- 开发人员和需求撰写人员对需求清晰度的认识不一致。
- 存在如何传达需求的问题,文字规范与口头说明均有利弊。
- 需求人员未解释通用假设,导致开发人员缺乏相应概念。
- 需求人员对开发出的软件易用性不满。
2. 解答:
- 考虑是否已清晰定义需求与开发的接口关系,提议通过讨论历史CRS和SRS文档来评估和改进。
- 提出建立标准业务术语或领域模型,并对新人进行培训。
- 建议在wiki系统中记录每个需求的讨论记录。
- 建议结合文字和语言交流,包括需求交底、逆向培训、结对设计等方式。
- 强调原型法的运用,需求人员应使用工具如AXURE开发原型,并在开发前完成。
- 推荐多次需求确认法,包括文字确认、原型确认及功能展示等多个阶段。
- 强调测试人员在需求讨论、评审、确认中的重要性,以及需求的可测试性。
- 讨论能否通过功能点估算来判断需求详细程度。
- 参考敏捷开发中的用户故事、实时验收和需求变更处理等策略。
- 针对非功能性需求,建议定义缺省值和设计测试解决方案。
- 最后强调需求开发的人力和时间投入的平衡,以及是否能定义最小实践集。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 948.4K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
不可重现的BUG的应对策略
问题场景:有一些比较严重的BUG随机发生,难以查找规律的,测试工程师提交上去后,有可能会出现以下三个情形:1.开发人员试图重现,重现不出,Reject回来;2.开发人员找不到规律,所以不去解决,问题一直处于Open状态;3.开发人员因为问题难以解决,所以直接Resolved回来,觉得反正是偶发的,先改成解决状态再说。对开发人员、项目经理和测试工程师来说,正确的处理方法应该是怎样的?解决方案:1 缺
聊聊故事点背后的故事
聊聊故事点背后的故事Q1、敏捷项目能不能不估算故事点,直接估算工作量?【观点一】:在策划扑克法中先估算故事点有其固有的优点,最无法替代的优点是故事点不是绝对的工作量,避免了团队在迭代早期盲目的承诺,第一个迭代可以只估故事点不估工作量,是一种保护团队的行为,体现了敏捷以人与团队为本的文化,多数策划扑克法没用起来的团队往往也是这种文化薄弱甚至背道而驰的。此时策划扑克就不是最适合的方法...
单元测试技术培训练习总结报告
培训日期:2007年9月14日到2007年9月15日日程安排:第1天:上午:单元测试的技术与方法培训下午:LINUX下CUNIT单元测试工具的使用方法第2天:上午:分组练习下午:分组练习练习总结练习情况概述:约50名开发人员参加了练习,分成了7个小组进行了练习,其中一个小组原来采用C#在windows开发平台下进行软件开发,其他小组均是在LINUX环境下用C语言开发。练习均在实际的工作环境中进行的
AI自动生成代码了,度量功能点还有意义吗?
用户可能说“做个电商系统”,但“母婴用品垂直电商”和“全品类电商平台”的功能点规模完全不同——前者需要“育儿知识社区”“母婴用品专属筛选”等功能点,后者需要“多商家入驻”“全品类分类”等功能点,两者的价值差异,正是通过功能点来量化的。无论是项目预算的编制、合同价格的敲定,还是成本的管控,都需要一个明确的基准——功能点,它能精准量化业务需求的体量,让“多少钱办多少事”有章可循,避免因需求模糊导致的报价混乱、预算超支。如果说传统时代,功能点是“有用的工具”,那么AI时代,功能点就是“不可或缺的标尺”。
由外而内的过程改进策略
何谓“外”?外,是相对而言的。 对于一个软件公司而言,供应商、客户为“外”; 对于一个开发部门而言,供应商、客户、其他部门(比如市场部门、运维部门等)为“外”; 对于一个项目组而言,供应商、客户、其他部门、其他项目组、其他支持组为“外”; 对于一个项目组内的小组而言,其他小组、其他项目组为“外”; 对于一个项目阶段而言,
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线