[還少一本書] Specification By Example

March 22 09:00~10:54

 

今年因為在北科兼任的「軟體生命週期管理」課程中教BDD，加上明天晚上在C. C. Agile要分享「SBE、BDD、ATDD、TDD、DDD大亂鬥」這個題目，從農曆年後又把《Specification By Example》（以下簡稱SBE）這本書拿出來讀了一次。第二次讀這本書比較有感覺，趁著記憶猶新的時候介紹這本書的內容。

 

從封底開始看

這本書的內容在英文版的封底已經簡短提示四個重點：

• Common process patterns：本書包含7個「process patterns」（流程模式），書中從Part 2開始用了7章的篇幅來逐一介紹這7個模式。雖然作者用「模式」這個詞彙來介紹他所提出來的7個套用SBE的流程，但書中並沒有使用大家熟知的模式格式。作者提到用模式來記錄SBE的知識還需要一段時間，所以他先把手邊有的資料用比較隨興的方式介紹。希望假以時日這些知識可以被整理成更正式一點的模式，造福像Teddy這種模式愛好者。
• How to avoid bad practices：既然書中提到7個流程模式，自然就會提到那些不好的做法會偏離這些模式，以及如何避免誤踩雷區。
• Fitting SBE in our process：書中介紹的7個流程模式並沒有綁定任何特定工具，讀者融會貫通之後可以自行吸納到自己的開發流程之中。例如，在Scrum、XP或Kanban中套用SBE。
• 50+ case studies：模式之所以被稱為模式，是因為模式針對重複出現的問題提出一個通過驗證的解決方案。本書是作者訪談超過50個案例並加以研究之後所整理出的7個流程模式，書中有大量的業界實踐SBE的佐證資料。書中Part 3特別用了6章來詳細介紹6個不同的案例，值得參考。

***

7個流程模式

本書的7個流程模式為：

• （1）Deriving scope from goals：專案的範圍要如何界定？如果沒有目標，在專案進行的過程中一下子業務說加入A這個功能產品絕對超級賣，行銷說沒有B這個功能無法跟別人競爭，老闆說A.B…Z這幾個功能優先權都是1。照單全收的情況下最後導致功能膨脹，但預計上市的時程又不能延後。開發人員只好加班趕工，想辦法讓系統「看起來可以動」先過了這一關再說。專案團隊成員爆肝也就算了，更慘的是東西好不容易做出來才發現並不是客戶心中所想要的。沒有人要對這一片混亂負責，最後又怪開發人員做太慢、bug太多。

以上慘劇每天都在發生，這當然是大家想要避免的。所以專案的範圍必須從目標作為出發點，思考這個專案到底要給客戶和公司帶來什麼好處，採用「以終為始」的思考方式，對於達成專案目標沒有直接貢獻的功能應該加以排除，以免做白工。

• （2）Specifying collaboratively：目標確定之後專案的規格要由誰來定？剛學Scrum的朋友可能會說：「需求是Product Owner負責的啊」需求是由PO排定優先順序這是沒錯，但並不是說所有需求都是PO一個人寫出來的。從敏捷開發的角度來看，需求是團隊一起討論出來的，這當然包含團隊與stakeholder的互動。SBE更加強調這一點，因此提出協作制定需求規格的建議。
• （3）Illustrating using examples：規格不管是由一個人或是團隊討論而得出，不同的人對於相同規格總是有不同的解讀，這是因為語言與文字存在著模糊性。例如，雖然法律以及大法官對於警察臨檢有著明文規定與解釋令，但不同人對於「警察是否可要求穿拖鞋到小七買飲料的歐吉桑出示身分證」這件事卻很可能有著截然不同的見解。如果可以搭配案例（example）來輔助說明規格，如此不但可以減少對於規格的誤解，這些案例還可以做為日後相同事件發生時的檢驗標準（驗收測試）。

 

• （4）Refining the specification：理解與梳理規格是一個迭代的過程，隨著案例一個、一個出現，專案團隊與stakeholder對於規格越來越清楚，因此需要回頭整理原先的規格。
• （5）Automating validating without changing specifications：等到規格與例子都整理得差不多了之後，就可以開始自動化。這個自動化的過程對應到Cucumber工具就是撰寫step definition，Teddy在BDD系列文章中已經舉過很多次例子。第5條流程模式的重點是：「自動化驗證而無須修改規格」，要做到這一點剛開始並不是很容易，實際做法可參考〈BDD（19）幫開發票功能加上使用者介面的三種方法〉。
• （6）Validating frequently：既然已經把對於規格的驗收條件給自動化了，就必須要經常驗證這些條件，以確定系統進度與確保系統品質。
• （7）Evolving a documentation system：最後，這些可自動執行與驗證的規格、例子與程式介面便成為系統的活文件（living documentation）。因為文件內容是由stakeholder與專案團隊共同討論，而且文件與程式碼隨時保持同步，因此是具備實際參考價值的活文件，而不像很多專案文件與程式已經不同步，變成沒有參考價值的死文件。

▼以上7個流程模式可以用下圖表示

***

讀中文版還是英文版？

經過Teddy這一番解釋，鄉民們先在腦袋裡面建立起這本書的概念圖，然後再去讀這本書應該比較容易看得懂。這本書有出正體中文版，Teddy也買了一本，內容翻譯的不錯。但是，Teddy對於正體中文版有一點覺得非常、非常的傻眼，那就是：「Specification By Example為什麼要翻譯成『Spec.實例化』？」把一個完整的名詞拆成兩半，前面用英文後面用中文讀起來真的不太習慣，讀正體中文版的時候每看到一次「Spec.實例化」就好像撞到一次牆一樣，思緒就被中斷一次。為什麼不用「實例化規格」、「規格實例化」或是直接用SBE都好。因為這個名詞貫穿整本書，用了「Spec.實例化」這個翻譯真的讓Teddy每看到一次心中就碎念一次啊。

***

友藏內心獨白：這是介紹SBE還是介紹Pattern啊。