度量和改进软件开发的工作效率

在《改进软件开发工作效率：软件管理中的高效领导力和量化方法》一书中，Randall W. Jenson 讲述了如何在组织中度量和改进工作效率。这本书中包括实践、模型和案例分析，可以帮助大家以量化方式实施敏捷软件开发。如果想对该书有所了解，您可以点击这里下载样章。

InfoQ 访问了 Randall，请他谈谈如何度量和改进工作效率、使用敏捷对工作效率的贡献、结对编程和团队的好处，软件维护中的知识留存，以及沟通的四条告诫。

InfoQ：是什么让您决定写这样一本有关度量和改进工作效率的书？

Randall：这个问题可不太好回答。我从1975年就开始做一些工作效率度量方面的工作，当时，我的任务是找到一些办法，来改进我们组织内的软件开发工作效率。第一次的实验包括两个程序员团队，此后他们成为结对编程的团队。这个实验背后的理念是：“两个脑袋胜过一个。”虽然投入工作的人数翻倍，但我们的工作效率提升了125%，而且错误降低了三个数量级。Chuck Tonis、我的经理，还有我，我们确定了一个研发环境的概念模型，发布在1979年的《软件工程》杂志上，其中有一个有效性公式（Effectiveness Formula），基于三个属性：沟通、管理质量和应用的技术。每种属性的值从0到1。组织有效性由这三个属性决定。我们初衷是描述环境，而不是改进工作效率，不过那个公式确实可以预测开发的效率如何。

我的第二个任务是确定软件开发的成本，以及日程估算模型（Seer），这是当今软件开发管理中最常用的模型。

接下来这些年，我直接参与到预测多个大型软件开发合同的成本和日程的活动中，包括一些政府的项目，同时评估组织能力，以满足特定的工作效率目标。我发现：在合同签署之前的评估阶段，概念公式就可以准确组织的工作效率。1995年，我修改了 Seer（Seer II），好让模型可以直接反映出组织本身的能力，以支持有效性共识。Seer II 出现的时机，正是软件开发领域中敏捷方法大行其道的时候，这又进一步证明了概念模型。

2005年之前，公式的正确性、背后的数据，特别是我与其他组织合作中吸收到的经验教训，这些都让我感到很满意。从敏捷开发中获得的数据也能与公式匹配得很好，而且在数据上明显表现出与传统开发过程的不同。该是写书的时候了！

InfoQ：您之前提到：要说起真正的工作效率收益，软件行业得到的结果还很有限。您能不能说明整个的改进到底有多大？

Randall： 从1960年代开始直到今天，我一直在收集各种项目的软件开发数据，并以其作为成本和日期估算工作的基础，这些工作我从1970年代中期就开始了。虽然所有数据中也有一些来自比较新的开发方法，但主要还是来自传统的开发过程。数据从汇编语言项目开始，没有工具，也没有现代方法的支持。几乎所有的改进都发生在工具、语言和方法层面，这些都属于有效性公式中的技术属性。在沟通属性中几乎看不到任何改进，除非将小隔间式办公考虑在内。1900年代早期就定义下来5种管理职能，可相关的管理的风格也没有发生什么变化。工作效率改进的速度时快时慢，但大约是每年每人月1.5行代码（sloc/pm），这从1960年代开始，而且完全来自技术方面。换种表述方式，也就是说1960年的 60 sloc/pm，到今天大约是 140 sloc/pm。这个数据基于完成代码行数，不能代表从汇编到 Fortran 语言带来的3倍提升，也不能说明可视化语言的功效。这纯基于产生的代码行数。

InfoQ：您觉得是什么阻碍了工作效率的提升？

Randall：用一句话总结工作效率为何无法提升：忽略了公式中沟通和管理质量属性。今天的传统开发组织，如果不考虑现在的技术变化，他们的表现和行为方式与1970年代的组织没有区别。

隔间带来绝对隔离，由此消除了沟通和写作。

沟通包括三个部分：视觉、口头和笔头。去掉视觉和口头元素，沟通只能保留原本7%的信息。跟旁边隔间的程序员在网络上沟通，实际上跟阅读笔头文字没有区别。您可以用文字发送问题（写邮件等于另一堆笔头文字），得到回应（也是邮件）。如果不能提供程序员可以面对面沟通的区域，我们就进一步限制了沟通。隔离也会降低士气，因为人们不能像团队一样发挥作用。

根据管理的五项职能，管理质量可以定位为：规划、组织、命令、协调、控制。这些职能限定了传统的管理，但它们无法应对影响工作效率的人的因素。这些问题在1920年代被定义出来，称为“霍桑效果”，在传统管理中完全是被忽略的。在传统组织中，管理者与开发人员之间是完全隔离的。我称传统管理者为指挥者，现代管理者为领导者，换句话说，就是牧羊人和 牧羊犬。

最让我惊奇的是：媒体上已经有很多系统研制领域的成功故事，他们放弃了传统的做法，整个组织像一个团队一样工作。举个例子，Lockheed Skunk Works组织从1940年代中期开始，就已经表现出团队所能达成的最好工作效率。想象一下247天就造出 P80 战斗机。（在软件行业中，）我见过很多很好的项目主管被拿下来，就是因为他们没有使用传统组织做事的方式。

InfoQ：对于敏捷软件开发崛起为提升工作效率做出的贡献，您是怎么想的？

Randall： 敏捷软件开发当然证明了沟通和协作在软件开发中的重要性。敏捷与我们为伴已经将近20年了（如果你考虑1975年结对编程的实验，那还要更长），但对于传统开发方法还是几乎没什么影响。小隔间还存在，管理层依旧奉 CMMI 为圭臬。敏捷开发证明了有效性公式的正确性，以及人在工作效率模型中的重要性。敏捷更重视个体和交互，而不是工具和流程，这明确表明了模型中人的重要性。

InfoQ：您和 Chunk Tonies 一起定义的有效性公式中，描述了工程师可以贡献的价值。您能详细说明吗？

Randall： Chunk 和我定义了软件开发环境的一个简单概念模型，其中基于环境的三个属性：沟通、管理支持和开发技术。这三个属性会决定激励、协作和开发团队的方向。

在为书籍收集资料的时候，明显看出：这个模型可以适用于几乎所有开发环境。Lockheed Skunk Works只是这个模型在系统研制领域环境的一个范例。很多敏捷方法都会利用现代的管理技术和有效的沟通方法。

说远一点，小学教室是另一种融合了学生、教师和技术的环境。如果学生可以协作，还能得到老师的紧密支持，想想那能带来多少效果上的提升。

InfoQ：您在书中提到结对编程的实验。能说说是怎么做的吗？结对方式工作有哪些好处？

Randall： 当时有人让我想办法提升组织的工作效率，我就回到了两个基本想法：（1）两个人的脑子比一个人好使；（2）为了获得电子工程学位时，我在一个团队中努力的经验。当时实验的平台是一个多任务系统集成程序，需要用 Fortran 开发大约50000行代码。有六个独立的任务需要完成。

组织提供了10个程序员，大家的经验各自不同，有的大学刚毕业，有的已经是经验丰富的系统程序员了。当时组成了5个小团队，将最有经验的和最没经验的人放在一起，第5个团队两个人经验水平相当。分配给每个双人团队的办公室彼此距离相近。团队要在一台工作站上一起工作， 一个人作为“司机”，第二个人作为“导航员”或是“观察员”。

项目经理是一个亲力亲为的领导者。 我认为他是完美的牧羊犬，必须克服最困难的阶段——让所有团队都能协作起来。这些团队都没有在团队环境中工作的经验。有一个团队中包括一个资深程序员和他的同伴，资深程序员结束了养育孩子的6年时间，刚刚投入工作，他一开始时是个麻烦。他觉得女同伴应该给他倒咖啡、从打印机那里拿报表，思考的任务就由他自己来做。几次严肃讨论之后，资深程序员发现他的同伴很有才华。

系统集成阶段最能体现这种团队做法的成效。最初的两个任务（大约10000行代码）集成时，只出现两个设计错误需要解决。这种整合发生于两个独立团队之间的组件。第三个任务（大约5000行代码）集成式毫无问题。最后两个任务的集成出现一些错误，但整体效果相当惊人，可谓现象级。他们实现了125%的工作效率提升，而且错误大大降低。

项目结束时的事情，是这次实验最值得铭记的部分。来自实验的结果在组织中高层会议上得以展示。来自其他项目经理的反应是：我们无法实施这种方法，因为组织中的资深程序员宁肯离职，也不愿意参与两人团队。我的想法是：“让他们走，这样反而对我们有利。”项目经理却被调离了项目管理部门，成为计算中心的主管。

InfoQ：您在书中提到与团队一起工作的正面效应。能不能列举一些？

Randall： 团队方式工作的好处包括：激励、问题隔离、头脑风暴、沟通、持续走查、协作等等。我观察到的这些，不过是在重复自己大学时的经验，我们在作业和测试准备上彼此协作。

InfoQ：在您看来，这些来自团队的正面效应能否解释敏捷软件开发带来的工作效率提升？

Randall： 当然。结对编程是敏捷方法之一。整体来看，敏捷就是基于团队的。你能看到，敏捷更重视个体和交互，而不是工具和流程，这明确表明了模型中人的重要性。大体上，敏捷开发是使用团队来解决问题的方法。每种方法都有自己的特点，或者说形式，但是激励、协作、沟通是所有方法的关键。我常思考这样一句话：每个项目都有问题，它们都是人的问题。1920年的霍桑试验是很前沿的研究，证明了人在工作效率提升中的重要性。

InfoQ：有很多因素都会影响工作效率。这会不会使得类似 SEER 这样的估算模型变得不好用了？是否存在轻量级解决方案？

Randall：要估算一个项目，大约需要考虑30个因素，因为存在很多影响因素，比如记忆力限制、需求稳定性、研发系统经验等等。

在不考虑项目约束的情况下，考虑组织的潜在工作效率，那就只要考虑7个参数，而且初步介绍给组织就可以把它们建立起来。如果你只关心自己的组织，你可能已经知道建立基本的工作效率需要哪些正确的值了。

此处会潜伏问题。设定这些参数的值时，你必须诚实。如果你觉得自己的组织在所有组织中大约排名在75名前后，你就很容易反复欺骗自己。现实地评估每个参数是最难的部分。

我常常使用一种快速估算方法，你可以称其为轻量级方法，这是一种交叉检查，我会用其验证工作效率评估：找到最后一个项目达成的工作效率。下个项目的效率可能与该值相当，除非下个项目之前发生了某些事情。如果发现工作效率估算比上个项目提升了25%，你不会接受这样的想法：“比起上次，我们的聪明程度提升了25%。”这只是一厢情愿。

InfoQ：你的书中提到：在软件维护团队中，知识留存是工作效率的重要因素。组织要想留存知识，他们可以做些什么？

Randall：大部分软件开发估算模型中包括的因素，都针对（1）正确的维护，（2）适合的维护，（3）完成的维护。这三个因素都假定：要完成维护工作，需要实施某些变化。大块变化（Block changes）是这三种变化维护的典型。Sage 基于 Seer II，是唯一一种假定运营中的软件不需变化的估算方法。

举个例子，假设我们刚刚接手一个一百万行代码的、正在运行的雷达系统。我们以前也没有这个软件的只是。如果软件存放在打孔的数据上，我们很容易把维护工作量形象化。希望你还能记得那样的日子。一百万行代码需要500盒卡片。要理解、修复这么多盒卡片，需要多少工程师？这个工作量可不能算在软件日常维护变更需要的工作量之内。要想保留这个系统的知识，我们是需要支持5个，还是50个人？要是系统宕机，指望就用一开始分配的几个工程师，马上就能搞清楚系统，做出正确变更，可千万别这么想。要想留存知识，必须付出工作量，这也要算在保持系统正常运作的维护成本之内。顺便提一句，应对这个例子中的系统，要想保留知识，组织平均需要40个工程师。在现实世界中，大约就是每个工程师要处理12.5个盒子（25000行代码）。要参与到这种量级的任务，我觉得没有什么捷径可以提升个人的记忆能力。

InfoQ：您在书中提到有效沟通的四条告诫。您能列举出来，并为想要实施这些告诫的组织提供一些建议吗？

Randall：这四条告诫是有理有据的。第一条：组织不应做任何事情限制沟通。典型的、也是很常见的障碍，就是格子间。在行动相对不受限的开放空间中，团队工作更有成效。

第二条：不要将两个甚至更多团队放在同一个项目区域中。与手上任务无关的人也是障碍，这些外人的出现会造成噪音，降低士气。

第三条：为开发团队提供白板、会议桌、马克笔，以及顺畅沟通需要的爆米花。

最后一条：不要试图在项目之间分享团队成员。这无助于顺畅沟通，也丝毫不利于激励。

敏捷的世界已经认可了这些告诫，或者指导意见，它们是保证想法和工作无碍流动的必要条件。

关于作者

Randall W. Jensen 博士是软件采购方面的咨询顾问，作为计算机软硬件开发的专业人士，有40多年实践经验。过去30年来，他一直积极参与软件工程方法、工具、高质量软件管理方法、软件研发日程制定和成本估算、管理方法度量等多种工作。退休时，他是休斯飞机公司地面系统集团软件工程部门的首席科学家，负责研发软件工程方法和管理方面的研究。他制定出的模型支持了 Sage 模型 和 Galorath 公司的 SEER-SEM 软件成本和日程估算系统。1984年，Jensen 博士获得了弗雷曼（Freiman）参数分析国际大奖中的参数估算杰出贡献奖（International Society of Parametric Analysts Freiman Award for Outstanding Contributions to Parametric Estimating）。他在犹他州立大学获得了电子工程博士学位。可以通过[email protected]发邮件联系他。

查看英文原文：Measuring and Improving Software Development Productivity