# 十三、稿紙原型開發
幾年前Excel團隊想知道,讓用戶能用鼠標拖放電子表格格子好不好。他們叫幾個實習 生用最先進的Visual Basic 1.0「快快地弄出一個原型」以便作可用度測試。結果卻花了整 個夏天,因為這個原型必須重現很多真正的Exce l功能,否則就沒辦法做真正的可用度測試。
可用度測試的結論呢?沒錯,這是個好功能!負責的程序員只用了大約一星期就實作出 完整的拖放功能。這個笑話當然就是原型的唯一意義就是要「節省時間」。
一年后另一個最高機密的微軟團隊又用最先進的產品Asymetrix Toolbook(天啊,真不 敢相信這東西還活著),替一套新使用接口制作完整的原型。原型花了大約一年才做好。而 真正的制品Microsoft Bob,(軟件界的PCjr)的下場是另一套廢棄的原型。
基本上我己經放棄軟件原型了。如果原型可以執行所有產品的功能,倒不如直接當作產 品,如果不能的話原型也沒多大用處。還好有個更好的點子:紙上原型。它一下子就徹底的 解決了這個問題和冰山問題。更幸運的是,Carolyn Snyde「剛剛針對這個主題寫了一本很好 的新書:紙上原型制作。這本書對任何設計使用接口的人來說都是很基本的參考數據,而且 書寫得很好。
- 第一部分 位與字節:編程實踐點滴
- 一、語言的選擇
- 二、深入底層
- 三、joel測試:改進代碼的12個步驟
- 四、每一位軟件開發人員必須、絕對要至少具備UNICODE 與字符集知識(沒有任何例外!)
- 五、輕松寫就功能規格說明書 - 第1節:為什么煩心?
- 六、輕松寫就功能規格說明書 - 第2節:什么是規格說明書?
- 七、輕松寫就功能規格說明書 - 第3節:但是……如何?
- 八、輕松寫就功能規格說明書 - 第4節:技巧
- 九、輕松制訂軟件進度表
- 十、每日連編是朋友
- 十一、難伺候的故障修復
- 十二、軟件開發中的5個世界
- 十三、稿紙原型開發
- 十四、不要被太空架構師所嚇倒
- 十五、開火與運動
- 十六、人員技能
- 十七、源于計算機學科的三個錯誤思想
- 十八、二元文化
- 十九、自動獲取用戶故障報表
- 第二部分 開發人員的管理
- 二十、面試游擊指南
- 二十一、重金激勵害多利少
- 二十、二不配備測試人員的五個首要(錯誤)原因
- 二十三、任務換人有害無益
- 二十四、絕不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序設計界的LordPalmerston
- 二十八、評測
- 第三部分 Joel對常態問題的遐想
- 二十九、RickChapman解讀愚昧
- 三十、在這個國家狗是干什么的? 我們有多么天真?
- 三十一、作為哼哈二將,只管去做事
- 三十二、兩個故事
- 三十三、巨無霸麥當勞與天才廚師JamieOliver
- 三十四、沒有什么像IT看起來那么簡單
- 三十五、提防非自主開發綜合癥
- 三十六、策略I:BEN&JERRY公司與AMAZON
- 三十七、策略II:雞與蛋問題
- 三十八、策略III:讓我回去!
- 三十九、策略IV:大件與80/20神話
- 四十、策略V:公開源代碼的經濟因素
- 四十一、墨菲法則肆掠的禮拜
- 四十二、微軟公司是如何敗北API之戰的
- 第四部分 對.NET稍多的評說
- 四十三、微軟精神失常了
- 四十四、我們的.NET對策
- 四十五、請問,我可以使用連接程序嗎