1969年，Mcllroy首先認識到了開創(chuàng)可重用軟件組件的需要，但是直到現(xiàn)在軟件團體也沒有實現(xiàn)這一目標；因此，很容易提出下列問題：如果可重用軟件組件的優(yōu)勢如此勢不可擋，那為什么沒有在整個計算機科學(xué)中實現(xiàn)軟件組件的重用？

-Grady Booch

?

Grady Booch[1]先生當(dāng)然不會不知道其中的原因——實現(xiàn)軟件重用的代價頗高，且獲得的收益并沒有預(yù)期的那么高，多數(shù)公司和機構(gòu)知難而退，所以軟件重用至今仍然是可望不可及的“烏托邦”，接著Grady Booch當(dāng)然就要向我們展示UML和RUP的強大威力；但是我們卻要延著這一話題來談?wù)勡浖赜眠M程躊躇不前的真正原因以及軟件產(chǎn)品線管理實踐中的得失。

其實現(xiàn)代軟件開發(fā)過程中無時無刻不在重用，重用的范圍包括架構(gòu)和模式（Design Patterns）、應(yīng)用接口（CORBA、DCOM、J2EE、.NET），組件（MFC、OWL、DELPHI的Component、各種SDK等）、各種語言開發(fā)平臺和支持工具等等；不過這種程度的重用并不能達到理想的多快好省的開發(fā)要求，主要原因就是這樣的重用幾乎與業(yè)務(wù)無關(guān)——而各軟件公司的產(chǎn)品在業(yè)務(wù)上具有極大的相關(guān)性，這就為從更深層次的重用中獲益提供了可能，許多公司進行了這方面的積極探索，建立了公司內(nèi)部的公用技術(shù)模塊、貨架技術(shù)、甚至開發(fā)規(guī)范，然后就像滿懷希望的農(nóng)民剛剛完成播種，憧憬著金色的秋天一樣迫不及待的想從績效中看到豐厚的回報。然而增加了許多額外的工作量后預(yù)期的回報并沒有出現(xiàn)，是什么原因呢？首先這些期望被重用的模塊是零散的，開發(fā)工程師在需要時往往不知道從何處尋找，即使找到了卻發(fā)現(xiàn)在接口、兼容、格式、約束等方面存在這樣那樣的問題，與其將就用還不如我重新開發(fā)一個更好用！就算是發(fā)現(xiàn)了合適的組件，遺憾的是軟件工程師往往對別人的東西具有本能的“懷疑一切”的態(tài)度，所以模塊獲得重用的機會并不大；需要注意的是一般開發(fā)可重用組件的成本比開發(fā)一次性組件高出50％，而一個組件被重用的次數(shù)超過三次才有可能從重用中受益：結(jié)論就是公用模塊開發(fā)方式的收益并沒有想象中那樣顯著，卻增加了單獨項目的開發(fā)成本。更麻煩的是許多項目的預(yù)算僅僅能夠滿足自己的要求，無法提供足夠的資源進行重用組件的開發(fā)。許多公司在遇到麻煩的時候果斷終止了這種冒險行徑，畢竟沒有誰會傻到愿意費力不討好！

“重用”的優(yōu)點是令人向往的，我們是否沒有找到適當(dāng)途徑來重用？既然公用技術(shù)模塊是零散的、被動管理的，如果采用統(tǒng)一的、與特定業(yè)務(wù)需求更加密切的方式進行管理又會是怎樣的結(jié)果呢？這就是采用產(chǎn)品線的方式進行軟件開發(fā)管理。

軟件產(chǎn)品線[2]是指一組具有可管理的公共特性的軟件密集性系統(tǒng)的集合，這些系統(tǒng)滿足特定的市場需求或者任務(wù)需求，并且按照預(yù)定義的方式從一個公共的核心資產(chǎn)集開發(fā)得到。

軟件產(chǎn)品線與其他產(chǎn)品線的定義并沒有什么不同，不過核心資產(chǎn)的范圍是相當(dāng)廣泛的：包括架構(gòu)、可重用的組件、需求規(guī)格、領(lǐng)域模型、進度計劃和預(yù)算、測試用例、開發(fā)過程定義等等。更重要的是不要忘記“人”是核心資產(chǎn)中的核心！使用這些核心資產(chǎn)資源，我們可以高效構(gòu)建特定的產(chǎn)品，主要的工作量在于集成而不是重新開發(fā)。軟件產(chǎn)品線不同于先前的“重用”，也不是對單一產(chǎn)品劃分子版本進行開發(fā)，也不是一些技術(shù)管理規(guī)范，只要看看項目組的主要工作是在開發(fā)還是在集成就可以清楚他們是否按照產(chǎn)品線方式運作。我并不否認能夠從其他開發(fā)方式中收益，但現(xiàn)在的重點在于軟件產(chǎn)品線。象華為TELLIN智能網(wǎng)上運行各種智能業(yè)務(wù)，如“200電話卡”、“201校園卡”、“神州行”、“動感地帶”、“固定電話預(yù)付費”、“193長途卡”、“17931IP卡”、“統(tǒng)一VC充值中心”等等，很難想象工程師面對如此繁多且相似度極大的智能業(yè)務(wù)系統(tǒng)都會從頭開發(fā)——他們只是在基礎(chǔ)平臺上進行少量的開發(fā)和配置就可以滿足不同的業(yè)務(wù)需求。

軟件產(chǎn)品線可以為我們帶來大量的好處：縮短開發(fā)周期、降低研發(fā)成本、減少產(chǎn)品更新和維護的難度、提供更好的產(chǎn)品質(zhì)量，進而在競爭中處于領(lǐng)先地位，獲取更大利潤。對于個人而言也是如此，比如微軟開發(fā)Windows NT Server時，先做英文版，然后再做其他語言的版本，這樣做的結(jié)果就使得其他版本和英文版的時間相差特別長，并且很多開發(fā)工作是重復(fù)的，即費時又費錢。于是唐駿有了同步開發(fā)的想法，就做了一套范例和樣本，然后開始推廣——“我一直認為這是目前為止我對微軟最大的貢獻，因為他改變了微軟的開發(fā)方式，使得國際版和英文版的同步性得到了很大的提高”。我想唐駿今天的成功與這次偉大的實踐不無關(guān)系吧。

聽起來很誘人吧？！不過實現(xiàn)產(chǎn)品線方式開發(fā)是有一定的風(fēng)險和約束的，我想每一種管理方法都是在一定的約束環(huán)境下才能夠獲得較好的效果，如果不明確指出就很容易在實踐中陷入困境。就像短信廣告中只告訴你有機會中大獎，僅在不顯眼的地方以肉眼分辨極限的字體寫著每條收費一元，而如何取消就更甭提了，當(dāng)用戶看到帳單大吃一驚并懊惱不已時甚至能夠聽到商販開心的竊笑！我們并不是在兜售和吹噓，所以還是清醒一下以免被縹緲的金錢蒙住了雙眼。

首先要清楚的就是產(chǎn)品線開發(fā)不像單獨的項目開發(fā)，需要一定的啟動成本用于建立核心資產(chǎn)，而最早利用核心資產(chǎn)構(gòu)建的產(chǎn)品開發(fā)周期和成本并不會顯著縮短，因為其承擔(dān)著相當(dāng)比例組件的開發(fā)任務(wù)，以及對核心資產(chǎn)的修訂和更新，也就是“前人種樹后人乘涼”。如果當(dāng)前項目的資源和進度壓力都非常之大時，參考下面這張圖吧：

?

從圖上看大約從公共平臺上開發(fā)三個以上產(chǎn)品就會受益，也許你認為總會有三個產(chǎn)品的，不過產(chǎn)品線會保證成為有效率的開發(fā)過程，卻不會保證這些產(chǎn)品的市場成功，如果貴公司產(chǎn)品沒有銷路，多好的過程也無濟于事；劃到一個產(chǎn)品線下的產(chǎn)品不僅僅是看他們共性有多大，而是要看他們可以共用的共性有多大——例如一家提供通訊設(shè)備網(wǎng)管的公司要求產(chǎn)品中70％的部分是平臺，另外30％是獨立開發(fā)的。

從眾多采用產(chǎn)品線開發(fā)的成功案例中會發(fā)現(xiàn)這樣一個奇怪的現(xiàn)象：多數(shù)是在某種“被迫”的情況下進行的。例如CelsiusTech Systems AB，一家為世界各地海軍提供船舶指揮控制系統(tǒng)的瑞典公司，在同一時間被要求建造兩個系統(tǒng)，按照慣例需要組建兩個項目組分別進行開發(fā)，但是麻煩來了——即使是全瑞典也找不到這么多合格的工程師！于是他們希望實現(xiàn)一種解決方案來滿足這兩個客戶的不同需求，以及將來的客戶需求；某數(shù)據(jù)通訊設(shè)備供應(yīng)商發(fā)現(xiàn)自己的產(chǎn)品開發(fā)速度總是較競爭對手慢——盡管已經(jīng)配備了足夠的研發(fā)資源，自己的開發(fā)進度幾乎達到極限。原因就是競爭對手采用產(chǎn)品線開發(fā)方式，其產(chǎn)品擁有極大的相似性：僅僅在容量、速度、Qos、端口、支持協(xié)議等方面略有差別。于是這家公司也嘗試了平臺化開發(fā)，結(jié)果大大縮短開發(fā)時間并在市場競爭中領(lǐng)先。我并不認為只有被迫的產(chǎn)品線開發(fā)才會取得成功，而是說產(chǎn)品線開發(fā)需要業(yè)務(wù)和市場等方面的驅(qū)動，我們可以確認從中收益，這樣有針對性的產(chǎn)品線運作才更有可能成功。

在全新產(chǎn)品的開發(fā)中試圖建立平臺往往難以成功，原因就是僅從一個產(chǎn)品中幾乎無法提取什么可以重用的共性：我曾經(jīng)參與過一個項目，由于業(yè)務(wù)領(lǐng)域知識的匱乏導(dǎo)致項目開發(fā)吃力，此時項目經(jīng)理聽說平臺化具有無比的優(yōu)勢（銀彈乎？），于是我們采用了平臺化方式開發(fā)——將界面上與特定用戶的標識統(tǒng)統(tǒng)去掉，這樣就“提取”了一個“平臺版本”——遺憾的是這個“平臺”和原來的系統(tǒng)幾乎沒有什么區(qū)別，只是穿了一個“馬甲”。

采用平臺化開發(fā)的風(fēng)險并非僅來自與公司業(yè)務(wù)戰(zhàn)略的匹配和技術(shù)的可行性，更隱含著組織方面的風(fēng)險：這種不同于單獨項目開發(fā)的方式需要在組織結(jié)構(gòu)上進行重大的調(diào)整，并且需要一位精通產(chǎn)品線運作實踐并具有執(zhí)行力的技術(shù)主管負責(zé)推行，同時公司還要承擔(dān)人員職位變化引起的工作效率下降、研發(fā)文化轉(zhuǎn)變等帶來的或長或短時間的娠痛。請問貴公司做好準備了嗎？