2.2　开发速度的四个维度

无论是陷入了试图避免错误的困境中，还是正在通过采用有效的面向进度的实践将项目迅速推进，你的软件项目都有四个重要的维：人员、过程、产品和技术。人员完成任务要么快，要么慢；过程调节人员的时间，或者是铲除一个一个绊脚石；产品以一个自我完善的形式定义，或者是以阻碍人员达到最好效果的形式定义；技术促成或者阻碍开发的实现。

为使开发速度最快，需要充分发挥这四个维度的作用，如图2-3所示。

对于这张图，我总是听到有些工程师说：“嘿！这不是四个维度，而是四个方向，你不能这样画。”是的，他们是对的，我画不出四维，此处只能以二维来表示。但我想给出的概念是多维，而不是多个方向。

软件开发方面的书籍总是试图强调一维而弱化其他维，但实际没有必要在人员、过程、产品和技术之间重此轻彼。如果它们之间是方向的关系，那么对人员的重视将削弱对技术的关注，对产品的重视将削弱对过程的关注。但由于它们是维的关系，因此你可以同时注重人员、过程、产品与技术。

软件组织倾向于将他们不关注的维看成是固定的，我认为这是项目计划，特别是项目进度计划挫败的一个原因。当我们只关注于某个维时，几乎不可能满足每个人的目标。真正的快速开发是要求你整合应用各类实践方法（Boehm et al 1984，Jones 1991）。能够有效实施快速开发的软件组织都会同时优化快速开发的四个维度。

一旦你认识到四个维度中每一维对软件开发进度的巨大潜在作用，你的计划就会变得更加丰满、更富于创新、更加有效，也更可能满足你及其他合作伙伴的愿望。

以下部分讨论这四个维度，并讨论它们之间的协同关系。

2.2.1　人员

不同人员之间经验的不同导致绩效差别是有目共睹的，你可能对不同开发人员之间生产效率差距达10:1的观点较为熟悉，或者你可能熟知一些明确的激励措施所带来的正面影响。

对于大多数开发人员（包括业界的大多数人）来说，人们所不熟悉的是对人件（peopleware）的研究。过去15～20年中，在人件研究方面已经有了稳定的积累。因此在众多个体研究结论的基础上进行分级，并根据未来发展趋势形成结论是完全可能的。

第一个结论是，从某种程度上讲，我们已经认识到人件比其他因素对软件性能与软件质量的影响更大。从20世纪60年代后期开始，反复的研究发现，经验相当的程序员之间效率的差别也是很大的，甚至达到10:1（Sackman、Erikson and Grant 1968，Curtis 1981，Mills 1983，DeMarco and Lister 1985，Curtis et al. 1986，Card 1987，Valett and McGarry 1989）。

研究也表明，整个项目团队的效率差异变化在3:1～5:1之间（Weinberg and Schulman 1974，Boehm 1981，Mills 1983，Boehm、Gray and Seewaldt 1984）。根据对实际项目20多年的跟踪，NASA软件工程实验室的研究人员已经得出这样的结论：技术并不是问题的答案，最有效的实践是那些能够发挥开发人员潜能的实践（Basili et al 1995）。很明显，人件极大地影响着生产效率，同时任何关注提高生产效率的组织首先必须有一套良好的人员激励、团队合作、人员选择及培训的机制。当然，也有其他提高劳动生产率的途径，但人件所带来的效益潜能是最大的。如果你特别关注快速开发，就必须对人件给予特别关注，将其放在过程、产品和技术之前进行考虑。如果想成功，你必须能很好地驾驭它们。

这个结论是显而易见的，但无论如何不能成为人件主义的借口。研究结果只是简单表明个体能力、个体激励、团队能力和团队激励的作用大于其他生产率因素，但并不是说一个团队只要有T恤衫、免费的碳酸饮料、有窗户的办公室、绩效奖金或是周五下午的酒会就可达到激励的目的，但这里的含义是清晰的：任何想提高生产率的组织都应主动采取这些措施。

本书涉及几种发挥人员最大潜能以缩短项目周期的方法。

1．项目组成员的选择

Barry Boehm在他的标志性著作《软件工程经济学》（Software Engineering Economics）中，提出了选择项目组人员的五个原则（Boehm 1981）：

·　绝顶的天才——用更少更好的人。

·　工作匹配——使任务与人员的技能和动机相匹配。

·　职业的晋升——帮助人员自我实现，而不是强制地把他推到他最有经验或最需要他的岗位上。

·　团队平衡——人员选择应强调人员之间的互补与协调性。

·　排除不称职的人员——应尽快排除或替换不称职的人员。

其他导致效率差别的因素还包括人员的设计能力、编程能力、编程语言经验、机器与环境经验和应用领域经验等。

2．团队组织结构

人员的组织方式对人员的工作效率有很大的影响，软件活动可以从调整项目团队以使之与项目规模、产品特点以及进度目标相匹配中受益。特定的软件项目也可以从适宜的专门组织中受益。

3．人员激励

一个缺乏动力的人不可能努力工作，其业绩只能是逐步下滑。没有比人员激励更能使人自觉放弃晚上和周末的休息时间而努力工作的了，也没有什么方法比人员激励更适应于不同的组织、不同的项目和不同的人员。人员激励是使你能够达成快速开发的最具潜力的方法。

2.2.2　过程

软件开发的过程包括管理方法学与技术方法学。评估过程对开发进度的影响远比评估人员对开发进度的影响容易得多，软件工程研究所（SEI）和其他的组织在过程的标准化和推行高效软件过程方面做了大量的工作。

过程几乎与人员一样是影响开发速度的一个重要因素。10年前，曾有过注重过程是否有价值的争论，而如今，如同人件一样，注重过程已变得无可争议。在过去的几年中，像休斯飞机公司、洛克希德、摩托罗拉、NASA、雷神公司及施乐，通过对开发过程的改进，将产品上市时间缩短了一半，降低成本、减少错误为原来的1/3～1/10（Pietrasanta 1991a，Myers 1992，Putnam and Myers 1992，Gibbs 1994，Putnam 1994，Basili et al 1995，Raytheon 1995，Saiedian and Hamilton 1995）。

有些人认为注重过程会使工作变得呆板，的确有些过程过于严格或者过于官僚。少数人建立一些过程标准主要是为了显示他们自己的权力，而对权力和过程的滥用，将无法获得关注过程所能得到的益处。过程滥用最常见的现象是忽略过程，而忽略过程的结果是，使明智的、尽责的开发人员在无须他们以某种方式工作时，会发现他们的工作效率低下，工作目的交叉重复。关注过程可以帮助解决这些问题。

1．避免返工

如果在项目最后阶段改变需求，你可能不得不重新设计、重新编码并重新测试。如果直到系统测试阶段才发现设计有问题，你可能不得不扔掉已经细化的设计和编码，然后从头开始。软件项目节省时间一个最直接的方式就是要确定你的过程，从而避免重复工作。

雷神公司因其将返工成本从41%降低到10%以下，并同时将生产率提高了3倍而获得了1995年IEEE计算机协会软件过程成就奖。这两项卓越成就之间的这种关系并不是一种巧合。

2．质量保证

质量保证有两个目的，第一个目的是确保交付的产品能够达到可接受的质量水平，虽然这是主要目的，但这不属于本书的范畴。质量保证的第二个目的是在各阶段以最少的时间代价（以及最小的费用）查出错误。很显然，应尽早在错误发生的时候就查出来，错误在产品中停留的时间越长，清除错误所花的时间和费用也就越多。质量保证是任何快速开发过程中必不可少的部分。

3．开发基础

在过去的20多年中，软件工程领域中的绝大部分问题都与软件快速开发相关。许多工作是侧重于生产率而不是快速开发本身，因此其中有些是针对用更少的人员完成同样的工作，而不是更快地完成项目。但你可以从快速开发的角度去理解这些原理，从20多年的艰苦经历中学习到的教训可以帮助你平稳地处理你的项目。虽然，标准的软件工程实践，如分析、设计、构建、集成和测试，本身不能加快项目进度，但可以防止项目失控。快速开发的大多数挑战来自于避免灾难，而这正是标准软件工程原理的优势所在。

4．风险管理

侧重于避免灾难的特定实践就是风险管理。在你的进度计划出台前的两个星期，快速开发可能起不到什么作用。对与进度相关的风险的管理是快速开发过程的必要组成部分。

5．资源目标

应该对资源给予足够的重视，一方面它有助于提高总的生产率，另一方面它也可能被浪费掉。在快速开发项目中，资源是极为重要的，甚至有时会对进度造成最大的冲击。本书中的一些最佳实践，如有助于生产力提高的办公条件、时限开发、准确的进度计划以及主动加班等，都有助于你确保每天能完成更多的工作。

6．生命周期计划

有效确定资源的关键之一是将它们用于项目的生命周期框架中，这对具体的项目很有用。没有一个整体的生命周期模型，你在决策不同的资源分配时，很可能每一个个别的计划都符合目标，但综合起来总体上却不满足目标。由于生命周期模型描述的是基本的管理计划，因此它是非常有用的。例如，如果你有一个高风险项目，基于风险的生命周期模型就很适合于你；如果你的项目有一个含糊不清的需求，则增量生命周期模型更有益。生命周期模型可以使你很容易确定并组织软件项目要进行的多种活动，从而更为高效地工作。

7．面向客户的开发

现代软件开发方式与传统主机时代的软件开发方式相比，一个最为彻底的改变是更侧重于关注客户的需求与愿望。开发人员已经认识到开发出符合产品规格的软件只是完成了一半的工作，另一半是帮助客户配置出产品能够实现的功能，而实现这些需要的功能所花的时间远远多于确定纸面上的产品规格所需的时间。让自己站在客户的角度考虑问题是避免大量返工的最好办法，因为是客户来决定你花了12个月开发出的产品是不是合适的产品。你可以从本书有关阶段发布、渐进交付、渐进原型、一次性原型、原则谈判等实践中受益。

2.2.3　产品

在人员／过程／产品／技术这四个维度中，最切实的维度是产品维度。对产品规模和产品特性的关注，意味着巨大的缩短计划进度的机会。如果削减了产品功能，你就可以缩短产品开发周期。如果产品功能是灵活的，你就可以使用80/20规则，先开发只需要花20%时间的80%的产品功能，而后再开发产品另外20%的功能。如果要保证产品灵活的感观效果、性能特色及质量特色，你可以使用现有的部件并编写少量的客户化代码来构建产品。通过关注产品规模与产品特性而实现的确切的进度削减量，只受你的客户心中产品的概念和你的项目团队创造力的限制。

产品规模和产品特性提供了缩短开发时间的机会。

1．产品规模

产品规模是对开发进度影响最大的一个因素，大型产品会花费更长的时间，而较小规模的产品会花费较少的时间。额外的产品功能要求额外的规格、设计、构建、测试和集成，同时要求与产品的其他功能相协调与匹配。由于构建软件所需的工作量的增长要比产品规模的增长快得多，而且增长是不成比例的，所以产品规模的缩小也将大大提高开发速度。将中等规模的软件削减一半通常可使工作量削减2/3。

你可以通过只开发最为必要的功能来彻底缩小产品规模，或者，你可以通过分阶段开发产品来临时缩小产品规模。你也可以通过采用能够减少每个功能所需的代码的高级语言或工具来缩小产品规模。

2．产品特性

虽然不像产品规模的影响那么大，但产品特性确实对软件计划有影响。对性能、内存占用、稳定性及可靠性要求很高的产品比没有这些特性要求的产品需要更长的开发周期。选择你的战役目标，如果快速开发排在优先级首位，就不要同时设置太多的优先级去束缚开发人员的手脚。

2.2.4　技术

从使用低效工具转为使用高效工具也是你提高开发速度的快捷方法。从汇编语言这样的低级语言到像C和Pascal那样的高级语言的转变，是软件开发历史上最为流行的一种趋势。当前向部件（VBX和OCX）转变的这种趋势可能最后会产生相似的结果。选择有效的工具并管理好由此所带来的风险也是争取快速开发主动权的关键之一。

2.2.5　协同

人员、过程、产品与技术之间存在着协同问题。Neil Olsen进行的研究发现，对职员薪金、培训及工作环境的花费由较低水平增长为中等水平时，生产率可以产生比例相当的增长：额外的花费基本可以获得1:1的回报；但当以上的花费从中等水平增长到较高水平时，生产率的回报将迅速上升到2:1或3:1（Olsen 1995）。

软件工程实践也有可以协同的地方。例如，组织范围内的编码标准有助于各个项目的开展，它可以便于一个项目使用另一个项目的部件，同时，部件的重用也有利于编码标准的使用，并确保部件在各个项目中具有相同的含义。设计和代码审核有助于编码标准和现有可重复使用部件知识的传播，可以促进成功使用重复部件的质量等级。好的实践应彼此相互支撑。