1969年，Mcllroy首先认识到了开创可重用软件组件的需要，但是直到现在软件团体也没有实现这一目标；因此，很容易提出下列问题：如果可重用软件组件的优势如此势不可挡，那为什么没有在整个计算机科学中实现软件组件的重用？
-Grady Booch
Grady Booch[1]先生当然不会不知道其中的原因——实现软件重用的代价颇高，且获得的收益并没有预期的那么高，多数公司和机构知难而退，所以软件重用至今仍然是可望不可及的“乌托邦”，接着Grady Booch当然就要向我们展示UML和RUP的强大威力；但是我们却要延着这一话题来谈谈软件重用进程踌躇不前的真正原因以及软件产品线管理实践中的得失。
其实现代软件开发过程中无时无刻不在重用，重用的范围包括架构和模式（Design Patterns）、应用接口（CORBA、DCOM、J2EE、.NET），组件（MFC、OWL、DELPHI的Component、各种SDK等）、各种语言开发平台和支持工具等等；不过这种程度的重用并不能达到理想的多快好省的开发要求，主要原因就是这样的重用几乎与业务无关——而各软件公司的产品在业务上具有极大的相关性，这就为从更深层次的重用中获益提供了可能，许多公司进行了这方面的积极探索，建立了公司内部的公用技术模块、货架技术、甚至开发规范，然后就像满怀希望的农民刚刚完成播种，憧憬着金色的秋天一样迫不及待的想从绩效中看到丰厚的回报。然而增加了许多额外的工作量后预期的回报并没有出现，是什么原因呢？首先这些期望被重用的模块是零散的，开发工程师在需要时往往不知道从何处寻找，即使找到了却发现在接口、兼容、格式、约束等方面存在这样那样的问题，与其将就用还不如我重新开发一个更好用！就算是发现了合适的组件，遗憾的是软件工程师往往对别人的东西具有本能的“怀疑一切”的态度，所以模块获得重用的机会并不大；需要注意的是一般开发可重用组件的成本比开发一次性组件高出50％，而一个组件被重用的次数超过三次才有可能从重用中受益：结论就是公用模块开发方式的收益并没有想象中那样显著，却增加了单独项目的开发成本。更麻烦的是许多项目的预算仅仅能够满足自己的要求，无法提供足够的资源进行重用组件的开发。许多公司在遇到麻烦的时候果断终止了这种冒险行径，毕竟没有谁会傻到愿意费力不讨好！
“重用”的优点是令人向往的，我们是否没有找到适当途径来重用？既然公用技术模块是零散的、被动管理的，如果采用统一的、与特定业务需求更加密切的方式进行管理又会是怎样的结果呢？这就是采用产品线的方式进行软件开发管理。
软件产品线[2]是指一组具有可管理的公共特性的软件密集性系统的集合，这些系统满足特定的市场需求或者任务需求，并且按照预定义的方式从一个公共的核心资产集开发得到。
软件产品线与其他产品线的定义并没有什么不同，不过核心资产的范围是相当广泛的：包括架构、可重用的组件、需求规格、领域模型、进度计划和预算、测试用例、开发过程定义等等。更重要的是不要忘记“人”是核心资产中的核心！使用这些核心资产资源，我们可以高效构建特定的产品，主要的工作量在于集成而不是重新开发。软件产品线不同于先前的“重用”，也不是对单一产品划分子版本进行开发，也不是一些技术管理规范，只要看看项目组的主要工作是在开发还是在集成就可以清楚他们是否按照产品线方式运作。我并不否认能够从其他开发方式中收益，但现在的重点在于软件产品线。象华为TELLIN智能网上运行各种智能业务，如“200电话卡”、“201校园卡”、“神州行”、“动感地带”、“固定电话预付费”、“193长途卡”、“17931IP卡”、“统一VC充值中心”等等，很难想象工程师面对如此繁多且相似度极大的智能业务系统都会从头开发——他们只是在基础平台上进行少量的开发和配置就可以满足不同的业务需求。
软件产品线可以为我们带来大量的好处：缩短开发周期、降低研发成本、减少产品更新和维护的难度、提供更好的产品质量，进而在竞争中处于领先地位，获取更大利润。对于个人而言也是如此，比如微软开发Windows NT Server时，先做英文版，然后再做其他语言的版本，这样做的结果就使得其他版本和英文版的时间相差特别长，并且很多开发工作是重复的，即费时又费钱。于是唐骏有了同步开发的想法，就做了一套范例和样本，然后开始推广——“我一直认为这是目前为止我对微软最大的贡献，因为他改变了微软的开发方式，使得国际版和英文版的同步性得到了很大的提高”。我想唐骏今天的成功与这次伟大的实践不无关系吧。
听起来很诱人吧？！不过实现产品线方式开发是有一定的风险和约束的，我想每一种管理方法都是在一定的约束环境下才能够获得较好的效果，如果不明确指出就很容易在实践中陷入困境。就像短信广告中只告诉你有机会中大奖，仅在不显眼的地方以肉眼分辨极限的字体写着每条收费一元，而如何取消就更甭提了，当用户看到帐单大吃一惊并懊恼不已时甚至能够听到商贩开心的窃笑！我们并不是在兜售和吹嘘，所以还是清醒一下以免被缥缈的金钱蒙住了双眼。
首先要清楚的就是产品线开发不像单独的项目开发，需要一定的启动成本用于建立核心资产，而最早利用核心资产构建的产品开发周期和成本并不会显著缩短，因为其承担着相当比例组件的开发任务，以及对核心资产的修订和更新，也就是“前人种树后人乘凉”。如果当前项目的资源和进度压力都非常之大时，参考下面这张图吧：
从图上看大约从公共平台上开发三个以上产品就会受益，也许你认为总会有三个产品的，不过产品线会保证成为有效率的开发过程，却不会保证这些产品的市场成功，如果贵公司产品没有销路，多好的过程也无济于事；划到一个产品线下的产品不仅仅是看他们共性有多大，而是要看他们可以共用的共性有多大——例如一家提供通讯设备网管的公司要求产品中70％的部分是平台，另外30％是独立开发的。
从众多采用产品线开发的成功案例中会发现这样一个奇怪的现象：多数是在某种“被迫”的情况下进行的。例如CelsiusTech Systems AB，一家为世界各地海军提供船舶指挥控制系统的瑞典公司，在同一时间被要求建造两个系统，按照惯例需要组建两个项目组分别进行开发，但是麻烦来了——即使是全瑞典也找不到这么多合格的工程师！于是他们希望实现一种解决方案来满足这两个客户的不同需求，以及将来的客户需求；某数据通讯设备供应商发现自己的产品开发速度总是较竞争对手慢——尽管已经配备了足够的研发资源，自己的开发进度几乎达到极限。原因就是竞争对手采用产品线开发方式，其产品拥有极大的相似性：仅仅在容量、速度、Qos、端口、支持协议等方面略有差别。于是这家公司也尝试了平台化开发，结果大大缩短开发时间并在市场竞争中领先。我并不认为只有被迫的产品线开发才会取得成功，而是说产品线开发需要业务和市场等方面的驱动，我们可以确认从中收益，这样有针对性的产品线运作才更有可能成功。
在全新产品的开发中试图建立平台往往难以成功，原因就是仅从一个产品中几乎无法提取什么可以重用的共性：我曾经参与过一个项目，由于业务领域知识的匮乏导致项目开发吃力，此时项目经理听说平台化具有无比的优势（银弹乎？），于是我们采用了平台化方式开发——将界面上与特定用户的标识统统去掉，这样就“提取”了一个“平台版本”——遗憾的是这个“平台”和原来的系统几乎没有什么区别，只是穿了一个“马甲”。
采用平台化开发的风险并非仅来自与公司业务战略的匹配和技术的可行性，更隐含着组织方面的风险：这种不同于单独项目开发的方式需要在组织结构上进行重大的调整，并且需要一位精通产品线运作实践并具有执行力的技术主管负责推行，同时公司还要承担人员职位变化引起的工作效率下降、研发文化转变等带来的或长或短时间的娠痛。请问贵公司做好准备了吗？