絕大多數的軟體開發專案,都會搭配一個時程表來進行。最理想的情況下,我們可以按表操課,按照一開始的計畫行事,最後時間到了,東西也做出來了。不過更實際的情況是,我們邊執行開發工作,也同時監測開發的真實進展,發現有些工作做得比預期快,也有些工作做得比預期慢,專案執行上便會動態的依據實際的執行情況,對未來接下來的計畫做對應的調整。

無論如何,相信絕大多數團隊成員的人最關心的,還是究竟專案何時會結束。明明所有的人都覺得程式已經照著規格及分析設計寫完了,但是還是有層出不窮的需求變更,不知道究竟需要改到什麼時候才能結束。此外,明明程式已經寫完好一陣子,也已經進入測試階段很久了,但是,還是不斷找到新的臭蟲或問題,導致軟體遲遲無法達到可以接受的品質,也就無法正式開始釋出。

程式寫完,不代表專案進入尾聲
我們當然可以計畫時程表,但是時程表是用來反映對未來的規畫和期待,但這不意謂著規畫不會失準,也不意謂著期待必然實現。尤其當專案愈接近尾聲時,大家會愈來愈關心,究竟何時能開始正式釋出。時程表沒辦法回答這個問題,而是我們必須將我們的答案寫到時程表上。因為並不是時程表怎麼寫,現實的情況就會那樣發生。

很多時候,我們覺得開發專案「收尾」很難,因為明明程式都寫得差不多了,為什麼感覺距離能正式釋出還那麼遙遠?

這當然是有一個刻板的印象,一直影響著很多人。

在不少人的心目中,還是認為程式的撰寫是開發的主體,一旦程式寫完了,開發也就差不多告尾聲了。但其實不然,在撰寫程式之外,還有很多事情等待發生。就拿測試來說,事實上,倘若你用一個單位的時間來撰寫程式,往往需要一個單位、兩個單位或更多的時間,來做測試及修正。這個測試時間都是很難壓縮的,但很多人都預期它可以被壓縮。但工作的本質是不會因為它和預期的不同,就被預期改變。需要多少時間,就是需要多少時間。

測試修正所花的時間比想像中要多
我們或許都有過類似的經驗,在時程表中,或許一開始規畫撰寫程式是一個月,接著也安排了測試一個月。不過,隨著時間的過去,因為種種的意外(這倒不難發生),突然發現撰寫程式的時間不夠了,於是決定延長兩週,但是,還是必須維持完成的期限不變。這要如何做到呢?當然就是壓縮測試的時間,把原先測試的時間砍掉一半。

「我們撰寫程式的品質那麼好,測試時間一定可以縮短的。」大家很少期待撰寫程式的時間可以縮短,但卻時常期待測試修正的時間可以縮短。但不斷重複的歷史告訴我們,測試修正的時間一樣很難縮短,甚至常常也比我們預期的還要久。有不少的因素,都影響著專案難以收尾、結束。

透過收斂的作法,加速專案收尾

當我們希望專案能夠盡快收尾時,有兩件事情必須足夠收歛,不再發散,第一是範圍(scope)必須收斂,第二便是品質能夠收斂。範圍收斂通常涉及的是,能否完成足以進入測試階段的程式碼,而品質收斂,則意謂著程式碼的品質是否足以達到正式釋出的標準。

倘若這二者其中之一處於無法收歛的狀態,你是很難預期究竟何時可以完成專案,因為你根本無法預期何時它們才能收歛。想要知道專案何時接近尾聲,就必須觀察這二者是否處於收歛或朝向收歛。

在二者中,範圍通常必須先收斂。有一種慘況是邊撰寫程式碼,需求還邊跟著改變,因為移動的靶子是很難擊中的。另一種慘況是進到測試階段後,代表使用者端的測試人員發現系統和他們想像的不同,或是發現他們的需求不足或不正確,於是開始調整需求。此時,之前在做分析、設計、撰寫程式碼時的一些假設,都可能因此被推翻,設計得好,小改過關。設計得不好,得做大幅度翻修,或是嘗試著在現有的基礎上疊床架屋。但無論是那一種,都會衝擊到原先計畫,進而影響對時程的評估。

範圍不能收歛,代表的就是對需求的變動持續在發生,你無法預測需求變更何時結束,或是無法控制停止對需求做變更。一旦不能把範圍收歛,就代表主要撰寫程式碼的工作無法告一段落,更別提想把專案收尾了。控制開發範圍,將其導進收歛狀態,是專案順利收尾的關鍵之一。

想要看出專案是否即將收尾,可以觀察需求變更的請求發生的趨勢。很多時候,當代表使用者的測試者開始測試之際,是需求變更發生的密集期間,因為使用者初次接觸到一個可以運作的系統時,他們最容易找出開發團隊和他們認知的差異,或是他們本身的認知和現實的差異,之前不過都只是紙上談兵罷了。若是處理得好,需求變更的範圍和次數,會隨著時間愈來愈小、愈來愈少,之後再出現大範圍的變動機會,就降低很多。

那麼品質的收歛呢?當然你同樣可以觀察測試時的臭蟲個數和時間的關係,來判斷是否往收斂的趨勢走,而這也是很多人常用的方式。

常見的方式是繪製一張以時間為X軸,臭蟲個數為Y軸的圖,在圖中繪製四條線的走勢,這四條線分別是:該測試週期找出的臭蟲數、累計找出的臭蟲數、該測試週期內解決的臭蟲數,以及累計解決的臭蟲數。當累計發現和累計解決愈趨近重疊時,代表有可能愈接近收歛,但並不是絕對,因為有可能測試團隊在每個測試週期裡發現的臭蟲,都被程式撰寫者在該測試週期內解決。當累計找出的臭蟲數的曲線愈趨平緩時,代表測試團隊在每個測試週期可以找出的臭蟲數,愈來愈少,這當然是好消息。

在測試開始時,測試者可以發現的臭蟲常常還不會太多,一來,是他們不見得已經很熟悉系統的行為,二來,是一開始很容易踩中一些關鍵性的地雷,使得測試工作無法再繼續下去,例如造成系統異常終止,或是行為完全和規格不同。當到程式撰寫者把這些臭蟲都修正後,系統慢慢進到比較穩定的狀態時,測試者可能就更容易測試臭蟲,因而造成臭蟲個數激增。最後,隨著不斷解決臭蟲,每一個測試週期測試者可以找到的臭蟲就會愈來愈少,直到開發團隊覺得達到可以正式釋出的水準為止(不見得是解決所有的臭蟲)。

除了觀察需求變更,以及臭蟲的個數,來評估範圍及品質是否收歛、開發是否即將收尾之外,其實還可以觀察需求變更,以及臭蟲的類型來判斷。

當團隊收到的需求變更都和重大的業務流程相關時,那麼通常距離收歛還很遙遠。但是倘若收到的,淨是一些修改字型大小、文字顏色之類的需求時,很有可能已經到了收歛的狀態。因為,大多數的人會先把關心的重點放在影響重大的地方,等到使用者開始關心這些細節時,代表那些影響重大的事情都已經做對了,那麼即使再有需求變更,也都是容易處理的小細節了。

品質收歛的情況也類似。測試團隊初期回報的臭蟲通常是那種很容易被複製、很嚴重(例如會造成異常終止)的臭蟲。但是愈到後期,往往會以那種不容易被複製、甚至很隨機出現的臭蟲,或是容易複製但卻不嚴重的臭蟲為主。

前者是因為很難複製不易出現,所以即使很嚴重,也不見得會成為初期關心的焦點,而後者則非重點,即使很容易複製,在初期也不太會有人放心力在上面。當你發現都在處理一些難複製、或是不那麼重要的臭蟲時,那麼常常代表著專案的結束即將到來了。

專案能否收尾和範圍及品質是否收歛息息相關,而範圍和品質的收歛與否,可以透過一些觀察來判斷。當這些觀察告訴我們範圍和品質都在收歛時,那麼就幾乎可預見完成之日了。

專欄作者

熱門新聞

Advertisement