敏捷实践效果量化分析

利用 Rally 软件公司的敏捷应用生命周期管理（ALM） 平台软件收集的数据，Rally 软件公司和卡内基·梅隆大学软件工程学院（SEI） 正在研究敏捷软件开发实践的影响效果。该研究的报告在这里可以看到。

InfoQ：你们为什么要量化研究敏捷的影响？

Larry：首先让我作为研究者回答这个问题。关于敏捷实践的出色效果，我们现在得到的很多信息，都是轶事形式，或者适用范围有限。因为 Rally 交付的是多租户的 SaaS 产品，所以我们有独特优势，可以进行这样全面的研究。我们可以访问13，000个不具名团队的数据，他们都使用敏捷实践，而且覆盖众多领域和背景，也就是说，我们可以达成统计显著性、通用性，以及对权衡过程的量化，这都是现有文献缺乏的。

现在，让我换个角度，作为希望交付更好、更快、更低成本的软件的人。大部分组织认为：如果没有大量具体证据，很难同意组织做出大规模转变，比如没有数据可以整合到公司的业务模型中，可以用于证明转变的成本和对公司运营底线的潜在伤害。该研究和我们正在进行的其他研究一起，就是要解决这些问题。

Jim： 还没有人进行过敏捷方法和实践的学术研究。尽管很多案例和调查数据指出，使用敏捷可以带来改善；我们希望更进一步地指出：哪些实践和实践组合、在哪些上下文中效果最佳。

InfoQ：为什么 Rally 和 SEI 要合作进行该研究？

Larry： 我曾经在卡内基·梅隆大学（SEI 所在地）从事研究者工作，当时 Watts Humphrey（时任 SEI 院士）首先提出，应该将量化思考重新引入到敏捷开发的世界中，虽然他们之前将度量方法视为妖魔鬼怪，退避三舍。在2009年的敏捷大会上，我就此想法做了一个演讲，然后得到三个工作邀请。我选择为 Rally 工作，因为他们是行业领导者，而数据又来自多租户的SaaS 软件栈，十分诱惑我这样的研究者。我们最终得到了一个度量框架：软件开发效能指数（SDPI），其基本结构与 SEI 长久以来研究得出的多种度量框架有很多相同之处。所以，自然而然，我们就在一起工作了。Rally 能够接触数据。SEI 能够接触软件工程度量领域中世界上最好的思想领导者。

Jim： 当时， Larry 联系我们，讨论一起进行度量方面的研究，我们马上认识到：这是一个很好的机会，可以用经验主义的方式，验证、强化敏捷对于提升效率的某些说法。Rally对这个研究提供的合作很值得称赞。总是有各种障碍阻止组织分享数据，所以我们非常欢迎这个来自 Rally 的机会。

InfoQ：你们使用了哪些数据供研究使用？又是如何分析的？

Larry： Rally 软件可以用来管理敏捷开发项目。我们可以查看 Rally 中的历史数据，得出效能指标（performance metrics），比如一个中等大小的工作项需要多久才能从“开发中”过渡到“可接受”状态。我们可以得到多种效能指标，涵盖工作效率、可预测性、质量和响应程度。而且，我们可以得出行为指标（behavior metrics），比如有多少个工作项同时处于“开发中”状态，或者看看专为一个团队工作的人完成了多少工作，以及同时为多个团队服务的人完成了多少工作。

Jim： Rally 收集软件开发的原始数据，我们也希望得到多种属性的数据，用于评估实践。为了完成全面分析，我们需要得到组织研发的背景资料，以匹配实际数据。虽然我们得到许可，可以收集一些团队的数据，包括使用了哪些实践、应用类型等等，但对本次研究，还是有些需要的数据不能及时到位。目前我们还在收集这些信息，希望能为将来的研究所用。

我们的确遇到一些数据问题：最大的问题是客户群的变动幅度。对于几乎所有的实际开发数据来说，这样的变动幅度很难建立严格的统计模型，难以分析不同变量之间的关系。也就是说，如果 n 是个很大的数字，一切都能体现出统计显著性，但是难以提供有效的可预测性，因为偏态分布太严重，方差太大。虽然我们使用了多种数据变换方法，以解决这些问题，如果没有对应的属性数据对全体样本分类，我们还是无法取得太多进展。

Rally的工具设计得很灵活，可以整合到多种工作流中，而不是强制用户让他们的工作流程符合工具的设计。这种灵活性对于我们这样的研究来说，是很好的差异来源，因为可以限制我们针对产生数据的工作流做出的假设。因此，数据中的差异水平曾经是个问题，因为如果没有对于实践模式（即工作流设计）的信息，我们就无法做出合理推论，推导出哪些团队模式对应数据中的效能模式。

InfoQ：你们在报告中使用了“软件开发效能指数（SDPI）”度量框架，提供对工作效率、可预测性、质量和响应程度的深入分析。为什么这些指标如此重要，需要加以度量？

Larry： 构成一个完整、平衡的测量体系，需要7个维度，这只是其中4个。目前我们在加入客户/项目干系人满意度和员工参与程度。以后我们还打算加入我称之为“构建正确之物（build-the-right-thing）” 的指标。你可以在今年出版的 “Impact of Agile Quantified - A De-Mystery Thriller”中看到。

InfoQ：研究中得出一个结论：当人们只为一个团队工作时，团队的工作效率就会提升。能否详细解释一下？

Jim： 当我们研究工作效率、质量或是可预测性时，我们看到相对稳定团队的中位数和平均数数据都有提升。但是这种差异被数据的变异多样性遮蔽了，因为数据产生于多种不同的工作流模式。

Larry： 一个团队，它的工作几乎100%都是由专属于它的人完成；另一个团队，只有50%的工作由专属于它的人完成；前者的工作效率是后者的两倍。

使用敏捷之前，人们认为团队中应该配备有特定技能的人，这些特定技能需要得到最大化利用，因此这些人会身兼多个项目。然而，由于任务切换和责任等原因，每个人身上背的项目多一个，他的效率就会呈现指数级降低。参与两个项目，只能发挥80%，参与三个项目，只能发挥60%……以此类推。推进到敏捷的做法，团队只需要响应不断变更的需求（这是敏捷的定义），他们不需要“拥有”全部技能。同时，让一个人只属于一个团队，团队就会迅速走上快车道。即使你的“专家”只能在一半时间发挥他们的特张，把他们只放在一个团队里面还是效果更好。

InfoQ：与之相关的结论就是，不稳定的团队会降低效率？组织应该怎么做，才能预防必须要改变团队构成？

Larry： 我们发现：一般来说，稳定的团队效率要高60%，可预测性高40%，响应程度高60%。

使用敏捷之前，人们的想法是：项目结束时，要将团队拆散；新项目开始，再组建新团队。可是团队要融合在一起并达到最佳效率，这需要时间。同时，因为开始和结束项目从来不会同时发生，几乎可以肯定：在项目开始和结束时，总会有些人不是一直呆在这个团队，而这都是团队效能最关键的时刻。

所以，首要之事，就是让已经达到最高效率、而且凝聚力强的团队接手新项目，而不是为每个项目构建新团队，从而还要再经历一次“初起炉灶—暴风骤雨—照本宣科—大放光彩（forming, storming, norming, performing ）”的循环。然而，不是所有的稳定性问题都源于公司决策。员工离职了，你必须要找人替换。对于这个问题，遵循传统的 HR 思考很重要：让现有员工开心，要比寻找新员工更好。

Jim：我们发现：不只是敏捷，各种软件开发环境中都有切分团队的事情。各种组织都在想尽办法，发现、招募、留住各种专业人才，过去十年也有不少值得注意的软件开发成功案例。敏捷作为一种思想，可以视为解决低效软件开发的一种方法，其目的就是要为团队授权，让有才能的人充分发挥。所以，任何与这种团队核心理念相龃龉的事情，我认为都背离了敏捷原则。

InfoQ：有些团队使用故事点数估算，有些使用任务小时数，有的两种都用。同时使用两种方法，能够为团队带来哪些好处？

Larry： 数据显示，一般来说，使用两种方法的团队，在发布版本缺陷密度上的表现有40%的提升。原因在于，将工作拆分为任务并加以估算，这种行为可以让人更深入思考设计和需要的功能。团队内部对工作会有更多讨论，大家得以分享彼此的理解。这种更多思考和共享的理解，可以预防缺陷流入产品。

同时要指出：我们的研究也得出结论，如果考虑工作效率、响应程度和可预测性，没有进行任务分解和基于小时的估算的团队，整体表现更好。不过，这也可能是因为成熟团队才会采取这种方式，而最终结果源于团队的成熟。

InfoQ：你们的研究也调查了减少在制品（WIP）的效果。在制品更少，能够带来质量显著提升，比如产品中的缺陷更少。能否详细说明？

Jim： 如果将在制品数目进行统计上的标准化，我们会发现，在制品的变化相当于质量指标。但我同时也对工作类型的比率变化感兴趣，不管是用故事还是缺陷。比率的变化，可能是更有效的团队度量指标。发现有意义而且有作用的方式，将数据加以统计上的标准化，这是本次研究的工作方向之一，而且会持续下去。举个例子，你愿意用何种方式计算软件产品的“规模”……类似的讨论没有止境。

Larry： 在制品对软件质量竟有如此重大影响，我们当时也很惊讶。我们当初以为：对响应程度会有很大影响，可能会影响一些效率和质量；但是我们看到：通过控制在制品，能够对发布产品缺陷密度有更大影响。原因可能在于：干扰更少，任务切换更少，而且能够将精力集中在少数几件事情上，这能带来质量的改善。不过，还有一种理论。竭力控制在制品的团队，在工作过程中，当工作受到阻塞，或者某个队列清空之后，没有其他工作可做，他们可以得到一些喘息时间。在这个喘息时间中，人们会更多思考已完成的工作，并用这些时间来确保产品的更高质量。

InfoQ：基于你们的研究结果，你们推荐哪些实践？是不是有哪些敏捷实践是你们不建议使用的？为什么？

Larry： 第一阶段的研究针对5种行为，但我们目前正在研究超过55种变量，包括行为、态度、实践、上下文。结果发现：我们关注的某些上下文变量，得到很多人推荐，而这些变量都与具体上下文密切相关。我想说：没有最佳实践，只有适合某个上下文的好实践。【译注：关于最佳实践，推荐 InfoQ 中文站的一篇老文章[《更好的最佳实践》](http://www.infoq.com/cn/articles/better-best-practices)。】

话是那么所，还是有些实践在很多情况下表现优秀。降低你的在制品。保持团队稳定。让大家只为一个团队工作，确保团队是一个“完整团队”，具备交付产品应有的全部技能。有些实践只在某些环境下才能发挥效果，或者只能带来某一个方面的好处，比如可以提升质量，那就有可能导致工作效率方面的妥协。我们现在还没有准备正式对外发布，不过有几个极限编程（XP）方面的工程实践属于这个类别。当然，仅仅从表面上实施一个实践无法达到预期效果。你必须要认真实施，才能享受带来的好处，或是去掉它的负面影响。

对于我不鼓励的实践，很多与文化和人的因素相关。如果你按照传统方式推动度量体系，就很可能伤害敏捷转换的进程，进入度量的“黑暗面”。我已经把某些内容写成了《敏捷度量七宗罪》一文。第一宗罪，就是试图使用度量指标直接驱动行为。正确的做法，是将其用于自我改善和提升的反馈机制。

Jim： 我同意 Larry 的说法，在制品和稳定性很重要，但我们还需要分析不同实践之间互相组合之后的效能。一般来说，在某些关系上，比如相同全部时间的处理能力和缺陷密度上，我们的确看到中位数和平均数在向期望的方向提升，但还是要说，样本差异太大了。考虑到敏捷是一个原则和价值体系，团队和组织可以选择自己构建软件的方式，而度量指标的使用假定了不同实践之间可以互相比较，由此得来的知识可能不太容易直接应用。

InfoQ：对于量化研发实践，未来还会有更多研究吗？

Jim：我们当然会继续研究敏捷实践效果，我们会去比对产品和质量数据与研发上下文的关系。目前，我们正在准备一个提案，研究这些问题。但在所有软件开发的数据背后，有一个同样的问题：在不同应用、系统和组织中，如何让这样的数据具有可比性？将焦点放在敏捷上，能够让我们获得更多更好的理解，理解如何更好地判断软件产品。

Larry：正如我上面说到的，我们现在正在研究55个另外的变量。其中某些即将公开发表，包括：不同上下文中的理想迭代长度，哪些地区有表现最佳的软件开发团队，不同上下文中测试人员与开发人员之比，等等等等。我会在六月的 RallyON 大会上分享这些内容，还有五月的Lean Kanban大会、六月的敏捷澳洲大会，以及七月的敏捷2014大会。

关于受访者

Larry Maccherone是 Rally Software的分析和研究总监。 在加入 Rally Software 之前，Larry 在卡内基·梅隆大学的软件工程研究院工作了七年，致力于软件工程度量的研究，专精于向敏捷领域重新引入量化理念。他现在带领 Rally 的一支团队，使用大数据技术，取得有趣的结论和敏捷效能指标，并为客户做出更好的决策提供产品。

Jim McCurley是SEI软件工程研究院中软件工程度量和分析计划（Software Engineering Measurement & Analysis，SEMA）技术组的资深成员。他在 SEI 长达17年，专精数据分析、统计建模、经验研究方法。最近几年，他与多个美国国防部部门一起工作，参与到大规模系统的采购之中。

查看英文原文：Quantifying the Impact of Agile Software Development Practices