Joel on Software

Joel on Software   周思博趣談軟體

 

其他Joel on Software文章( 繁體中文)

其他Joel on Software文章(英文)

與作者聯繫 (英文)

 

無痛功能規格 - 第二篇: 規格是什麼?


作者: 周思博 (Joel Spolsky)
譯: Paul May 梅普華
編輯: Jeff Wang 王家麒
2000-10-03

(你看過第一篇嗎? 如果還沒有可以到這裡.)

這一系統的文章是在探討功能規格而非技術規格(譯註:也稱為工程規格). 人們常會把這兩者攪混. 我不知道是否有其他標準術語, 不過我個人的用法如下:

  1. 功能規格純粹由使用者的角度來描述產品如何運作.它不管東西是怎麼做出來的.功能規格會述及功能, 還會詳述畫面,功能表,對話框等等.
  2. 技術規格則是描述程式內部的實作.它會說明資料結構,關連式資料庫模型,程式語言及工具的選用,演算法等等.

當你從頭設計一個產品時, 最重要的一點就是要確定使用者的體驗.要顯示什麼樣的畫面, 運作的邏輯為何, 要達成什麼功能. 再來還要考慮如何達成. 如果產品本身要做什麼都還沒決定, 爭論要用哪種程式語言是完全沒有意義的. 我在這個系列中只會討論功能規格.

我寫了一篇簡短的規格範例, 應該能讓你大致瞭解一份良好功能規格的重點.在我們繼續之前請先 讀這份規格範例.

讀完了嗎?

一定還沒有. 現在就去讀完再回來, 這樣我們才能討論一份良好規格所應具備或不應包含的東西. 我會在這裡等你. 謝謝.

(耐心地等待...)

[Image]

噢, 很好. 你回來了.

下面列出一些我在每份規格上都會放的項目.

一段聲明. 純粹自衛用. 如果你寫一段文字說"這份規格還沒完成", 別人就不會衝進你辦公室把你的頭咬掉. 等時間流逝規格開始完整時, 你可以改寫成"就我所知這份規格已經夠完整了, 不過有什麼漏掉了, 請告訴我" 這提醒我每份規格都需要:

一位作者. 有些公司認為規格應該要由整組人來寫的. 如果你嘗試過團體寫作, 就知道那是最可怕的酷刑.團體寫作就留給擁有大批新出廠哈佛畢業生的管理顧問公司吧, 他們需要做大量的虛工才能收取鉅額費用.你的規格應該由一個人負責並撰寫.產品規模很大時就切成幾區, 讓不同人寫各區的規格. 其他公司認為把個人名字放在規格上會讓他"獨佔功勞", 會太過自我本位,不是良好的"團隊合作"模式. 胡說.人們對被指派的工作 應該要同時有責任所有權.如果規格有問題,在規格上印上大名的規格負責人應該要負責解決. 

腳本. 當你在設計產品時, 一定要想出某些真實存正的狀況以及 人們使用的方法.否則最後就會設計出一個完全沒有真實用途的產品(就像Cue?Cat). 替你的產品選好客戶群,針對每種客戶想像一個完全虛構而又完全典型的使用者,用很典型的方式使用產品. 我的UI設計書(可以在線上免費取得)中的 第9章討論虛構使用者和情境的建立. 這些使用者或情境就是用在這裡的。狀況定得愈清楚愈真實, 針對真實或虛構使用者的設計就愈好. 這也正是我會放入這麼多虛構細節的緣故. 

非目標. 當你和整組人一起建立產品時, 通常每個人都會各有所好, 因而產生各式各樣真正或虛構的必備心愛功能, 如果要將這些功能全部都做出來,恐怕永遠做不完而且要花很多很多的錢. 所以你必須馬上開始刪功能, 而刪功能的最佳方法就是利用規格的"非目標"章節,列出我們不打算做的東西. 非目標可能是個不會具備的功能 ("沒有精神感應式介面!"),也可能是較一般性的定義("我們不在意這個版本的效能.這個產品跑得多慢都沒關係.如果第二版時間夠, 我們會把效率最佳化.)這些非目標很容易引起爭議,不過儘早把它們曝露出來卻是非常重要的. 就像老喬治布希說的:"絕對不會做!" 

概要. 這就像是規格書的目錄. 它可以是張簡單的流程圖, 也可以是段廣泛的架構討論. 大家會先讀這部份知道大致輪廓, 再來看細節才有意義.

細節,細節,細節. 最後會進到細節. 除非必須了解特定的細節, 否則大多數人都會略過這一部份. 當你在設計一個網路服務時, 有個好方法就是把所有可能的畫面都取個正式的名稱, 再對每個畫面用一整章鉅細糜遺地詳述細節.

細節是功能規格中最重要的部份. 由範例規格中, 你可以注意到我對登入頁面各種錯誤狀況有極為詳細的說明. 當郵件地址錯誤時要怎麼做? 密碼錯誤時要怎麼做?這所有的錯誤狀況,都會對應到將要撰寫的真實程式碼, 不過更重要的是這些狀況都會對應到某人必須做的決策. 某個人必須決定遺忘密碼時的處理方式. 由於不決定就無法寫程式, 所以規格就必須把決定寫下來.

未定義項目. 第一版的規格有未定義項目是正常的. 我在寫初版草稿時總是有很多未定義項目, 不過我都會標示出來(加上特殊格式便於尋找), 如果可以的話還會討論各種可選用的方案. 等程式人員開始作業時, 所有未定義項目都必須處理乾淨. (你可能認為, 先讓程式員從簡單的項目做起, 你稍後再把未定義項目定清楚. 這是個壞主意. 光是處理程式人員實作程式時出現的問題就夠了, 根本不會記得還有些舊問題有待處理. 另外解決重大項目時所用的方法也可能會嚴重影響到程式的寫法.)

旁註.在寫規格時要記住你會有各種不同的讀者:程式員, 測試人員, 行銷人員, 技術作者等等.當你在撰寫時可能會想到一些只對某類讀者有用的小資料. 舉例來說, 我會把寫給程式員看的訊息 (通常描述某些技術實作細節)標成"技術註解". 行銷人員直接跳過而程式人員就會細讀. 通常我的規格裡滿滿都是"測試註解", "行銷註解"和"文件編寫註解"

規格必須是活的. 某些程式團隊會有一種"瀑布"心態: 我們會一次就把整個程式設計好, 所以把規格寫好印出來丟給程式員就可以收工回家了.對這種想法我只能說:"哈哈哈哈哈哈哈哈!"

這種作法正是規格如此不受歡迎的原因.很多人都對我說:"規格根本沒用, 因為沒有人會照著做. 規格總是過時而且從來無法反映產品."

原諒我. 你的規格可能總是過時又不能反映產品. 不過我的規格可是時常更新的. 只要產品還在開發而又出現新的決策, 就會持續進行更新. 規格總會反映我們對產品運作的最佳認知. 只要在程式完成時(也就是所有功能完備但尚未測試除錯)規格才會凍結不變.

為了讓大家好過一點, 我不會每天重新發行規格. 通常我會在伺服器上放一份最新版供大家參考. 遇到特別的里程碑時,我會印一份出來, 裡面加上修訂標記讓大家不必重讀整份文件(他們可以快速地發現修訂標記以便找出變更所在).

誰該寫規格?請看第三篇.



文件來源: Painless Software Specifications Part 2 (英文) 

約耳.斯珀儿斯奇是Fog Creek Software (設立在紐約的一家小型軟體公司) 的創立者. 約耳畢業於耶魯大學 (Yale University) ,並曾經在微軟, Viacom 和 Juno 擔任程式人員与管理工作.


這些網頁的內容為表達個人意見
Copyright ©1999-2005  Joel Spolsky. 所有權利皆予保留 使用規定

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky