本文探讨了敏捷开发中Product Backlog在需求管理中的局限性，指出需求空间的重要性。需求空间用于精细化和量化用户需求，提供可追溯性管理。尽管Product Backlog仍然是开发团队的重要工具，但单纯依赖它不足以实现全面的需求管理。引入需求空间和Story概念，可以更好地控制需求的分配和跟踪，提高项目管理效率。
敏捷方法指导团队将产品需求置于Product Backlog中管理，并按照优先级对每个产品需求进行必要的排列。在计划会(Planning Meeting)之前，由Product Owner从Product Backlog中挑选迭代周期准备开发的意向表（Willing List）进行总体介绍，然后分配到Sprint研发过程中。以Scrum为代表的纯敏捷方法，认为首先不需要对需求做分析，因为需求一直在变。所以提出了Story的概念，认为需求就该是对需求的一种类似讲故事的方式来表达的，这样便于让原始客户比较清晰的对需求进行表达，同样开发和测试也会逐渐以客户的需求思维来思考自己的工作。使得大家都能在需求的层面上，进行大脑思维。
但是敏捷方法的普遍使用中，又发现了纯敏捷方法的局限性
- 无法支持需求驱动下完整的可追溯性。
- 整个团队完全致力于项目的开发是基本前提。一旦开发团队的方向出现变化，会导致项目的崩溃；因为需求总在变化。
实践调查发现更多大型项目的成功，依赖于通过需求工
最低0.47元/天 解锁文章
扫一扫
1394
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
