认识达内从这里开始

许多的程序员在进行项目开发的时候一般都喜欢使用框架来提高工作效率，最主要的原因就是这些内容都是提前编制好的，不需要再重新输入。那么，是否使用框架就是最好的选择呢?

几乎每个项目都需要以某种形式把进度呈现出来，以便项目团队和管理者可以制定关于项目的决策。项目正在进行中?团队是否被困住了?团队因为其他更重要的事停住了脚步?

许多管理者和项目经理习惯使用干特图去了解进度。项目经理(希望团队)为不同的项目阶段制定相应的里程碑。当他们达成这些里程碑的时候，团队就可以在干特图中展示他们完成了什么了。

我在瀑布和其他连续生命周期项目的经验是，直到项目超期之前它都是准时的。项目团队准时或接近准时地完成他们的阶段。然后，当测试人员介入项目时，团队最终认为他们完成了特性。往往，测试人员会发现重大缺陷。然后，项目会因为返工而超期。

敏捷方法让我们使用经验数据(即工作相关的实际数据)来帮我们了解实际的进展。数据告诉我们当前处于什么位置：超前、落后，甚至偏离了方向。另外，因为我们能在构建过程中看到产品，所以能知道是否能就此打住，还是持续推进。

敏捷方法可以改变项目度量值。首先，让我们讨论一下速度，因为许多团队把速度作为进度度量项。

速度是对团队能力的度量

许多团队按故事点来度量速度。他们认为速度是对进度的度量。但其实不是。速度是团队能力的当前度量。

有些团队使用速度来看他们能在下一个短时间周期完成些什么。然而，其他团队以这些方式使用速度会遇到以下麻烦：

速度是关于团队的相对度量，所以你不能在团队之间做比较。实际上，如果你们作为一个团队有了提升，你也不能用现在的速度去比较之前的速度。当你们转变了团队的工作方式时，你的团队速度会在一定时间后发生改变。

个体会影响团队的速度。如果你改变团队中的人，那么团队的速度就会发生变化。

员工休假或生病时，速度就会发生变化。

人们很容易就会把速度当成是目标，而不是对能力的评估。

团队想要了解他们能力的时候，可能会觉得度量速度很有帮助。有些团队愿意看到他们能在一个迭代完成30个故事点。他们甚至知道这30个故事点大概是给定时间内的五个小故事或一个大故事和两个小故事。这些团队采用故事点来度量他们的能力。

有些团队试着预测一份季度待办或项目待办。他们清楚他们的速度是30个故事点。对这份完整的待办事项予以评估后发现，他们要实现大概180个故事点。他们“有理有据”地猜测以当前的团队成员需要大约六个迭代完成这些工作。他们可能会解释说，“以我们目前所知，至少六个迭代吧。我们将按工作进展持续更新评估”。

人们如果想要比较团队的速度，或者速度成了目标，那速度就成了问题。如果你曾经听某人说，“你可以加快两倍!”那这就说明速度成了目标。我就见过管理者和团队都认为可以用这种方式创建目标。

目标，对射箭很有帮助。但对于度量能力却没什么用。

我们总用速度这个词来度量进度。我们甚至可能认为我们是在高速公路上飞驰。我们测算速度时，距离不会随着时间的变化而变化。一英里就是一英里，一千米就是一千米。距离是一个静态的指标。所以，我们能够对这两个指标加以转换(英里和千米)。

故事点会随着时间的变化而变化。故事变化时，团队交付的故事点就会变。如果团队习惯在一个周期内针对产品的某一领域交付30个故事点，他们可能甚至不知道在同样的时间内针对其他领域他们能够交付多少故事点。如果产品经理改变他或她编写故事的方式，故事点就会发生变化。而且，如果团队中的人变了，可能交付的故事点也会变。

这就意味着，我们使用故事点时度量不是静态的。特定的条件有相应的评估。当这些条件变化时(编码和测试的领域、团队组成、已有代码和测试的质量)，相应的评估就会发生变化。

这也正是为什么速度是对当前能力的相对评估，而不是永远的评估。

故事点的评估能帮助团队理解他们的能力。然而，如果你度量故事点，得到的就是故事点，而不会得到特性。

作者：JohannaRothman

译者：冬雨

节选来源：infoq

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。