l

2017年3月22日 星期三

[還少一本書] Specification By Example

March 22 09:00~10:54

屏幕截图 2017-03-15 15.39.38

 

今年因為在北科兼任的「軟體生命週期管理」課程中教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)來輔助說明規格,如此不但可以減少對於規格的誤解,這些案例還可以做為日後相同事件發生時的檢驗標準(驗收測試)

屏幕截图 2017-03-22 10.25.40

 

  • (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個流程模式可以用下圖表示

屏幕截图 2017-03-22 09.50.59

***

讀中文版還是英文版?

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

***

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

沒有留言:

張貼留言