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

xmxm76

　　在《改进软件开发工作效率：软件管理中的高效领导力和量化方法》一书中，Randall W. Jenson 讲述了如何在组织中度量和改进工作效率。这本书中包括实践、模型和案例分析，可以帮助大家以量化方式实施敏捷软件开发。如果想对该书有所了解，您可以点击这里下载样章。
　　InfoQ 访问了 Randall，请他谈谈如何度量和改进工作效率、使用敏捷对工作效率的贡献、结对编程和团队的好处，软件中的知识留存，以及沟通的四条。
　　InfoQ：是什么让您决定写这样一本有关度量和改进工作效率的书？
　　Randall：这个问题可不太好回答。我从1975年就开始做一些工作效率度量方面的工作，当时，我的任务是找到一些办法，来改进我们组织内的软件开发工作效率。第一次的实验包括两个程序员团队，此后他们成为结对编程的团队。这个实验背后的是：“两个脑袋胜过一个。”虽然投入工作的人数翻倍，但我们的工作效率提升了125%，而且错误降低了三个数量级。Chuck Tonis、我的经理，还有我，我们确定了一个研发的概念模型，发布在1979年的《软件工程》上，其中有一个有效性公式（Effectiveness Formula），基于三个属性：沟通、管理质量和应用的技术。每种属性的值从0到1。组织有效性由这三个属性决定。我们初衷是描述，而不是改进工作效率，不过那个公式确实可以预测开发的效率如何。我的第二个任务是确定软件开发的成本，以及日程估算模型（Seer），这是当今软件开发管理中最常用的模型。接下来这些年，我直接参与到预测多个大型软件开发合同的成本和日程的活动中，包括一些的项目，同时评估组织能力，以满足特定的工作效率目标。我发现：在合同签署之前的评估阶段，概念公式就可以准确组织的工作效率。1995年，我修改了 Seer（Seer II），好让模型可以直接反映出组织本身的能力，以支持有效性共识。Seer II 出现的时机，正是软件开发领域中敏捷方法大行其道的时候，这又进一步证明了概念模型。2005年之前，公式的正确性、背后的数据，特别是我与其他组织合作中吸收到的经验教训，这些都让我感到很满意。从敏捷开发中获得的数据也能与公式匹配得很好，而且在数据上明显表现出与传统开发过程的不同。该是写书的时候了！
　　Randall： 从1960年代开始直到今天，我一直在收集各种项目的软件开发数据，并以其作为成本和日期估算工作的基础，这些工作我从1970年代中期就开始了。虽然所有数据中也有一些来自比较新的开发方法，但主要还是来自传统的开发过程。数据从汇编语言项目开始，没有工具，也没有现代方法的支持。几乎所有的改进都发生在工具、语言和方法层面，这些都属于有效性公式中的技术属性。在沟通属性中几乎看不到任何改进，除非将小隔间式办公考虑在内。1900年代早期就定义下来5种管理职能，可相关的管理的风格也没有发生什么变化。工作效率改进的速度时快时慢，但大约是每年每人月1.5行代码（sloc/pm），这从1960年代开始，而且完全来自技术方面。换种表述方式，也就是说1960年的 60 sloc/pm，到今天大约是 140 sloc/pm。这个数据基于完成代码行数，不能代表从汇编到 Fortran 语言带来的3倍提升，也不能说明可视化语言的功效。这纯基于产生的代码行数。
　　Randall：用一句话总结工作效率为何无法提升：忽略了公式中沟通和管理质量属性。今天的传统开发组织，如果不考虑现在的技术变化，他们的表现和行为方式与1970年代的组织没有区别。隔间带来绝对隔离，由此消除了沟通和写作。沟通包括三个部分：视觉、口头和笔头。去掉视觉和口头元素，沟通只能保留原本7%的信息。跟旁边隔间的程序员在网络上沟通，实际上跟阅读笔头文字没有区别。您可以用文字发送问题（写邮件等于另一堆笔头文字），得到回应（也是邮件）。如果不能提供程序员可以面对面沟通的区域，我们就进一步了沟通。隔离也会降低士气，因为人们不能像团队一样发挥作用。根据管理的五项职能，管理质量可以定位为：规划、组织、命令、协调、控制。这些职能限定了传统的管理，但它们无法应对影响工作效率的人的因素。这些问题在1920年代被定义出来，称为“霍桑效果”，在传统管理中完全是被忽略的。在传统组织中，管理者与开发人员之间是完全隔离的。我称传统管理者为指挥者，现代管理者为领导者，换句话说，就是牧羊人和 牧羊犬。最让我惊奇的是：上已经有很多系统研制领域的成功故事，他们放弃了传统的做法，整个组织像一个团队一样工作。举个例子，Lockheed Skunk Works组织从1940年代中期开始，就已经表现出团队所能达成的最好工作效率。想象一下247天就造出 P80 战斗机。（在软件行业中，）我见过很多很好的项目主管被拿下来，就是因为他们没有使用传统组织做事的方式。
　　Randall： 敏捷软件开发当然证明了沟通和协作在软件开发中的重要性。敏捷与我们为伴已经将近20年了（如果你考虑1975年结对编程的实验，那还要更长），但对于传统开发方法还是几乎没什么影响。小隔间还存在，管理层依旧奉 CMMI 为圭臬。敏捷开发证明了有效性公式的正确性，以及人在工作效率模型中的重要性。敏捷更重视个体和交互，而不是工具和流程，这明确表明了模型中人的重要性。
　　Randall： Chunk 和我定义了软件开发的一个简单概念模型，其中基于的三个属性：沟通、管理支持和开发技术。这三个属性会决定激励、协作和开发团队的方向。在为书籍收集资料的时候，明显看出：这个模型可以适用于几乎所有开发。Lockheed Skunk Works只是这个模型在系统研制领域的一个范例。很多敏捷方法都会利用现代的管理技术和有效的沟通方法。说远一点，小学教室是另一种融合了学生、教师和技术的。如果学生可以协作，还能得到老师的紧密支持，想想那能带来多少效果上的提升。
　　Randall： 当时有人让我想办法提升组织的工作效率，我就回到了两个基本想法：（1）两个人的脑子比一个人好使；（2）为了获得电子工程学位时，我在一个团队中努力的经验。当时实验的平台是一个多任务系统集成程序，需要用 Fortran 开发大约50000行代码。有六个的任务需要完成。组织提供了10个程序员，大家的经验各自不同，有的大学刚毕业，有的已经是经验丰富的系统程序员了。当时组成了5个小团队，将最有经验的和最没经验的人放在一起，第5个团队两个人经验水平相当。分配给每个双人团队的办公室彼此距离相近。团队要在一台工作站上一起工作， 一个人作为“司机”，第二个人作为“员”或是“观察员”。项目经理是一个亲力亲为的领导者。 我认为他是完美的牧羊犬，必须克服最困难的阶段让所有团队都能协作起来。这些团队都没有在团队中工作的经验。有一个团队中包括一个资深程序员和他的同伴，资深程序员结束了养育孩子的6年时间，刚刚投入工作，他一开始时是个麻烦。他觉得女同伴应该给他倒咖啡、从打印机那里拿报表，思考的任务就由他自己来做。几次严肃讨论之后，资深程序员发现他的同伴很有才华。系统集成阶段最能体现这种团队做法的成效。最初的两个任务（大约10000行代码）集成时，只出现两个设计错误需要解决。这种整合发生于两个团队之间的组件。第三个任务（大约5000行代码）集成式毫无问题。最后两个任务的集成出现一些错误，但整体效果相当惊人，可谓现象级。他们实现了125%的工作效率提升，而且错误大大降低。项目结束时的事情，是这次实验最值得铭记的部分。来自实验的结果在组织中高层会议上得以展示。来自其他项目经理的反应是：我们无法实施这种方法，因为组织中的资深程序员宁肯离职，也不愿意参与两人团队。我的想法是：“让他们走，这样反而对我们有利。”项目经理却被调离了项目管理部门，成为计算中心的主管。
　　Randall： 当然。结对编程是敏捷方法之一。整体来看，敏捷就是基于团队的。你能看到，敏捷更重视个体和交互，而不是工具和流程，这明确表明了模型中人的重要性。大体上，敏捷开发是使用团队来解决问题的方法。每种方法都有自己的特点，或者说形式，但是激励、协作、沟通是所有方法的关键。我常思考这样一句话：每个项目都有问题，它们都是人的问题。1920年的霍桑试验是很前沿的研究，证明了人在工作效率提升中的重要性。
　　Randall：要估算一个项目，大约需要考虑30个因素，因为存在很多影响因素，比如记忆力、需求稳定性、研发系统经验等等。在不考虑项目约束的情况下，考虑组织的潜在工作效率，那就只要考虑7个参数，而且初步介绍给组织就可以把它们建立起来。如果你只关心自己的组织，你可能已经知道建立基本的工作效率需要哪些正确的值了。此处会潜伏问题。设定这些参数的值时，你必须诚实。如果你觉得自己的组织在所有组织中大约排名在75名前后，你就很容易反复自己。现实地评估每个参数是最难的部分。我常常使用一种快速估算方法，你可以称其为轻量级方法，这是一种交叉检查，我会用其验证工作效率评估：找到最后一个项目达成的工作效率。下个项目的效率可能与该值相当，除非下个项目之前发生了某些事情。如果发现工作效率估算比上个项目提升了25%，你不会接受这样的想法：“比起上次，我们的聪明程度提升了25%。”这只是一厢情愿。
　　Randall：大部分软件开发估算模型中包括的因素，都针对（1）正确的，（2）适合的，（3）完成的。这三个因素都假定：要完成工作，需要实施某些变化。大块变化（Block changes）是这三种变化的典型。Sage 基于 Seer II，是唯一一种假定运营中的软件不需变化的估算方法。举个例子，假设我们刚刚接手一个一百万行代码的、正在运行的雷达系统。我们以前也没有这个软件的只是。如果软件存放在打孔的数据上，我们很容易把工作量形象化。希望你还能记得那样的日子。一百万行代码需要500盒卡片。要理解、修复这么多盒卡片，需要多少工程师？这个工作量可不能算在软件日常变更需要的工作量之内。要想保留这个系统的知识，我们是需要支持5个，还是50个人？要是系统宕机，指望就用一开始分配的几个工程师，马上就能搞清楚系统，做出正确变更，可千万别这么想。要想留存知识，必须付出工作量，这也要算在保持系统正常运作的成本之内。顺便提一句，应对这个例子中的系统，要想保留知识，组织平均需要40个工程师。在现实世界中，大约就是每个工程师要处理12.5个盒子（25000行代码）。要参与到这种量级的任务，我觉得没有什么捷径可以提升个人的记忆能力。
　　Randall：这四条是的。第一条：组织不应做任何事情沟通。典型的、也是很常见的障碍，就是格子间。在行动相对不受限的空间中，团队工作更有成效。第二条：不要将两个甚至更多团队放在同一个项目区域中。与手上任务无关的人也是障碍，这些外人的出现会造成噪音，降低士气。第：为开发团队提供白板、会议桌、马克笔，以及顺畅沟通需要的爆米花。最后一条：不要试图在项目之间分享团队。这无助于顺畅沟通，也丝毫不利于激励。敏捷的世界已经认可了这些，或者指导意见，它们是想法和工作无碍流动的必要条件。

温州半自动切纸机故障解析