敏捷开发需求收集与文档记录的新方法
1. 传统需求收集方式
瀑布模型和敏捷开发在需求收集和共享方式上存在显著差异。在瀑布模型中,所有需求必须在完整收集后才能传递给 IT 部门进行评估。瀑布模型是线性流程,一个阶段结束后才能开始下一个阶段,因此所有需求必须提前完全明确并记录下来。
然而,由于市场动态变化,事物不断发展,这种方式几乎不可能实现。这导致产品人员和开发人员之间产生挫败感,开发人员觉得没有得到所需的全部信息,产品人员则无法考虑到所有可能的细节。
此外,旧的需求交换方法缺乏对话。产品人员花费数月时间收集和记录需求,然后几乎不沟通、不协作地将其发送给 IT 部门。IT 部门没有机会就需求提问或提供建议,也就无法利用自身专业知识提高需求质量。最后,瀑布模型难以跟上业务需求的变化,而敏捷框架则是为适应变化而构建的。
2. Scrum 中的敏捷需求
与瀑布模型相比,敏捷开发以一种完全不同且创新的方式运作。它不需要详细记录复杂系统的所有细节,而是针对简单功能提供简单说明,并在讨论过程中逐步添加细节。需求聚焦于满足用户/客户需求、提供切实的商业价值以及促进协作。
在 Scrum 中,需求被称为用户故事。用户故事必须足够小,以便能够在一个冲刺或迭代周期内完成设计、编码和测试。由于冲刺周期较短(通常为两到四周),这就要求用户故事简洁明了。
2.1 用户故事的定义
- 什么(What) :用户故事是对所请求功能(或功能组件)的简短描述。
- 谁(Who) :用户故事融入了使用或受益于
超级会员免费看
订阅专栏 解锁全文
931

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



