推测在词典中的定义是根据不完全的事实或信息猜测某事。在推测阶段，项目成员要收集初始的广泛的产品要求；制订一个迭代的基于功能的交付计划；估计项目成本，并生成其他必要的行政管理和财务信息。

(1) 产品功能单。创建一份产品功能单是推测阶段的首要任务。产品功能单是一份用来扩充产品构想的功能清单列表，是对构想阶段制订的清单的扩充和提炼。产品功能单列出那些经过可行性分析或市场研究、初步需求收集工作和产品构想等工作收集起来的产品功能，对于现有产品，客户、开发人员、产品经理和客服人员可以不断地提出改进建议，并添加到产品功能里。

产品功能清单通常包括故事卡、优先级别、探索系数和估算等信息。项目团队需要为每种产品功能建立一张或多张故事卡，其中包含基本的功能描述和开发工作估计等信息。探索阶段中的每次迭代会按照这些故事卡确定详细的需求，展开开发和测试工作。

故事是指从用户的角度来描述的功能。例如，传统的任务被描述为“开发用户界面”，从客户角度描述则是“能够审查用户信用等级”。故事是一个可交付的有用的功能，但不构成完整的功能。交付完整的功能需要完成几个故事。创建故事需要项目团队与客户共同合作，也可以邀请产品团队加入，协助制订详细的计划。如果一个故事无法在一次迭代内完成，则可以继续拆分成几个更小的故事。

实际操作中，故事卡片用来作为收集故事基本信息、记录高层次需求、开发工作估计和定义验收测试的工具。故事卡片只用于列出功能，而不详细定义功能。故事卡片是客户和项目团队成员在一次迭代期间讨论详细需求后达成的协议。表21-2是一个典型的故事卡片，一般故事卡片包含的信息如图21-3所示。

表21-2　典型故事卡片示例

在功能清单中，产品团队和开发团队还应定义功能的优先级，并列出这些功能在发布计划中的迭代时间表。功能清单上的功能具有易变性是敏捷项目的特点之一，因此每次迭代计划中的功能清单都可能发生变化。

图21-3　故事卡片信息

(2) 发布计划。发布计划是团队在项目数据表中所描述的在项目目标和约束内实现产品构想的路线图。发布计划的主要任务是依据价值和风险把故事分配到迭代中，如图21-4所示。

(www.daowen.com)

图21-4　部分发布计划

在传统项目中，项目管理计划用任务来构造工作分解结构，以此组织工作。敏捷生命周期则以迭代和故事驱动。故事驱动的表现在于将计划和执行的重点从任务转变为产品功能，将可交付的产品作为重点，然后创建交付这些产品所需的任务和工作。

因此在敏捷项目生命周期中，发布计划至关重要。发布计划需要团队(包括产品团队、开发团队和主管)共同协作来实现。

许多项目在制订计划时表现难以令人满意。因为计划往往基于愿景制订，而非能力，这就导致计划没有平衡需求和组织真实的工作能力。因此，在发布计划中应该按组织实际能力来制订计划。

对于一些包含大量功能的大中型项目，使用多层计划的方式来制订发布计划更合适。多层计划使计划既具有预测性又具有灵活性。

(3) 迭代。迭代是指在一段确定的时间，开发团队从开始到结束持续创建特定的一组产品功能的过程。每次迭代之后，开发团队创建的产品应该能正常工作并进行演示。迭代通常持续1～4周。任何迭代持续时间不应超过4周，一次迭代时间过长会加剧变更风险，违背敏捷的初衷。

发布计划一般包含第0次迭代。第0次迭代期间没有任何功能向客户交付，但是给予敏捷团队充足时间进行计划、需求说明和体系结构筹划工作，为以后开发工作做准备。

(4) 估计。敏捷项目管理方法主要用于不确定性高的项目，因而项目估计难以获得良好的效果。项目团队应将进度和成本视为限制而非估计。在精益思想中，估计是一个不产生价值的活动，因此敏捷项目应减少甚至消除一些不必要的估计活动。为项目设定界限是一种常用的方法，例如，需要在多长工期以及多少预算的情况下完成项目。这种做法的好处在于，项目管理者能从战略的角度去把握团队是否有能力在项目约束期间内交付可发布的有品质的产品。

估计和设定界限经常随时间的变化而不断演变，项目团队应注意这些变化，及时修正估计。

一个完整的产品计划结构如图21-5所示。

图21-5　产品计划结构