敏捷方法中的功能度量

Question

我正在为管理人员(而不是程序员)准备一个关于敏捷方法的演示，我期待着，从一个侧面来看，敏捷讨论的是功能视角*^(在Scrum中我们有计划游戏)，但从另一方面来说，它缺乏**功能度量的任何(标准)定义。

在我看来，这很奇怪:如果敏捷方法没有使用功能需求的正式/统一定义，并且不采用任何形式的功能度量(Function，宇宙)，那么我如何能够根据用户的功能需求来进行大量的工作。

如果你玩过计划游戏或用户故事，你的衡量单位是什么？你用过FP还是宇宙？

Answer 1

sprint的规划有两个组成部分。一方面，您估计故事和任务的复杂性的积压单位的故事点。稍后再讨论这个问题。另一方面，团队可以在一次冲刺中传递多少个故事点。这就是所谓的速度，它是基于历史数据的多少故事点的团队在过去的冲刺。在这里，您还可以考虑到已知的缺勤，例如，由于(公共)假期。

故事点是一种相对的度量，它表示与项目中的其他任务相比，给定任务所需的工作量。在最初的几次中，您可能需要将一个简单的(但并非琐碎的)任务指定为“参考任务”，并将1 Story定义为完成该任务所需的工作，但过了一段时间，人们就会开始说：“嘿，这个任务/故事看起来与我们两次短跑前做的任务/故事类似。它应该有相同的故事点数。”

你应该意识到故事点通胀的风险。对于那些习惯于在工时内估算工作量的人来说，这是一种风险，当他们开始给出比以前更高的估计值时，就会发生这种情况，因为以前他们忘记考虑一些因素(例如，测试)。如果你总是忘记在你的“故事点”的估计中加入一些因素，那么你就不应该调整你的估计，因为你总是忘记了某件事情，这将以团队的速度来表达自己，所以调整你的估计会产生双重补偿。

特别是对于经理来说，认为你可以比较不同团队的故事点是愚蠢的。如果你有多个团队在一个项目上工作，很有可能他们的速度差异高达一个因子3，但是速度数最低的团队产生的价值最大，仅仅因为他们的测量单位(“故事点”)要大得多。