笼统的需求对团队的沟通与合作十分不利。另一方面，在未开发前追求完美的需求是错误的。需求工程正是借助团队力量达到最佳平衡。
在进入第一个迭代前，提供需求积压是产品负责人的职责。如果产品负责人认为手上的愿景、业务分析乃至市场承诺不需要改进或消除， 而需求不清的地方适合进入第一个迭代后由团队一起改进，那么需求工程没有必要。
若产品负责人认为有些想法过于笼统，需要改进或消除，抑或是需要处理其他利害关系人的不同意见， 那么产品负责人可以使用需求工程看板改进或消除需求，使其适合进入第一个迭代。
第一批需求基于愿景、业务分析，甚至是市场承诺，产品负责人通过使用场景或用户故事，提高它们的清晰度，同时解决冲突的需求。这个过程有助于产品负责人在进入迭代之后更有条理地向团队解释需求积压。
在迭代开发过程中，优先产品积压工作中列出的要求（在每次迭代之前都会进行更新），将演变成可以并且应该使用经验数据来完成的工作，这些经验数据是通过编写和测试代码获得的。这类型的需求改进在进入迭代后进行，而不是在进入第一个迭代前在需求工程中进行。
在需求工程中，产品负责人收集有用的用户故事， 了解用户正在做什么， 有了新产品功能后能做什么，从中受启发整理好初步的需求积压，然后进入第一个迭代， 开始迭代地改进需求。
在需要存在的情况下，通过需求工程活动，产品经理可以建立优先的初始需求积压。产品经理向团队介绍愿景和需求积压清单。团队和Scrum主管会面，计划第一个迭代，这样就能完成最高优先级的任务，也能将该高优先级的任务分解成几个迭代任务。
返回
QQ客服
