定制你的敏捷方法：以结果为导向

本文要点

• 速度是对当前能力的度量，但不是对项目进度的度量。
• 度量完成的故事，而不是故事点，以了解项目进度。
• 选择能对你了解进度有实际帮助的度量项。
• 通过查看特性燃尽图衡量项目进度。
• 改变度量能改变交流。

我遇到过很多人想使用一个且唯一一个敏捷框架。我并不反对框架，除非有人想盲目地遵从框架去寻求想要的结果。往往，你的项目或团队需要考虑，可以选择使用哪些敏捷方法以寻求所需的结果。在这种情况下，为什么不先定义好商业结果和你想要度量的产出物呢？

这是系列文章中的第二篇，该系列主题为帮助你思考如何针对你的环境定制敏捷方法。本文围绕的是团队可能收集和使用的数据（比如正在做的产品和其他度量），即那些你想要分享给管理者和利益干系人的信息。

在本系统的第一篇文章《定制你的敏捷方法：选择适合你的敏捷方法》中，我写了你可以如何去考虑对你行之有效的敏捷方法。定制你的敏捷方法的其中一种方法就是，考虑你想要把什么数据展示给其他人。

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

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

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

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

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

速度是对团队能力的度量

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

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

• 速度是关于团队的相对度量，所以你不能在团队之间做比较。实际上，如果你们作为一个团队有了提升，你也不能用现在的速度去比较之前的速度。当你们转变了团队的工作方式时，你的团队速度会在一定时间后发生改变。
• 个体会影响团队的速度。如果你改变团队中的人，那么团队的速度就会发生变化。
• 员工休假或生病时，速度就会发生变化。
• 人们很容易就会把速度当成是目标，而不是对能力的评估。

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

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

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

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

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

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

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

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

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

度量完成的故事，而不是故事点

Jim 是一家组织的一位敏捷项目经理，这个组织希望能够更快地交付特性。他从上级管理者那里接到了一个命令：提升特性发布速度！Jim 的领导想要看到特性交付后可以更可靠的流转，以便他们更快地确认收益。

Jim 的团队度量了他们的故事点。他们有个小麻烦，他们迟于迭代后完成的故事点呈曲棍球棒曲线。

图1© 取自创建你成功的敏捷项目—Johanna Rothman

Jim 发现，他们有些迭代末期正在进行中的故事，所以他请团队增加一个故事度量到图表中。通过把完成的特性（故事）增加到图片中向他们展示了正在发生着什么：

图2© 取自创建你成功的敏捷项目—Johanna Rothman

团队之前认为他们的故事都有两个故事点。如果是这样的话，他们在本迭代中应该已经完成五个故事。相反，他们只完成了两个故事，这意味着这些故事每个略为五个故事点。当他们看到这个图表时，发现实际上他们完成了比故事更多的故事点，这才认识到他们的故事太大了。

另外，他们发现故事完成得太晚了。第一个故事是在第9 天完成的，而第二个是在第10 天，还有几个正在进行的故事没有完成。

对于Jim 的团队，度量对客户（特性）有价值的东西而非故事点能帮他们认识到为什么管理者想要更多的生产力。现在他们需要弄清楚是什么妨碍他们交付更多完成的故事。

度量想增多或减少的东西

Jim 想知道尚未完成的故事的所有故事点。他清楚累积怜（越攒越多），但他想要理解什么组织制度阻碍了团队更快发布更多的故事。他决定看看周期时间和交付周期。

一般来说，周期时间即团队把一项任务从准备就绪列拿出来直至将其完成的时间。Jim 确信，这个团队肯定依赖组织内的其他人或团队。Jim 请团队介绍一下发生的现象。按他们对此的陈述，他绘制了这张图表。

Jim 问，“一个任务从完成到已发布需要多久呢？”整个团队一致认为不会超过一天。Jim 把这标为 T5，并写上“最多一天”。

然后，他问，“怎么算是完成了呢？”

每个人七嘴八舌地说起来。他等了一会儿，然后说，“谁能告诉我工作流程吗，我如何来理解呢？”

Susan，一名高级开发人员说“我先来，我们把一项任务从‘准备就绪’列拿出来，把它放到‘进行中’列，然后开展工作直至认为它完成了。但是，这有个问题，我们不做任何界面上的事，必须得等 UI 团队协调人给我们。”

大家纷纷点头表示认同。Susan 持续道。“然后，我们必须提请用户接收测试，等他们取走这个特性。”

Jim 问道，“每次？”

Susan 点了点头。“每一次。”

Jim 画了下面这张表，问，“是这样的吗？”

每个人都说是的。

这些依赖都会花许多时间。Jim 请团队介绍最近几年的工作。团队在这段时间内完成了五个故事，所以他请他们说明在流程的每个环节花费的时间。

故事 团队内时间 界面时间 用户接收测试时间 部署时间 周期时间 故事1 3 天 3 天 2 天 1 天 9 天 故事2 2 天 0 天 2 天 1 天 5 天 故事3 4 天 1 天 3 天 1 天 9 天 故事4 1 天 0 天 2 天 1 天 4 天 故事5 1 天 3 天 1 天 1 天 6 天Jim 的领导想让团队更快地发布。然而，团队把大量的时间用在了等待界面和用户接收测试上了，这意味着团队的速度和完成的故事点不那么关键。

该团队无法控制UI 团队的申请和响应。他们不知道他们的工作和UI 之间要来来回回多少次，所需的时间难以预计。

另外，用户接收测试的时间从发起测试申请到开始测试至少得有两天，如果用户接收测试发现了问题，可能工作又会转回到这个团队或相应的UI 人员。除此之外，如果最初负责UI 的人没空或有其他状况，那么团队可能还得与新的UI 人员协作。

这个团队的周期时间不只是团队内的时间，而是所有时间的总和。团队惊讶地发现这些事花了这么长时间。这五个故事的平均周期时间是6.6 天，都没有人会想到会多花这么多时间！

基于这份数据，Jim 提议招收了他们“自己的”UI 人员。这一改变把他们的平均周期时间缩短到了每特性2.5 天。该团队不必再UI 团队指派人员给他们了。他们能够自己调整UI 方面的工作方式。他们喜欢一开始实现一个故事就集中开始UI 方面的工作。

现在他们可以向管理者说，他们每个特性的2.5 天与总体周期和上市时间相比仍然相形见拙，因为用户接收测试和部署仍不在团队范围内。

Jim 的团队发起组织级的讨论，探讨如何把用户接收测试和部署也整合到团队中。无论怎样，再也没人抓着他们的评估不放了。每个人的关注点都上升了一个层次，即如何组织测试和发布新特性。

度量项目进度

虽然组织讨论的是测试和发布新特性的总体问题，产品经理已经为项目的总体路线图增加了故事。

但是 Jim 认为产品经理需要增加更多的故事。然而，如果完成产品经理增加的每个任务就得花很长的时间才能完成项目。他需要想个办法，向管理者展示虽然项目在前进，但是增加特性将推迟发布时间。

他选择了两个图表：项目特性燃尽图图和项目待办事项燃尽图。

图 3 © 取自创建你成功的敏捷项目—Johanna Rothman

该特性完成图展示了已完成特性的燃耗、所有特性的燃耗，以及剩余特性的燃耗。

Jim 和产品经理统计了这些特性。他们没有描述复杂度或评估，他们统计的特性的总体数据。

其中某些特性增长是因为产品经理理解特性后发现有复合的特性能够分解为几个故事。Jim 和产品经理把每个故事视为了一个特性。

增长的另一个原因是产品经理增加了更多的特性。这在产品待办事项燃尽图中很容易就能够看出来。

图 4© 取自创建你成功的敏捷项目—Johanna Rothman

该团队每个迭代都度量他们的进度。随着项目的进行，产品经理增加特性到产品待办列表中，特性集也会随之增长。

每个特性集不断地增长。因为产品经理和团队可以看到哪些特性集在什么时候增长的，所以他们可以问以下问题：

• 它是最具价值的部分吗？
• 我们现在如何先发布一小部分，如何了解已经为客户完成了哪些所需的内容？
• 或要结束这个项目预期还要做些什么？

你的团队或许有不同的问题，但 Jim 的团队问的是这些问题。

Jim 的团队想要确认，这些客户真的需要这个项目的这些特性。有时，会因为故事或特性不再对客户有价值或重要程度不足而削减特性集。

改变交流为切实有效的度量

Jim 将此类交流从能力的预测（即速度）改为了切实有效的度量。他能够将组织内部的交流从关于团队应该做什么改为团队应该完成什么，并讨论他们发现了什么障碍。

所有一切，都是源自改变度量。

关于作者

Johanna Rothman, 著名的“实用主义管理者”，为你遇到的问题提供中肯的建议。她帮助领导者和团队发现问题并解决风险，以及管理他们的产品开发。Rothman 是十多本书的作者，包括：《创建你成功的敏捷项目：协作、度量、评估、交付》、《敏捷和精益程序管理：跨组织的大规模协作》、《管理你的项目组合：提升能力完成更多项目》第二版，在 jrothman.com 上可了解她的更多著作。

查看英文原文： agile approach results