为什么值得投入

抛开所有困难的原因，那些已经成功过渡到Scrum的公司的利益相关者都为他们已经做了这样的转变而高兴。让他们觉得满意的原因之一是使用Scrum这样的过程缩短了产品上市时间。敏捷团队的高生产力能使产品快速上市，这也促使敏捷项目能产出更高质量的结果。由于员工产出高质量的工作成果，并且这些工作成果更快交付给等待中的用户，工作满意度也因此得到提升！与更高工作满意度随之而来的是，员工有了更高的工作热情，这会带来更多生产力方面的回报，从而形成一个持续改进的良性循环。

第2章余下部分将深入探讨这些观点。与此同时，我还会阐述支持每个观点的证据。有一些证据是趣闻轶事性质的，它们来自于我的经历，我的客户和同事的经历，或者是一些杂志或技术会议上报道的一些经历。此外，这些观点也由如下来源的数据提供支持。

　一个针对26个敏捷项目和基于7500个传统项目基准数据资料的严格对比。这项研究是由Michael Mah进行的，他是QSM Associates的管理合伙人（QSMA）。QSMA收集项目相关的绩效、质量以及其他度量数据已经超过15年。Mah研究的敏捷项目规模在60人～1000人之间（Mah 2008）。

　各种学术和研究论文，包括David Rico博士的综合研究，David Rico博士曾对51个已经发表的敏捷项目的研究做过调查。

　由敏捷工具供应商VersionOne在2008年进行的超过3000人的在线调查（2008）和Dr. Dobb's Journal期刊进行的642人的调查（Ambler 2008a）。Dr. Dobb's Journal是一个知名技术开发杂志。这些调查都是在2008年进行的。

当然，像这样的行业调查不能作为具体的答案。个人选择这种调查很可能倾向于有利于敏捷的视角。这里使用这些调查的结果是因为它们更具有代表性而不是决定性。这些调查在接下来的几个小节中被引用为VersionOne及DDJ。

在下面几个小节，我们来看为什么值得向Scrum这样的敏捷过程转型：

　更高的生产力及更低的成本

　员工的参与度和工作满意度增强

　更快的产品上市时间

　更高的质量

　项目干系人的满意度提升

　现在的做法不再有效

更高的生产力及更低的成本

遗憾的是，没有普遍认同的衡量生产力的手段。Martin Fowler甚至说，衡量开发人员的效率是不可能的（2003）。虽然我同意Fowler的观点，但我确实认为衡量生产力的替代物或替身是有可能的。有些团队使用代码行数作为衡量生产力的替代物，而另外一些团队以交付的功能点数或者产品特性的数目作为衡量生产力的替代物，忽略特性或功能点大小不一的情况。使用这些替代物来衡量有问题吗？当然有。但我认为通过替代物的方式来衡量生产力的效果是合理的，如果我们能够合理地假设团队产出的代码行数和功能点没有造假，比如通过复制代码，或者不考虑功能点可复用，等等。在许多情况下，特别是那些涉及大型数据集（像QSMA研究）的情况，我认为这是一个合理的假设。

QSMA为其数据库中的项目计算一个生产力指数。该指数会考虑工作量、进度、技术难度及其他，旨在让跨团队的比较更有意义。在敏捷和传统项目之间的比较中，Mah发现敏捷项目的生产力要高出16%，他发现的这些增长有统计学意义。图1.1显示了QSMA数据库中的敏捷项目（敏捷项目用点表示）和行业平均生产力的一个对比，旁边是一个标准差。可以看出，这些点大多高于行业平均水平，少数项目的生产力甚至还超过了行业平均水平一个标准差。

QSMA的结论得到了DDJ和VersionOne的调查证实。82%的DDJ调查参与者认为，使用Scrum敏捷方法时生产效率有些提高或者提高很多，只有5%的人认为生产效率有降低或低得多。73%的VersionOne受访者认为敏捷明显提高了23%或50%的生产力。生产力提高了，成本当然会更低。

VersionOne和DDJ的研究都证明了这一点，在表1.1(2)中可以看出。

2008年出版的David Rico的敏捷团队案例研究调查结果如表1.2所示。David Rico发现，报告的生产率提高的平均值为88%和节约成本平均值为26%。这些证据表明敏捷团队有较高的生产效率并且能节省他们的项目开支。

尽管这些数字是令人鼓舞的，但它们只是故事的一部分。敏捷的一个重要好处（这里没有体现出来）在于敏捷团队不太可能开发用户不需要的功能。对顺序开发过程（标准瀑布模式）的常见批判是软件交付的时候提供了用户不再需要的功能。由于频繁反馈、时间箱式的Sprint和每一个Sprint重新排列优先级，Scrum团队更有可能只开发用户真正需要的功能。如果我们在考核生产力时考虑到这一点，会看到更明显的结果。

员工的参与度和工作满意度增强

也许，员工比以前更喜欢他们的工作，这也是敏捷项目能有更高的生产力和更低成本的一个因素。实施Scrum 15个月之后，Salesforce.com对其员工做了一个调查，调查发现86%的员工认为在公司工作快乐或者很快乐。在实施Scrum之前，只有40%的人这样认为。此外，92%的员工表示，他们会向其他人推荐敏捷方法。类似这样的结果很普遍，我的客户做了很多员工满意度调查，始终得到类似的结果。通过对整个行业范围的调查，VersionOne发现，74%的受访者认为士气得到改善（44%）或显著改善（30%）。

员工更热爱自己的工作，其中一个原因是敏捷过程提倡可持续的开发步调。卡尔加里大学的Chris Mann和Frank Maurer研究了某个团队在转型到敏捷团队前一年和后一年的加班数量（2005）。他们发现，在实施敏捷实践之前，团队成员平均加班比例是19%，采用敏捷过程之后，他们的加班比例降低了三分之二，达到平均7%。

此外，正如团队转型到敏捷前后的标准差测量所示，实施敏捷后，即使是偶尔需要加班，加班的量也不会太多。敏捷软件架构师Johannes Brodwall说：“在我们开始敏捷后，加班似乎不是那么平常了。测试人员对这个效果的感觉尤其明显，因为在过去，他们的工作量极其繁重。”

更少加班可能只是敏捷团队中的员工具有更高工作满意度的因素之一。其他因素还包括日常工作具有更好的可控性，习惯更快看到自己的工作成果，与同事更紧密的协作，制造的产品更有可能满足客户和用户的期望，等等。对自己工作和雇主更满意的员工会更好地参与工作。员工参与度增强能使企业获得更多的利益。

更快的产品上市时间

和传统团队相比，敏捷团队倾向于更快地发布他们的产品。根据VersionOne的研究，64%的参与者认为产品上市时间有了改善（41%）和显著改善（23%）。通过26个敏捷项目和基于7500个传统项目的数据资料的对比，QSMA得出敏捷项目的上市时间要快37%，如图1.2所示。

敏捷团队可加快产品上市时间有两个原因。第一，敏捷团队的高生产效率使其能够更快开发功能。第二，敏捷团队更有可能增量发布。当项目的干系人意识到团队在每个Sprint都能产生有价值的功能时，他们常常决定他们不需要等着包括所有功能的大爆炸似的一次性交付。

快速实施Scrum之后，Salesforce.com很快意识到这些好处（Greene and Fry 2008）。图1.3显示了2006年（实施Scrum之前）和2007年（差不多年初开始转型的时候）交付客户的功能特性总数。该图显示了一个简单的度量：交付的功能原始数据和交付时间，说明在使用Scrum的第一年里给客户带来的额外价值。

更高的质量

如果问Scrum团队是什么使他们比使用Scrum之前更高效，大多数人会说他们的成功至少部分归功于他们能不断地产出高质量的工作。没有遗留的缺陷拖累他们，所以他们可以持续不断地快速前进。因为按照可持续的节奏来工作，质量得以提高。质量的提高还因为采用了许多工程技术实践，比如结对编程和重构，强调更早、更多的自动化测试。

David Rico的研究证实了敏捷团队能产出高质量产品的观点。在他调查的51个公布的敏捷项目研究中，最低提高水平是10%，平均提高水平在63%。我之前对客户质量结果的度量或报告与Rico的研究结果一致。以为中等规模的商户提供退休计划的ePlanServices为例。大多数服务都通过一个很强大的Web应用程序提供。在开始Scrum转型的前9个月中，他们的千行代码缺陷率下降了70%。

VersionOne的调查也证实Scrum此类敏捷过程的质量更高。60%的受访者回答认为敏捷过程使软件质量提高（44%）和显著提高（24%）。另外，84%的受访者认为敏捷降低了10%甚至更多的软件缺陷；30%人认为降低了25%甚至更多。DDJ的调查结果类似，48%的受访者认为质量有了提高，29%的受访者认为有了很大的提高。

项目干系人的满意度提升

前面已给出敏捷过程的所有好处，这些当然足以增强项目干系人的满意度。DDJ的调查报告发现，实施敏捷可以带来干系人满意度的提升（47%）和很大提升（31%）。

项目干系人对敏捷过程更满意的一个原因在于敏捷实践能更友好地应对优先级别的变化，这也是当今快节奏和激烈竞争的企业环境下一个不争的事实。VersionOne的研究显示，92%的受访者认为敏捷提高了企业管理不断变化的优先级的能力。另外，因为可以更容易地调整优先级，所以参与敏捷项目的这些干系人也体会到了变化带来的影响。PetroSleuth公司的一个项目干系人对此深有体会，PetroSleuth是油气行业的一个小型开发公司。

Scrum过程让我们更多地参与每日评审和讨论。这也让他们可以对任何变革的过程有更多的了解，更早建立责任感。

VersionOne的调查更深入地显示了让干系人满意的附加因素。表1.3表明绝大多数受访者一致认同几点：敏捷可以使技术团队和商业团队更容易达成共识；敏捷可以降低项目的风险；敏捷能够更好地管理优先级的变化；敏捷有助于提高项目的可见度。

Steve Fisher是Salesforce的高级副总裁，他也扮演着Salesforce许多敏捷团队项目干系人的角色，他如此表述Scrum实施情况：“完全可见的交付，完全透明和令人难以置信的生产效率……大获全胜”。（Green 2008）

现在的做法已经不再有效

考虑实施Scrum的最后一个因素是当前的开发过程已不再有效。若过去有效的某个过程不再有效，通常倾向于将这个过程做得更好。这正是雅虎所遇到的情况，他们的首席产品主管Pete Deemer是最早意识到需要变革的成员之一。

最初，雅虎尝试Scrum完全是破釜沉舟，瀑布式的做法显然不再有任何成效，通过一年的尝试让瀑布模式做得“更好“，通过更彻底的计划与分析，更彻底的文档，更多的签字等。结果，这只能让事情更糟糕，而不是更好。那些看到好处的团队，大多是尝试Scrum的团队，这些好处几乎一眼就能看出来。

控制台视频游戏开发商High Moon Studios，其前任首席技术官Clinton Keith讲的故事与此类似：

作为一个成功的项目经理，在项目刚刚启动、资金充裕的时候，我们感觉可以“更彻底地”应用瀑布模式于我们雄心勃勃的新项目。实际与我们预期的效果恰恰相反，项目急剧失控。我们的假设是错误的，这也迫使我们重新思考需要如何管理项目。