企业转型成敏捷型企业思想很复杂。决策者想要数据。随着你把业务从计划驱动心态的业务转型为敏捷业务价值驱动型时，了解该跟踪什么以及怎样跟踪将会是一项挑战。本文讲述的几点可以指导你开始工作。

传统方法 VS. 敏捷开发方法

传统的瀑布思想可以归结为：在开始你的项目之前，仔细计划每一个细节，细致到每个任务的内容、时间和人物。然后，一旦你有了一个健全的计划，那么在执行时就要严格跟踪并对计划进行反馈报告。换句话说，计划工作，然后执行计划。

敏捷流程对此心态持反对意见，提醒我们在敏捷宣言中，我们应该支持“响应变化胜过遵循计划。”这听起来似乎很合理，支持的理由有两个：（1）业务需求总是试图追逐最好的价值与最合理的开发费用；（2）历史上最大规模发布的计划和执行负责人Dwight Eisenhower将会证明——他引用说，“战争中，计划一无是处；规划才是一切。”

瀑布方法出了什么问题？

对一个细节非常详细的计划进行跟踪有两个麻烦。一是，所有人事先了解所有需求和任务是不可能的，因为魔鬼藏于细节之中。事情一直在变化。人们的思想也在改变。要处理它。二是，传统跟踪对于计划衡量成本没有好处。但是，我们真正要做的是衡量交付的价值和避免延迟。

敏捷跟踪的类别是什么？

有许多很难开始的事情，敏捷都可以跟踪。但所有人都知道有两个好的方面就中速率和燃尽（burn-down）。这些都是可预测性的衡量，而且不会用于衡量生产力，以免我们影响该游戏的效果：

速度是主要的衡量，我们用它来在敏捷项目中获得持续的功能。

发布的燃尽图应该既要展示出完成的点，还要表明在迭代中添加迭代点。

考虑运行测试功能的其它指标：所需的软件根据功能（需求、案例）命名分解，组成了需要交付的系统。对于每个命名功能，有一个或多个自动化验收测试，测试哪一个，以及什么时候有效，这表明有问题的功能已经实施。这个衡量标准显示出多少特征通过了他们验收测试。

业务价值燃耗(Burn-Up)：这些跟踪只是像案例点一样燃耗，但都是基于产品所有权签名的业务价值交付的。

缺陷计数：这有几种类型：后冲刺（post-sprint）缺陷的到来、后发布（post-release）缺陷及缺陷分辨率。

技术债务：这是“未完成的工作”，通常发生在当团队过于努力产生冲刺点输出时。技术债务事例会添加到产品博客中，并像其它事例一样优先化。此指标将会跟踪技术债务的位置并预测其趋势。

工作过程：这个指标追踪大量团队在流程中一直使用的条目。得到这种趋势为1。如果得到的结果过高，Scrum大量可能会想培养更好的协作。

案例周期时间：此指标跟踪一个案例从投入工作的完全的周期时长，并帮助团队集中精力在一个案例上。

代码指标：这些帮助确保你不积累技术债务。这里就有好几个：

• 圈复杂度
• 违反编码标准
• 代码重复
• 代码覆盖率
• 死代码
• 代码依赖项
• 抽象性

功能成本：业务功能需要的完成当今来说很有意义，并不仅仅只是很好的执行计划。

我应该跟踪哪些敏捷指标？

组织必须注意他们衡量了什么，因为最终获得的是他们衡量的。这里有一些条目相当容易衡量，但对于他们却有着极其反敏捷的意味：

KLOC（千行代码）。该思想是，大多数生产效率高的开发人员得到的奖励。但我们最终奖励的是，冗长编码人员，他们在系统开发这场游戏中获得胜利。

任务完成。这里我们奖励那些在系统中编写无限个小任务的，然后完成它们的人。但我们是从所有这些工作中得到业务价值呢？

任务工作时长。当进行一个项目工作时，如果我们只希望某个人安静地坐着或站在我们旁边的话，那么我们应该雇佣金毛。它们忠诚且不会抱怨。但我们需要的是参与，而不仅仅只是出席。我们想可能会跟踪到相同的结果。

为了不是跟踪这样的指标，我们应该寻找敏捷度量，它们有一些特定的特点：

他们肯定及强化了精益和敏捷原则。“可工作的软件是首要的进度度量指标。”

它们衡量的结果，而不输出。你希望宁愿每一件事情完成90%，但在工作软件上却没有任何显示，还是希望完成70%，但却交付了软件呢？

他们遵循着趋势，但不是数据。当你学会开飞机时，你的第一个趋势是不断地看表盘。你从来没有完成课程，总是在不断地纠错，这正是我们需要避免的东西。

它们是一小套指标和诊断的一部分。我们需要真正关注在软件艺术品的生产上，这是很重要的（代码），并且尽可能少地拖延我们的课程的进度。

这些很容易收集。有一个好朋友曾经对我说“我可以报告现状，或我可以改变现状，但我不能一次性做这两件事。”我们需要花费我们大量的时间在软件生产上，而不晨报告它的生产上。

他们透露，百不隐瞒上下文。敏捷是诚实、透明的。如果我们收集数据来满足隐藏议程，那么我们对于这些价值来说一点用也没有。

他们给有意义的对话提供燃料。指标只是数据。我们需要在数据中找到趋势和模式来收集我们正在观察的信息。当我们把它与因果关系相联时，我们会发现其中蕴藏的智慧。当我们运用这些智慧，并改进我人瓣软件开发流程时，我们已经完成了所需的敏捷的“检查和调整”的反馈回路。但是如果我们收集数据只是为了收集，我们是在浪费时间，并远离了创建软件的任务。

我该如何进行呢？

这里有一些方法：

• 明智地进行衡量。
• 不要只是因为你能，你就进行衡量。
• 利用你所收集的指标，要么就不要收集它们。
• 寻找强化精益和敏捷的流程指标。
• 寻找可用于减少技术债务的代码指标。
• 如果你们得到我们所衡量的东西，我们将会成为敏捷且精益的软件制作机器。