許多專案難以收尾,便是在專案的前期或中期,太過於輕視確認客戶需求、沒有發掘客戶真正需求的重要性,因而造成了專案接近尾聲時,必須花更多的力氣來處理這些新增的或修改的需求。這麼一來,不僅專案時間會拉長,成本也會跟著提高。

除了需求面上的問題之外,還有一個影響到專案難以收尾的重要原因,那便是輕忽整合。

實作介面不按規範或規範不明確,難以整合
一般來說,程式進行開發時,都會被拆解成各個規模大小不同的模組,而這些模組理論上,本身要有高的內聚力、彼此之間的耦合力則低。所以,這些模組可以分頭進行開發,因為它們本身皆自成一體,而不同的模組之間的相依性相對而言較低,所以,每個模組可以獨立開發、獨立測試,同時,不同的模組之間倚靠設計好的介面相接。

在很理想的情況下,各模組可以平行開發,但終有一天,當它們各自完成程式碼的撰寫及單元測試之後,就會需要將它們整合在一起,確保透過介面相接之後,能夠達到原先設計時的期望。

在整合的時候會發生什麼問題呢?當兩個模組或更多的模組要進行整合時,首先有可能遇到的一個大麻煩便是──根本就整合不起來。

為什麼無法整合呢?通常是因為其中有的模組。沒有依照介面來實作。

這是個嚴重的問題,因為這意謂著完全沒有依照一開始設計的介面去進行程式碼的撰寫。該有的類別、各個類別需要提供的函式、每個函式該有的引數列表,以及回傳的型別,都是各個模組在實作時,必須依照介面規範去實作的。但是,當有任一個模組,並沒有依照介面規範去實作時,其他的模組預期和它進行互動的模組應該具備的介面,但該模組沒有時,自然無法整合在一塊。

整合動作本身就具備測試的性質,因此首先要檢驗測試的,便是各個模組是否正確的實作介面。

當介面設計規範完備時,其實無法整合的機會將降低很多。在我們現實的開發生活中,最常發生的情況是,各個模組之間相接的介面,並不存在明確的設計及規範。各個模組大約需要提供什麼功能或許有默契,但是這個介面並沒有事先約定。那麼,當模組間整合時,自然有可能發生牛頭不對馬嘴。

當欲整合的模組間發生了介面無法匹配,或是預期整合的方式有所落差時,自然得花上許多力氣來重新調整介面,甚至有可能會影響到內部的實作方式,那麼自然會延長整合的時間、增加在整合所花的功夫。

對模組設計的認知差異或不夠完善,也會導致失敗
整合的困難不僅可能發生在介面無法匹配上,也有可能是介面實作正確了,要整合的模組間可以順利接合了,但問題不發生在介面上,而是發生在內部的實作不符合期待。例如,模組A預期模組B的函式F,在傳入特定的參數時,應該要有什麼反應,但實質整合運作時,才發現該函式的實作方式和所預期的不同,因此函式F有了不同的行為反應,這麼一來整合當然失敗。

當模組間進行整合時,會檢驗測試到的,便是各個模組內部的實作是否正確。即使設計完備,這種情況都還是有可能發生,因為對設計的認知難免會有不夠完善的情形,更何況,設計時可能有些細節沒有考慮到十分詳盡,這些細節就會等到撰寫程式碼的階段才會確定下來,這麼一來,便有可能造成兩個模組的開發者之間存在認知上的歧異,也造成了整合上的障礙。

設計完備時都有可能發生這種情況,更別提設計不那麼完備時,各個模組的開發者,對於對方將會有的實作方式假想,其落差自然更大。

當模組整合時,介面的不相匹配,大多在編譯階段便可以查覺,所以,此類的問題姑且不論修改調整的難度,光是找出問題這一點來說,基本上是簡單多了。但是,和預期不同的實作方式是隱藏在介面之中,通常並不是那麼容易把程式碼整合起來、交給編譯器幫你找出不相容的地方,就可以輕易達到目的。

實作的問題,得真的把程式整合、真正讓它運作起來,並且透過整合測試的動作,才有可能找出究竟運作的行為中,有那些其實是被另一方所錯誤看待的。

這類只會在整合後才發現的問題,在單元測試中通常是找不到的。而且,在整合測試時呈現出錯誤的現象時,通常需要花費更多的時間,才能找出究竟問題出在那些模組之中。

要預留多一點時間,因應整合面臨的困難
整合為什麼是一件麻煩的事,是因為當愈多的模組整合在一起時,其複雜度往往呈類似指數的方式在增加。一旦存在問題,想要找到導因的難度、時間,都會隨著參與的模組個數增加而扶搖直上。

整合很困難,但就和確認需求一樣,許多人往往都忽視了它的重要性和嚴重性。攤開很多專案的時程表,你會發現,其中整合的時間往往都被大大的低估了。因為在很多人的想法裡,個別的模組才是最花時間的地方,「模組都寫好了,不就把它們給整一整就好了嗎?」

等到專案的開發進入尾聲,各個模組單元都大致就緒、開始進入整合的階段時,才會開始發現整合其實不如想像中容易和輕鬆,需要耗費的時間及力氣時常都遠在想像之上。

許多專案之所以難收尾,和整合階段難度時常被低估,也脫離不了干係。原本專案經理預期要開始收尾了,但是進行整合時,才發現問題層出不窮,解了一個問題還冒出更多問題,問題成長的速度比解決問題的速度還要快,當然會對究竟何時才能把這尾巴收掉,信心愈來愈低落。

但很有趣的是,大多數人很少從這樣的經驗中認識到,整合其實有著遠超乎想像的難度,然後將這個經驗回饋到下一次的專案中。在下一次的專案中,還是會同樣低估整合會造成的困擾及障礙,然後同樣因這樣的低估,而讓專案再度難以收尾。

可以考慮用持續整合的做法,及早解決
整合的本質在先天上就是難,但是重視它、運用各種方式,可以降低它的難度及帶給專案的那些不可預期的事情。例如,重視設計、運用好的設計技巧,以及利用各種方式,來強化不同模組開發成員之間的溝通,減少彼此認知上的差異、提前偵測出問題等。

專案經理在安排時程上,也應該正視整合階段本身就是個充滿變因、不確定性高的階段,不能太過於輕視,否則,在專案後期會給你最大重擊的,往往就是這個整合階段。

面對整合的困難,XP(極限編程)提出的解決方案也很有趣,在XP中認為,既然整合這麼重要,那麼我們就不斷地、持續地做整合,這種「持續整合」的實務方針,也是XP重視整合因而提出的解決方案。

面對整合,我們可以有很多種不同的解決,但是,我們一定得重視它,否則,你的專案恐怕又要面臨不知何時才能收尾的疑問。

專欄作者

熱門新聞

Advertisement