提升敏捷开发中的生产力

概述

在准备一场敏捷大会的主题演讲时，我们通过推特发布了两条消息。第一条提到，一个耗资1000万欧元的瀑布模型项目惨遭失败。第二条消息称，一个数百万欧元的Scrum项目也毫无成果。这两则消息引发的反应截然不同。

针对瀑布模型项目的评论非常严厉：“你自找的，现在就得承受后果。” 人们还辩称，该项目本就不该采用瀑布模型。

而针对Scrum项目的回应则完全不同。有人提出，该项目可能错误地使用了Scrum，或者采用了“ScrumBut”——即以“我们做Scrum，但……”为特征的变体形式，代表对Scrum的不当应用。简而言之，问题不在于方法本身，而在于团队执行的方式。这种差异令人深思。

当传统项目失败时，我们归咎于方法论；但当敏捷项目失败时，却很少责怪方法。真相介于两者之间。研究显示，相比瀑布模型，敏捷项目更有可能成功。但这并不意味着敏捷项目必然成功。根据我们的经验，无论是传统项目还是敏捷项目，失败的根本原因始终是实施方式，而非方法本身。真正的问题从来不是方法，而是人。

顺便提一句，关于瀑布模型的消息是虚构的，用于测试公众反应。然而，关于Scrum项目的消息却是真实的。

改进措施

当组织选择敏捷时，其背后的原因往往并不清晰。动机多种多样：可能是为了提升生产力或缩短上市时间，希望更好地掌控项目耗时与预算，或是因为过去十年里从未成功交付过任何项目。当然，也可能仅仅是因为CEO、CIO或CTO听说敏捷是当前的潮流。

要成功推行敏捷，关键在于明确这一方法如何才能取得成效。实施敏捷是一项持续改进的过程，旨在提升软件质量。敏捷被引入，是为了缩短上市时间、改善组织内部协作，或提高项目生产力与可预测性。

敏捷的实施是一个变革过程。不仅方法需要改变，组织文化与员工思维模式也必须随之转变。因此，除了指导新方法的应用外，还必须提供辅导，帮助组织成员适应新的工作方式。

为了有效展示这一改进过程的成效，必须建立以下几点：

明确量化目标

明确组织希望通过实施敏捷实现什么，并将其量化。敏捷是一种手段，而非最终目标。

我们曾辅导过的一家组织表示，希望将每单位智能用例点的生产效率提升至10小时。另一家组织强调要大幅减少生产环境中软件缺陷的数量。第三家组织的CIO则希望“所有岗位终于能够协同合作”。后一个目标难以量化。

建立基线

建立基准数据以衡量改进效果。当前项目的生产效率如何？团队完成一个点需要多少小时？每月报告多少缺陷？

有一家组织希望将生产效率提升至每点10小时。最初估计其当前效率约为每点20小时。我们在一个正在进行的项目中首次测量发现，实际效率为每点50小时。

从一开始就进行测量

尽早开始测量。幸运的是，在敏捷项目中这通常很容易实现。因为每个工作项都在短周期内完成。结合固定尺度的估算，可以在首个迭代阶段就测量生产效率。记录每个迭代完成的点数以及每点所花费的工时。

立即对比

通过从一开始就开展测量，可以立即判断改进是否朝着既定目标推进。

请记住：没有测量，就无法实现改进。