案例:需求问题的解决方案
发布于 2024-10-02
1761
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
会议摘要
讨论时间:2012-09-14下午13:00至14:45
参与人员:EPG3人,需求开发部门负责人一名,项目经理一名
1. 现象与问题:
- 开发人员和需求撰写人员对需求清晰度的认识不一致。
- 存在如何传达需求的问题,文字规范与口头说明均有利弊。
- 需求人员未解释通用假设,导致开发人员缺乏相应概念。
- 需求人员对开发出的软件易用性不满。
2. 解答:
- 考虑是否已清晰定义需求与开发的接口关系,提议通过讨论历史CRS和SRS文档来评估和改进。
- 提出建立标准业务术语或领域模型,并对新人进行培训。
- 建议在wiki系统中记录每个需求的讨论记录。
- 建议结合文字和语言交流,包括需求交底、逆向培训、结对设计等方式。
- 强调原型法的运用,需求人员应使用工具如AXURE开发原型,并在开发前完成。
- 推荐多次需求确认法,包括文字确认、原型确认及功能展示等多个阶段。
- 强调测试人员在需求讨论、评审、确认中的重要性,以及需求的可测试性。
- 讨论能否通过功能点估算来判断需求详细程度。
- 参考敏捷开发中的用户故事、实时验收和需求变更处理等策略。
- 针对非功能性需求,建议定义缺省值和设计测试解决方案。
- 最后强调需求开发的人力和时间投入的平衡,以及是否能定义最小实践集。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1251.2K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
系统测试成功的关键点
(1)系统测试人员参与需求评审 (2)定义明确的测试需求 (3)测试人员要在需求阶段介入项目组 (4)系统测试用例要覆盖所有的场景 (5)建立产品需求与测试用例的跟踪矩阵 (6)评审测试用例 (7)利用回归测试工具 (8)
唐僧团队是否是一个优秀的Scrum团队?
唐僧团队通常被认为是一个成功的团队,因为他们是不同风格的成员组合在一起,经过了磨合后,同心协力达成了最初的目标,封神成佛。一个成功的团队,未必是一个优秀的Scrum团队。如果站在Scrum的角度来检视唐僧团队,他们有哪些突出的待改进之处呢?1 不是学习型团队在整个团队组建以后,团队成员的技能没有发生变化,孙悟空仍然还是那些绝技,猪八戒沙僧也没有学到新技能。每次打完妖怪后,没有总结经验教训,如何更好、更快地降服妖怪,打完一次妖怪,团队的整体技能没有提升,说明该团队不是一个学习型团队!...
开发过程中的八种确认方法
确认是确保做了正确的事情,方向不偏。确认可以在项目前期做,也可以在项目后期做,提倡持续确认、质量左移。在前期主要是检测需求的质量,在后期是检测完成的系统是否真的是客户所需。本文概要归纳了开发过程中常见的八种确认手段。
过程改进不能这样啊
过程改进是长期行为: 公司的高层对软件规范管理的认识有一个过程. 公司负责过程改进的人员对规范管理的理论的理解也需要一个过程. 公司的规范体系的推广需要一个实用化的过程. 公司的开发人员认识规范管理也需要一个过程. 公司的管理问题的解决从认识到制定措施,落实措施,优化措施也需要一个过程. 公司的管理体系真正制度化也不是短期内能做到的. 任何事情都有其发展的必然规律.违反了客观规律是要摔跟头的,
如何落地“单一职责原则”?
摘要: 本文探讨面向对象设计中的单一职责原则(SRP)在AI技能(Skill)开发中的实际应用。通过“五个单一”(目的、触发、输入、输出、变化)标准,提出“动词+名词”组合法作为核心判定工具:一个Skill应仅完成一个逻辑连贯的任务(如“生成PRD”)。Skill可分原子层(小职责)和组合层(大职责),后者可通过调用小Skill实现复杂功能,但需封装独立业务逻辑。文章对比正反案例,指出常见陷阱(如过度拆分或机械编排),并给出三步判定流程,强调Skill设计应像乐高积木一样精准分层,确保职责清晰且实用。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线