敏捷框架给软件开发领域带来了巨大的文化转变，从繁琐的规划转向迭代和精益的执行。然而，有一件事没有改变，那就是每个人都仍然期望估算软件功能何时交付，以及项目需要多长时间才能完成。任务规划和估算很难，也许足以将它们视为科学和艺术。对于开发人员和产品所有者来说，这可能是一项令人生畏、艰巨的任务。

话虽如此，在将敏捷用户故事分解为任务并估计其工作量时，有足够好的“科学”，或者至少有可靠的实践可供您参考。在本指南中，您将了解它们是什么。

需要立即确定的一件事是，这是一项团队工作。虽然产品负责人负责确定待办事项的优先级并获取业务和用户的需求，但开发人员实际上最了解必须开发哪些技术能力以及需要付出的努力程度。

将用户故事分解为任务时需要考虑一些重要事项：

• 任务要尽量小，但不要太小。根据经验法则，任务应该是一天之内可以完成的事情，但也不能只花几分钟。
• 确保任务的范围非常精确。不要创建带有“编码”或“实施”等模糊陈述的任务，以为任何人都可以参考父用户故事来了解详细信息。写一些更有意义的内容，同时使范围非常清晰。例如：“开发登录类。”
• 使用用户故事的验收标准作为起点，并将其完成定义作为检查表。验收标准将帮助您确定需要实现哪些功能，而完成定义是所有用户故事的检查表，还可以帮助您确定故事中是否缺少任何待完成的任务。

让我们通过一个例子来理解这一切。让我们来看看以下用户故事，这是一个 Web 应用程序的要求：

作为注册用户，我希望使用我的用户名和密码登录，以便系统可以对我进行身份验证，并且我可以信任它。

并符合以下验收标准：

“鉴于我是注册用户并且已退出…… ”

1. “...如果我进入登录页面并输入我的用户名和密码并单击登录，那么与我的用户相关的数据就应该可以访问。”
2. “...如果我进入登录页面并输入用户名但密码不正确，然后单击登录，则登录失败并显示一条错误消息，指出用户名或密码错误。”
3. “...如果我进入登录页面并输入我的用户名和密码并单击登录，那么我的用户登录会话将在不到八秒的时间内加载。”

我们假设所有用户故事的完成定义都包括确保代码符合标准和样式指导并且经过适当的测试。

通过让所有开发人员聚在一起集思广益，您可能会听到如下内容：

• “我们需要一个新的 UI 元素用于注册和登录”
• “我们需要开发密码加密功能”
• “我们需要在数据库中创建一个表来存储用户信息”
• ETC。

现在，为了以更有条理的方式做事，让我们问问自己（团队）：

1. 我们如何将其分解为可执行的、范围有限的任务？在这里，团队可以就用户故事的以下任务达成一致：

   • 定义注册/登录表单样式并开发新的 CSS 类
   • 开发 HTML 和 Javascript 注册/登录表示层代码
   • 开发 Javascript 注册表单验证代码
   • ETC。

2. 执行完所有任务后，是否能满足验收标准？在这里，团队查看验收标准并得出以下结论：

   • 如果不开发错误页面或消息，则第二个验收标准将无法满足。然后，团队将任务“开发 HTML 和 Javascript 注册/登录表示层代码”的范围（描述）扩大到包含错误消息。仅为此目的而设立的新任务太小了。
   • 第三个验收标准指的是非功能性需求。团队意识到，如果没有适当的测试，就无法确保满足该要求，因此他们添加了一项任务：“对登录功能进行性能测试”。

3. 用户故事是否符合给定任务的完成定义？在这里，团队浏览确定用户故事已完成的项目列表，并得出结论，应该向该故事添加两个新任务以确保其完整性：

   • 编写并运行回归测试
   • 更新变更日志以描述添加的新注册/登录功能

现在，你可以看到，只要问自己这些问题，任务列表就会变长一点。自然，经过几次这样的练习后，团队就会从一开始就开始思考这些问题，并且每次都会变得更擅长提出次要任务，例如测试或文档相关的任务，以确保不会忘记重要细节并且交付得到接受。

当你对每个用户故事中的任务列表有了更清晰的认识后，就该估算工作量了。这里需要考虑的重要事项是：

• 依赖关系和下游任务：此任务是否存在必须开发或修改的依赖关系或构建块？
• 复杂性和团队技能：开发人员是否具备解决此任务所需的技能？或者他们是否需要一些时间进行研究和学习？
• 过去的估计：开发人员是否可以借鉴过去类似任务的估计来更好地估计当前任务的工作量？以前有人做过类似的事情吗？

在敏捷中，团队通常会使用故事点作为度量单位的估算值，而不是实际时间估算值（例如小时或天）。故事点是遵循修改后的斐波那契增长序列的数值，例如：1、2、3、5、8、13、20、40 和 100。它们代表了工作量级别，由于尺度的相对性，可以更容易地相互比较。例如，虽然很难判断五级工作量与六级工作量（增加 20%）的差异有多大，但五级和八级（工作量增加 60%）之间的差异更明显。在较低的范围内，绝对差异很小，但相对差异仍然很大（例如，二级工作量是一级工作量的两倍）。正是这种工作量级别与下一级工作量之间持续较大的相对差异使该系统能够正常工作。

敏捷团队必须就单个故事点在实际工作量方面所对应的内容达成一致（或最终通过经验学习）。然后，其他一切都可以据此进行衡量。故事点占用了讨论的时间，因为时间并不总是一个可靠的指标。例如，如果在特定的一周内，每个团队成员都忙于其他公司职责，例如培训或面试，那么每项任务都需要重新估计，并人为地增加天数（这会掩盖其背后的实际努力）。有了故事点，工作量估计始终是正确的。实际交付日期将随着团队的可用性而变化，但从一开始就要理解这一点。

在估算任务的故事点时，有一些技巧可能会有所帮助。其中最常用的两种是规划扑克和T 恤尺码。

规划扑克“游戏”的想法很简单，可以总结为以下步骤：

1. 每个团队成员都会获得与故事点值相对应的卡片（1、2、3、5 等）。
2. 产品所有者检查每个用户故事，并要求团队根据所涉及的任务单独评估该故事的工作量。
3. 每个团队成员挑选一张卡片，该卡片与他们对用户故事故事点的估计相对应。此时，他们不应互相展示卡片或开始任何讨论。这是一种丰富估算过程的方法，因为不会让任何人影响其他团队成员，而是让每个人都提供自己的观点。
4. 每个人都亮出自己的牌。如果达成了共识（即结果差异很小），那么故事点就可以轻松地分配给用户故事（最常选择的牌是最合理的选择），团队可以继续下一个。如果没有达成共识，或者提出了一些截然不同的估计，那么每个团队成员都有机会解释自己的决定，澄清任何误解或错误的假设。此后，团队根据讨论情况重复第三步和第四步。

重复第三步和第四步，直到达成共识。六名开发人员组成的团队在 Planning Poker 会议上达成共识的示例是3-3-2-3-5-3（三个故事点是合理的选择）。

对于相同的团队规模，无法达成共识并且可能需要另一次迭代的示例是3-8-3-2-5-8或3-3-3-13-3-5（一名“玩家”强烈反对）。

这种技术通过使用更大的“桶”来简化工作量估算，这些桶对应于 T 恤尺寸 XS、S、M、L 和 XL（或更小的子集）。然后可以进行类似于规划扑克的过程，就每个用户故事的工作量达成共识，这应该更容易做到，因为它涉及更少的尺寸选项，并将讨论提升到更高的水平（使用“小”和“大”等度量而不是数字）。因此，这种技术通常会加快估算过程。这也是向团队介绍 Agile 和相对估算概念的好方法。

将用户故事分解为任务并估算工作量并不是产品所有者可以独自完成的事情。敏捷估算技术的关键主题是达成共识的目标和流程的迭代性质。通过使用故事点的相对测量系统并让整个团队参与估算过程，往往会出现高保真度的估算（或至少比通过传统方法获得的估算更好）。通过从讨论中抽出时间，期望变得更加现实，团队能够更好地衡量其工作所涉及的复杂性。