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、端口、支持協議等方面略有差別。于是這家公司也嘗試了平臺化開發，結果大大縮短開發時間并在市場競爭中領先。我并不認為只有被迫的產品線開發才會取得成功，而是說產品線開發需要業務和市場等方面的驅動，我們可以確認從中收益，這樣有針對性的產品線運作才更有可能成功。

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

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