如何用用户故事来评估一个敏捷项目？

图片：Tumblr

估算软件项目很难，敏捷项目更是如此。在开发过程的早期，您无法精确定义项目的范围。而且在项目开始之后，其范围将不可避免地发生变化，因为团队在开发过程中也在不断学习更多有关项目及其背景的知识。尽管如此，团队依然需要在项目开始之前估算项目所需的资源。

那么，这该如何解决呢？

传统方法是进入分析阶段，创建开发任务的详细规范。但正如我们所说，在开发开始之前，项目的范围并不完全清楚。因此，分析不是最好的方法。

什么是用户故事？
用户故事（User Story）简单但功能强大，是对需要实现的单一功能的一句话描述。它描述了用户角色，需要执行的功能以及所需的结果。编写这些故事是描述我们想要开发的内容的敏捷方式。

用户故事的优点在于它用简单的文字书写。因此，即使您没有软件需求管理或项目管理方面的技术背景或经验，也可以编写一个，因为您可以在不深入研究技术细节的情况下描述应用程序的高级需求。

用户故事对于从用户的角度捕获所需功能至关重要。它们还可以帮助您向团队的所有成员传达做出某些决策的内容，方式和原因 – 即使该团队仅由一名开发人员组成。通过用简单的词语描述期望，您还可以使非技术团队成员（如设计人员，QA工程师和客户支持专家）也参与进来。

如何编写用户故事
典型的用户故事遵循以下公式：

作为<用户角色>，我想<功能描述>以便<期望结果>

示例：作为管理员，我想开发供应商功能，以便能够将订单分配给供应商并查看交易信息。

用户是管理员，功能是创建供应商模块  - 这就是管理员需要做的事情。最终结果是向供应商分配订单并查看交易，这解释了管理员首先需要创建供应商模块的原因。

用户故事很容易与为开发人员编写的开发任务混淆。任务类似于用户故事，但不同之处在于：任务通常只描述在不提供任何上下文的情况下需要完成的任务，更多的是实现。换句话说，任务描述了为了实现用户故事需要做的事情：设计前端界面，开始后台工作，制作可点击按钮等。另一方面，故事是高级且简单的。它们为任务提供定义和推理。

编写用户故事的backlog可能需要一些时间。有时候您可能会发现，自己并不了解真正的用户如何看待自己所设想的特定功能。这可能表明您需要回到绘图板去找头绪。

用故事点评估
编写完用户故事后，即可开始评估工作。

如果您没有软件开发经验，那么您需要开发人员这样做，因为您不知道如何评估某个功能的工作量或持续时间。您可以要求为您构建应用程序的开发人员提供用户故事的估计值，或聘请顾问，并将其估算值用作基准。

您可能倾向于通过评估完成用户故事所需的时间来预估。然后，您将能够为backlog中的所有用户故事添加时间量，除以处理项目的开发人员数量，并计算完成项目所需时间的粗略估计。

不幸的是，这种方法不起作用 – 实际开发部署的时间经常会超出预估，至少不会低于预估。如果部分用户故事超时，整个计划都会偏离预期。有些故事依赖于其他故事，导致更多延迟，迫使开发人员一次处理多个故事。结果，整个评估最终被“关闭”，项目比预期长两到三倍。

因此，我们需要承认软件项目的高度不确定性。而不是估计用户故事的持续时间，最好估计实现它们所需付出的努力。

好的，这是最简单的方法：只需给你的用户故事从1-3分打分。也就是对故事的复杂性进行排序 – 简单的是1，普通是2，复杂是3。你甚至可以将故事评为0，几乎不需要任何努力，例如更改设置或更新设计。这没有公式。只需使用你的直觉和估算师的经验（或估算师团队，如果你有一个团队来定义故事点）。

故事点（Story Point）最大的优点是：它们是相对的。因此，一旦您将用户故事定义为简单，您就可以将其与另一个用户故事进行比较，以确定它是否具有相同，更低或更高的复杂性。

根据故事点评估团队的进展速度
你可能会怀疑故事点是否有任何意义。毕竟，故事点无法（直接）用来评估项目的周期或预算。

但是，您可以通过衡量团队在每个Sprint中完成的故事点数来进一步评估项目所需时间。也就是对所谓“团队的速度”的评估。

您对项目了解得越深入，就能愈加准确地计算团队每个sprint完成的平均故事点数。将故事点总数除以“团队的速度”（每次Sprint完成的平均故事点数量），乘以Sprint平均时间，您将可以大致估算整个项目的时间。

简单地说？如果你的团队每个sprint的可以完成三个正常故事（2分难度）和一个复杂的故事（3分难度），那么你将需要34个冲刺来完成一个300分的项目。

关于作者：Alex Ponomarev是Medium作者，帮助开发者和创始人维护和改进应用。