关于实施敏捷的度量——访谈 Capers Jones

在今年的早些时候，InfoQ 发表了一篇由 Capers Jones 所写的文章，名为《评估 敏捷和Scrum 以及其他软件方法》，在文中它使用几个标准指标比较了敏捷和Scrum 与其他软件开发方法的效果。

InfoQ 就敏捷绩效的度量、常用的测量方法以及这些方法对敏捷实施的支持采访了 Capers。

InfoQ：感谢 Capers 能够接受 InfoQ 的本次专访。可能有些读者对您还不太熟悉，您能否向这些读者做一个简单的自我介绍？

Capers：我是 Namcook Analytics 有限责任公司的副总裁和技术总监。我用 40 多年的时间收集质量和生产率数据，我发表了超过一打的书和上百篇期刊论文，其中有一篇关于软件度量的文章发表在了《科学美国人》杂志上。

InfoQ：我们已经看到了您为我们共享的数据，数据量非常大。您能举一个例子说明公司正在如何使用这些数据吗？

Capers：公司使用了这些数据和我们的预测工具——软件风险大师（SRM）。我们研究在项目启动之前展示风险、进度、人员配给、工作量、成本和质量。这些研究得益于相似项目历史数据的支撑。这个想法是为了减少延误的风险、成本的超支以及彻底的失败和投诉。

比如，我们可以向用户并行展示瀑布、敏捷、极限编程和许多其他开发方法的实例（其他的公司也在做同样的事情）。比如许多商业评估工具，支持敏捷项目的有 KnowledgePlan、SEER、SLIM 和 SRM 等等。

InfoQ：在你看来，实施度量实践的主要障碍是什么？我们能做些什么跨过这些障碍？当组织想要对敏捷应用度量时，我们可以帮他们做些什么？

Capers：使用敏捷方法会认识到“变化是正常的”，它们应该易于被开发方法处理，所以敏捷方法可以卓有成效地加快开发速度。这意味着应用程序的规模可能最终会有些出入。但是，敏捷已经被使用了足够长时间，有一些历史结果能够展示出一些有用的信息，比如冲刺的数量、随着时间推移的增长率以及从开发累计工作量和发布之后维护的累计工作量。有些项目可以参考借鉴这些质量结果。

在首席执行官、首席信息官和技术总监这一层面很希望在为项目投入大量资金之前就先了解项目将来的结果。度量结果能够帮助他们更好地预测未来。如果敏捷社区想要说服首席执行官和其他总裁级领导实行敏捷工作，那么针对敏捷质量和生产率的度量就可以帮上大忙了。

特别要指出一个问题，手工统计功能点稍微有些慢，使它成了敏捷项目的障碍，而且它还假定了固定的规模。现在流行的快速方法能够在几分钟内预测出规模，还能额外预测出变更的速度，看上去它更加适用于敏捷环境。数个公司致力于自动化或快速统计功能点的领域，包括 CAST Software、Relativity Technologies 和我自己的公司。

InfoQ：当组织从瀑布项目向敏捷方法转变时，会不会影响到他们运用度量来管理软件开发？

Capers：这个问题看起来把敏捷假定成了瀑布唯一的出路。有很多像敏捷一样好的软件方法，甚至有一些会更好。IBM 的统一软件开发过程（RUP）和 Watts Humphrey 的团队软件过程（TSP）常常比敏捷有更高的质量。

有几个敏捷的变体，比如极限编程（XP）和 Crysta 开发看起来也不错。还有几个诸如 IntegraNova 创作软件的方法也比敏捷更快。IntegraNova 是一个来自于西班牙的新方法，已经被德国军队采用，并向美国国防部作了演示。它在一两天内就可以使用需求模型和应用生成器创建出完整的应用。像敏捷那样定制设计和手工编码，速度肯定比不过应用生成或使用有保证的可复用组件。

把问题只限制在瀑布和敏捷上就失去意义了。这看起来就像是在问“从健康角度来考虑，你会选择用巧克力棒当主餐还是用油炸薯片？”你需要有更多的选择。你也需要包括“混合的方案”，这常常是一个非常不错的选择。

InfoQ：明白了。那么我换一种问法：当你从一种方法转移到另一种时，有没有一些可以使用的基础度量，有没有一些可以帮助你们跟踪绩效的指标？

Capers：在这个世界中有两个针对生产率的度量已得到广泛应用，那就是“每人月功能点”和它的倒数“每功能点的工时”。为了评判生产率，每人月超过 10 个功能点认定为好，每人月低于 7 个功能点认定为差。有些敏捷项目每人月可达到极致的 15 个功能点，这在瀑布模式下几乎是不可能发生的。

对于质量来说，最高效的度量是使用功能点和“缺陷去除率”标准化“潜在的缺陷”。潜在的缺陷是在需求、设计、代码、文档和不良的修改中将要发现的缺陷总数。每个功能点潜在的缺陷超过 5 个就认定为差；每 3 个功能点只有 1 个缺陷认定为好。

去除超过 99% 的缺陷的确是个目标，但美国的平均水平只能达到 85%。去除 95% 以上认定为好，低于 85% 认定为差。大多数敏捷项目不去度量潜在的缺陷和缺陷去除率，那么他们并不真正了解质量。

InfoQ：关于团队软件过程（TSP）方法，InfoQ 的读者在你那篇关于比较软件方法的文章上发表了评论说，这篇文章是在“推销”TSP 吗？

Capers：团队软件过程是由 late Watts Humphrey 开发的，受到软件工程研究所（SEI）的肯定。我未从事任何团队软件过程的开发工作，与软件工程研究所也没有任何商业关系。

据我所知，它仅有的收入来源于使用团队软件过程将会花钱购买 Watts Humphrey 有关于团队软件过程的书，而且版税也支付给了 Watts 的产业。我没从团队软件过程上赚过一分钱，也不会在任何其他方法上赚钱。我不推销方法，我只度量它们的结果。

通过度量团队软件过程项目我会有一些收入，但这些收入不会超过度量其他 34 个方法中的任何一个。我的论文中报告了 10 个方法的结果。所有方法提供商未向我支付过任何东西。

InfoQ：敏捷团队可以使用故事点跟踪他们的绩效。考虑到故事点常常只涉及到单独的团队、产品或项目，能够把故事点像功能点一样按同样的方式来使用吗？

Capers：故事点在敏捷项目中广为流行，因为它们可以引导用户思考要用软件做什么事，所以它们具有一定的过渡性价值。在这个意义上说, 它们是有价值的。

故事点没有国际标准，也没有任何像功能点一样的鉴定考试。因此，同一个“用户故事”如果出自不同的项目、不同的公司，可能会有 3 处以上的差异。

在少数项目中，使用了故事点和国际功能点用户组（IFPUG）功能点，看起来有大约 2 比 1 的比例；也就是说，对于同一个应用采用故事点和功能点这两种方式，功能点数大约会是故事点数的两倍。

如果你想要对比一个项目和另一个项目，那你就不太走运了。有基准组织拥有 50,000 多个项目的功能点数据，其中包括大约 5,000 个项目已经由国际软件基准组织 (ISBSG.org) 向公众开放。据我所知，故事点还没有好的基准。

InfoQ：有没有已经证明对团队有益的特定的敏捷实践？有哪些？它们如何为组织实现价值？

Capers：一般来说，Scrum 站立会议看起来很流行，也很有益处。当然，scrum 实践也可以用于非敏捷方法中，尽管它们确实来自敏捷。大多数人认为 scrum 是敏捷独有的，事实上这是错误的。一旦像 Scrum 站立会议这样的做法展现出它的价值，它们也会被蔓延到其他的方法中。

一个更加成功的敏捷实践是“嵌入的用户”，他们已经成为团队的一份子，实时提出需求并验证需求是否已经被全部实现。但有一点要特别警惕的是，嵌入的用户只适用于只有少量用户的规模极小的项目。举个例子，Microsoft Office 有 50,000,000 多个在世界各地的用户，对于这个如此巨大和复杂的应用套件，没有一个用户能够理解它的所有特性。

同样需要警惕应用的规模。一个用户大约能够理解 1000 个功能点的系统需求。对于规模范围在 10,000 到 100,000 个功能点的应用来说，一个用户所能理解的需求不会超过全部需求的 5%。对于这些大型的系统，除了嵌入的用户还需要焦点调研小组和市场研究。

InfoQ：对于正在使用敏捷方法的组织来说，为了有效地开展度量他们还需要做些什么？

Capers：这不仅仅是一个敏捷的问题。通过现场采访数百个软件开发团队，美国平均只收集了 37% 的历史项目数据。最常被忽略的有：没付工资的加班时间、项目管理和专家部分时间的工作（比如科技作者、质量保证、集成和配置管理人员）。首席执行官对软件团队的评价要低于其他的技术组，这应该归功于一贯的乐观估计、进度的拖延、成本的超支、劣质的交付，最终彻底的失败。在所有这些里，软件最糟糕。敏捷打算在一定程度上改善这个局面，但不适用于超过 10,000 个功能点的大型项目，对于敏捷来说这相当棘手。

项目（包括敏捷项目）最好的措施是改善软件社区的专业地位，这也许会使首席执行官比现在更加尊重软件团队。许多首席执行官面对软件团队时，即感到无比痛苦又觉得不可或缺。ITT 的前任董事长 Lyman Hamilton 做过一次公开演讲，在这次演讲中他说，软件工程师以及许多其他工种的工程师（比如电气和机械）在正式工作之前都需要三年的在职培养。

InfoQ：那么外包公司呢，如何度量他们的绩效？

Capers：除非他们一开始就出示定量数据，否则敏捷团队就要自己承担外包的风险。举一个例子，60% 的印度公司使用功能点指标，并用数据证明成功完成。巴西政府现在需要所有政府软件合同中的功能点，韩国政府可能要做同样的事，意大利政府也有这个可能。要把软件项目放在管控之下，功能点是一个关键的成功因素。如果美国敏捷团队想要做海外业务，他们的度量就需要比现在做得更好。否则，他们甚至不能在巴西、韩国之类的国家提出报价。

美国公司可以从巴西处理合同的方式上学到很多东西。他们在早期就已经相当精确得预测出了功能点、工作量、进度表、成本等，通过它们就可以了解规模。

InfoQ：如果一个组织只想做一种度量，您会推荐哪一个？您能解释一下为什么吗？

Capers：如果只想做一种，不管组织选择做哪一种度量，都会失败。这必须要做 1 种以上。

最好的做法是说服总裁和其他人，敏捷将来确实需要:

1. 与其他方法（比如统一软件开发过程、团队软件过程和瀑布）比较时间进度
2. 与其他方法比较工作量和成本
3. 使用每人月功能点度量生产率，或者反过来用每功能点工时

不管如何，你都需要复合的度量手段。这就像试图只选择一种产品作为你唯一的食物，不管你选择牛排还是布鲁塞尔豆芽，如果你只吃一种最后就会生病，然后可能死于营养不良。

InfoQ：确实，但是组织不能在一个时间做每件事情。请给最后一个建议，如何开始度量, 他们怎么做能够提高运用度量的能力?

Capers：其实度量相当简单。你需要通过一个标准的指标（比如功能点）来了解应用程序的规模。你需要了解开发工作量，你需要了解从发布之前到发布后的一个固定间隔内会发现多少错误或缺陷。

在许多合同里这些数据是必须的，大型公司的首席执行官和首席信息官也越来越需要这些数据。软件开发人员需要从低级工艺向专业化转变，度量是朝着这个方向迈出的一步。任何人都曾经花钱请过律师或看过医生，由此可以看出度量是专业化的标准组成部分。如果医生和律师可以做到度量，那么软件社区也可以做到。

当一个印度外包公司访问美国公司时，向首席执行官提议要承接软件开发，很可能这个提议会包括预期功能点的生产率和质量数据。如果美国软件团队不能掌握他们自己的生产率和质量，如何能与外包团体竞争？

InfoQ：您有兴趣听听 InfoQ 的读者有关质量的经验吗？

Capers：如果本次访谈的读者有度量措施，我非常愿意和他们一起讨论，弄清楚他们是怎么做的。

点击此处可以下载：《在世界财富500 强公司里降低公司软件风险》

Capers Jones 的这篇论文阐述了世界财富 500 强的制造业公司如何决定要着手处理全公司范围降低风险的问题。这种降低风险的活动每四年举办一次，它可以作为其他大型公司的典范，这些公司同样对一些常见的软件问题（比如取消的软件项目、进程延期、成本超支、不满客户的投诉以及其他常见的软件问题）耿耿于怀。

关于受访人

Capers Jones目前是 Namcook Analytics 有限责任公司的副总裁和技术总监。这家公司针对风险、成本以及质量设计前沿的评价和度量工具。在 2012 年之前他曾任职于 Capers Jones & Associates 有限责任公司的总裁，曾有 12 年任职于 IBM 的软件研究人员和管理者，在 ITT 公司任职编程助理主任（在这里他启动了他们的软件度量程序事业）。Capers 是一名著名的作家和国际演讲者。他的著作有《软件质量经济学》（与 with Olivier Bonsignour 合著）、《软件工程最佳实践》、《应用软件度量与估算软件成本》等。他目前正致力于第 15 本书的编写，这本书名为《软件工程的技术和社会史》，将于 2013 年冬天出版发行。

Capers 和他的同事已经收集了一些历史数据，这些数据可以用来判断软件过程改进方法的有效性，并且也可以校准软件估算的准确性，质量、生产率和进度方面的软件诉讼也属于诉讼的一部分。他还曾经在 15 起涉及违反合同和软件税收问题的诉讼中担任鉴定证人。

查看英文原文： Interview with Capers Jones on Measuring for Agile Adoption

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大 家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。