今年四月,我曾經在公司內舉行兩次 DDD (domain-driven design) 讀書會(1 & 2),試圖推動 DDD 觀念與實踐,以解決日積月累的技術債及文件債。不過,我高估了一般工程師的 modeling 能力,尤其是「透過對話進行 modeling」的能力。

畢竟,「透過對話進行 modeling」其實已經有點偏向商業分析師或系統分析師的工具箱了,若想成為整個團隊成員的共同技能共通語言,可能得培訓好一陣子。

隨後,個人重心暫時轉移到公司的敏捷轉型議題上,就沒繼續強求 DDD 了。

我也思考另一個導入途徑的可能性:SBE (specification by example; 實例化需求)。我只先鎖定在純粹的 SBE 層次,而不過早強調 BDD (behavior-driven design) 或 ATDD (acceptance test-driven design)。



SBE 領域,經典之作,就是神人 Gojko Adžić 寫的《Specification by Example》。

書中,有一系列「成功的團隊」論述:

  • 成功的團隊,不會一次性或針對所有 spec 去實作整個系列的工作。只有當團隊準備開始實現某個功能時,例如,在相關的 iteration 開始時,他們才著手制定 spec。
  • 成功的團隊,不會盲目地接受軟體需求,並將其當作是未知問題的解決方案;相反的,他們會從目標中獲取範圍。他們以客戶的業務目標為起始,接著經由協作來界定可以達成的目標範圍。
  • 成功的團隊,不會依賴於某個人獨自去收集正確的 spec,而會與商務使用者一起協作制定解決方案。
  • 成功的團隊,不會等待 spec 被精確表述,而會舉例說明 spec。團隊與商務使用者一起工作,確定那些描述預期功能的關鍵實例 (key example),說明邊界狀況。
  • 成功的團隊,提煉 (refine) spec,移除多餘資訊,為開發和測試建立一個具體且精確的背景。
  • 成功的團隊,在自動化驗證時,不會去改變關鍵實例的資訊。在自動化期間,他們維持完全相同的 spec——這樣就不會有錯譯的風險。
  • 成功的團隊,不會滿足於頻繁驗證一組可執行的 spec。他們能確保 spec 清楚明確,便於尋找和獲取,而且還具有一致性。

這正是我想要的團隊。

該如何善用這份創造性張力呢?



Specification by Example》是一本有趣的書,是大規模田野調查之後淬鍊的精華,但也過於精練,不容易只看書就能順利照著執行(難怪 Teddy 在某篇文章建議,先讀另一本 BDD in Action 再回來讀這本)。

那麼,上課呢?

即使我曾推坑三位同事參加呂毅老師的 CSPO 課(在【DevOps to Agile 敏捷轉型經驗】演講第 33 分鐘有提到),課堂上也有一場簡單的 SBE 實例演練,但畢竟練習量不多,回來後,無法擴散到他們團隊身上。

我知道,練習量是其中一個因素,與自動化驗收結合是第二個因素。不從這兩方面切入,不易引起興趣。若是有好的引路人,先實際示範幾回合 "specifying collaboratively" 及 "refining the specification" 的過程,並展示 “executable specifications” 的可能性,較能迅速體會殊勝之處。

因此,我一方面開始更積極把關團隊的測試流程品質,為有朝一日時機成熟而鋪路;另一方面,也在物色適當的 SBE workshop,替自己解惑,也觀摩導入手法。

九月底,Odd-e 在台北開設【实例化需求及验收测试驱动的移动和 Web 开发】課程。精實的兩天,完全解答我的疑惑。

課上完後,不僅《Specification by Example》更讀得出味道,也更有導入團隊的把握。



我開始著手籌劃導入。

首先,我挑選團隊中某一研發中的新專案,分別進行三場各約 30 分鐘的暖身活動:

第一週,用類似 DDD 方式檢討其中一個關鍵模型。

第二週,用簡化的 GWT (Given/When/Then) 形式,檢討同一模型。

第三週,再做一次 GWT,並調出既有的單元測試程式來對比檢討。

暖身了三輪,固然挑出一些模型及流程邏輯問題,但真正的重點在於:確定大家對這個案例已有共同的基礎理解,以便在之後正式的 SBE Workshop 中,能以較完整的 Gherkin GWT 形式來 "specifying collaboratively" 討論推演。

接著是自動化議題。

我們公司的主力語言是 Python,為了避免其他人抗拒出自 Ruby 陣營的 Cucumber + Capybara,我也得整合出一個 Python 陣營的替代方案。我將 Behave + Selenium + Chrome + Elementium + Capybara 包成一個 Docker image:

▷ Docker image for Python-based SBE/BDD tools.
https://github.com/William-Yeh/docker-behave

Docker 方案容易安裝,更可利用 data volume 機制漂亮串起資料設置流程,不會弄髒宿主機或測試機環境。

最後,就是重頭戲了:我利用公司每月一次的研發團隊休耕日,進行第一次 SBE Workshop。

而且⋯⋯像歐陽鋒逆練九陰真經一樣,我們逆練 SBE:從研發者及測試者角度出發,逆向工程導出 spec。個人認為滿有教育意義的,馬上清出一些陳年舊帳。

因為是第一次,不要太貪心,先求已經小小示範了兩周的 GWT 三板斧,能夠在這一天真的養成習慣。 反正接下來還有跟進措施:每週再花半小時來集體 refine 這次的成果,深化 SBE 思維。 至於自動化,就等下個月第二次 SBE workshop 再來進行。



一整個白天的 SBE Workshop 帶下來,滿燒腦的,但團隊收穫也滿滿:

  1. 初步體驗領受 SBE 的精神及實踐。
  2. 初步整理出三個 service spec(還有待 refinement)。
  3. 初步學會敏捷式需求釐清的提問法。

這些,都是我認為要成為成熟敏捷戰力的必需裝備。

期待能更邁向《Specification by Example》書中所提的「成功的團隊」境界。