User Story是一种描述用户需求、业务价值的最佳实践,
但不是说非要用User Story的形式来描述需求,
而且通常在一个Sprint backlog中,尤其在最初的若干Sprint中会存在一些架构设计、技术调研、接口定义、获取背景知识这些方面的事项和任务需要处理,
那么这些任务是不适合用User Story进行描述的,应该用技术团队熟悉的语言和规范进行描述,这些任务是为了后续Sprint更好更多的完成业务需求相关的用户故事。
这意味着一个Sprint不是所有的任务输出都可以给用户演示,但依然是需要可以被团队评审的。
一般而言,可以参照如下的规则来确定某需求是否适合采用User Story的形式来进行描述:
- 业务需求: 适合。
- 技术规格: 不适合,这些通常是用来完成一个User Story的支撑任务
- 缺陷: 未必适合,通常可能是技术过失
- 非功能性需求: 适合
by iefreer
本文探讨了在敏捷开发中如何区分并描述业务需求、技术规格、缺陷和非功能性需求,强调了使用UserStory描述业务需求的重要性,同时说明了技术任务更适合使用团队熟悉的技术语言和规范进行描述,以确保团队评审的有效性和后续Sprint的顺利进行。
1031

被折叠的 条评论
为什么被折叠?



