最近剛好在 Facebook 上看到朋友提到,軟體開發工作上竟然收到了一份規格,是做成投影片格式的,讓他大感驚訝。這件事情讓我想到,對軟體開發來說,規格是很重要的一件事情,究竟為什麼我們需要一份規格、規格應該以什麼形式呈現、以及規格中應該包括那些元素呢?這是一個值得探討的主題。

功能規格的重要性
我們可以說,所謂的規格,就是用來描述所開發出來的軟體應該具備的特質。

軟體規格依據其性質可以再做區分,例如,所謂的「功能規格」,指的就是軟體開發完成之後應該具備的樣貌,包括了它面對使用者或其他系統的介面,以及它的諸般行為。「功能規格」著重在從外界看來,軟體產品是什麼東西;而所謂的「技術規格」所涉及的,則像是軟體產品內部實作層次的規範,像是資料結構、演算法、或是運用的程式語言、程式庫、以及應用程式框架、……等等。在談軟體開發的規格時,我們所最關心的,應該還是以「功能規格」為主。

軟體開發如果不寫規格的話,會發生什麼事?在以前的文章中曾經提到過,軟體規格這些在程式碼撰寫完成之前就先行產出的開發產物,其實是代表最終所要開發出來軟體的模型。

就像蓋房子前,會先繪製的草圖或小模型一樣,我們可以在投入實際的施工之前,先讓關心最終產物究竟會長什麼模樣的利益關係人,都可以先透過一個簡單模型的建構,來明白究竟這個開發專案會做出什麼東西出來。

開發一整個軟體所需耗費的力氣,遠大於完成一份軟體規格,若是透過些許的投資,便能夠完成一份規格,並且有效讓利益關係人知道,究竟這個開發案會得到什麼產出,那麼相較於必須等待整個軟體都完成之後,才能夠知道,這些許的投資顯然是極為划算。

這邊所指的利益關係人,包括了使用者端的人,他可能是公司的老闆、產品經理,也可能是接下來要做系統設計的人、也可能是開發者,當然也有可能是測試者。

所以,一份規格最重要的作用,就是讓代表使用者端的人,可以確認這的確就是他們想要的東西,也讓開發團隊中的各種角色知道,他們應該要做出什麼樣的東西。

確認規格的有效性更重要

沒有產品規格的開發,有沒有可能?當然有,尤其是一人開發的產品最有可能,因為開發者自己「校長兼撞鐘」,自己決定自己要做的東西。不過即使是一個人開發的情境下,透過一份規格,可以在實際動工之前,先全盤思考自己究竟要做出什麼樣的東西,中途持續改變想法時,也可以省去因為需求變更所衍生的種種額外負擔。

有些人不寫規格是想省時間,但很多時候,「出來混的遲早要還」,省去撰寫規格的時間,之後只是在開發過程持續的「加倍奉還」而已。

但這並不是說你寫了規格,或者寫了堆積如山的規格,就一定可以達到它該有的作用。

我常舉一個例子,在生涯中參與的第一個救火專案,就是在離距離交期已經延遲了半年時,才決定打掉重練的一個專案。

這個專案發生了什麼事?

這個專案把開發外包到上海去,因為兩岸相隔遙遠,所以為了避免溝通產生誤差或時間差的問題,所以在臺灣訪談需求後,寫成了一份份量極重的規格書,照同事的說法是「和一個人差不多高」,接著丟到上海去開發。當上海的團隊好不容易把系統開發好了,交到臺灣建置之後,讓客戶端的使用者看了之後,他們都嚇了一跳:「這……這是我們請你們開發的東西嗎?」顯然所開發出來的產物和客戶所預期的,存在不小的差距,而這也就是之所以這個專案幾乎是要從頭歸零開始,徵召多人組成救火隊,重新追趕進度的原因。

這說明了開發時有一份規格當然很重要,但是這一份規格必須真的能夠發揮它的作用,包括了和關心最終開發產物的人確認下來。

在上面的例子中,同時也點出了一個許多人都會有的迷思,也就是規格書寫愈多愈好,最好有一個人那麼高。但是,很容易理解的,規格書的份量並不是愈多愈好,它必須有效的、並且精確的傳達需要被傳達的資訊。並不是厚重的規格、鉅細靡遺地交代一切細節,就一定是好規格,也不是寫得輕薄短小、省略若干細節,就一定是不好的規格。我認為,還是要視當時的時空環境,以及限制條件來決定。

決定規格的形式
有些人會在寫軟體規格的時候,喜歡基於一些模版來著手,不過,其實你究竟需要一份怎樣的規格書格式或體裁,往往取決於應用時的許多因素,就像前一段中所說的:當時的時空環境,以及限制條件。

舉例來說,極限編程(eXtreme Programming)的方法裡就主張簡化規格的描述,建議用所謂user story來描述規格。對一些人來說,這樣的描述可能不夠系統化,也不夠嚴謹,而且認真來挑剔,可能還會略去不少細節。但是,並不能這麼說就覺得這樣的規格不能用,因為極限編程有一些假設的應用情境及配套的方式。

就像這類的敏捷方法,總是預期要快速因應需求的變動,那麼,太重量級的規格寫作方式,就會影響到開發的步調,還有每一次的做改變時的代價。但是簡化規格並不是沒有配套,配套就是像 「user on site」,也就是決定需求的人和開發團隊的人在同一個地點,彼此之間可以很緊密合作。一旦開發團隊需要什麼資訊,都可以隨時得到。

所以說,什麼樣的形式才是一份實用的規格,其實很難有一定的標準答案,團隊採用什麼樣的開發方法、團隊的規模、團隊成員的素質、需求變動的可能性及程度、甚至像團隊成員中溝通的能力等等,都會影響到你究竟決定規格應該以什麼形式,或精細度來呈現。

從實用性來考量規格的形式

回到本文一開頭所提到的,投影片的格式能不能做為規格的文件形式呢?

或許對有些人來說,乍聽之下會覺得很不合理,起碼你也拿個 Word 格式來編一下規格吧!不過,舉例來說,如果你參考有名的 Joel Sposky 曾經寫過的一個規格範例,你會覺得,其實就算這一份規格,都放到一頁一頁的投影片裡,也都挺適合的。而且,投影片還很適合做為簡報的內容,直接跟大家做報告以利溝通和確認。

所以投影片是好的形式嗎?有些情況下,它可能會不錯。規格文件的問題很少是出在它呈現的文件形式,而是出在內容本身。

內容不對,用什麼形式來呈現都不會對,相反的,內容正確了,呈現的文件形式就有比較多的選擇性了。

就像用像 Excel 之類工具裡的試算表文件,一樣有能力表現規格。就像你可以在網路上,找到一些採用敏捷開發方法的人,利用 Excel檔案格式來記錄User Story的例子一樣。

所以說,份量不是問題,形式也不是問題,重點是,你的規格有沒有表現出一份規格該表現出的內容。在下一回中我們會繼續探討。

作者簡介


Advertisement

更多 iThome相關內容