Odd-e 實例化需求（Specification By Example，SBE）課後心得。瞭解「需求」與「開發」間的橋樑，降低溝通成本，減少穀倉效應，達到團隊間高效協作。
除了以上好處，SBE 是驗收測試驅動開發的源頭，可讓系統擁有更佳的穩定性、可維護性高、自動化驗證（Automation Check）、和活文件（Living Document），達到溝通與文件與驗證一體化的方法。
一、緣起
遇過「文件」與「信件」溝通的公司，也遇到「開會」數個小時沒有結論的的會議（溝通取得共識成果 0），也碰過長官共識決... 等情況，深深瞭解溝通成本相當相當的高。也常聽到 PO / SA 要的與開發產出不一致的問題，嚴重一點是你做的產品不是 End Users 要的產品。
不過課堂上講師特別強調，面對內部團隊與面對使用者，溝通方法與手段是不同的。先在這邊強調一下，後續會稍微說明。
良好的溝通與協作可以提振士氣，加速團隊產出。溝通產出又能變成自動化測試，讓系統更佳健壯，減少無謂重複性人肉手動驗證（Check），SBE 真的是一魚多吃的好工具。
以上概念上課前就已經知道了，也嘗試使用過，但如何做的更好呢？同堂同學很多人表示看過 Specification by Example 這本書，看完後覺得寫的真好，但不知道下一步該如何走。以上因素是我來上這堂課的主因。
二、用文件 / 信件溝通 vs. 面對面溝通
課堂一開始玩個小遊戲，相當適合帶回公司團隊玩玩。花個 30 分鐘，快速讓你瞭解文字溝通造成誤會。舉個例子：下雨天留客天留我不留，一段文字，各自表述，倒底要不要留客呢？事後與同隊隊員面對面確認需求，結果不到 10 秒就理解且正確做出想要的成果。
這邊的意思不是不要寫文件或不要用文字溝通，面對面透過畫圖與文字溝通，然後將結果轉化成大家都看的懂得文件，這才是比較好的作法。
面對面溝通也是有陷阱的，最常見的屬於知識的詛咒。我希望畫面上左上角有個三角形，設計師完成設計，結果我要的三角形是直角三角形，而設計師給的是正三角形。不是 PO / SA 不和你說清楚，有可能在這個專業領域上，所謂的三角形一律為直角三角形。
這就是為什麼我們需要面對面溝通，需要透過繪畫與實例再次確認需求，需要減少專有名詞帶來的誤會，再將需求共識與實例寫成文字（驗收測試），確保大家的「完成」是一致的。
三、Specification by Example（SBE）
面對面溝通是有技巧的，於 Specification by Example 這本書中，也是這堂課中私認為最重要的地方，如何透過「實例」來溝通。我不會劇透太多，詳情只能自己去上課體驗看看。關鍵是『案例要具體』且『實作 / 操作細節要抽象』，又具體又抽象，中間平衡拿捏才是最重要的。
『案例具體』用來消除知識的詛咒，減少專有名詞或將專有名詞案例化，用大家都瞭解的用語，以一致性的用字來撰寫案例。
『實作 / 操作細節要抽象』不是不關心，而是這些細節本來就是授權給開發團隊去做，譬如：登入失敗時在對話框中顯示「無效的帳號或密碼」。除非使用者非常在意呈現方式，這時才需要寫明。一般使用者只關心資訊呈現是否夠清楚，且如何清楚顯示資訊應該是 UX 或開發團隊可以決定的事。另外，夠抽象才能將此實例運用於各種不同平台上，譬如 Android 與 ios 版本同功能都能共用此實例。
以上拿捏非常難掌握，兩天課程都在討論如何寫好 SBE，上課的好處是有人會逐步帶你瞭解與掌握好具體和抽象間的界線。
對團隊而言，需求中重要的部分寫明，大家一起討論達成「共識」，大家一同完成 SBE，其他細節實作部分授權團隊自由去處理。會需要 SBE，因為每個人的「常識」都不一致，所以才需要團隊共創完成 SBE，這觀念非常重要，絕不是 PO / SA 撰寫就好。團隊如何一起寫好 SBE 呢？課堂中也有說到如何進行 refinement meeting，私認為這也是課堂重點之一，學了以後如何回公司帶領大家一同進步，此部分建議大家去上課，或者未來我實務上嘗試過後再寫一篇心得文吧。
SBE 對內部團隊與對外使用者都相當好用，但別忘了，對外使用者重點不是 SBE，假設你可以接觸到使用者，可以用 SBE 凝聚與使用者共識，但與使用者凝聚共識最好的方法還是「快速交付項目」並「讓使用者看到實體」。去年上過 91's TDD 課程，第三天課程提到「可行走的骨架」，我個人目前需求訪談採用兩階段，先請使用者講解與提供實例方式說明需求，然後回去後，用最快速度打造出「可行走的骨架」，然後展現給使用者看，收取回饋意見，然後才進入開發流程，並盡快交付持續改善。對使用者而言，給他們看到摸到實物，聽取回饋意見並快速改善比較重要。
不管面對誰，只要需要溝通需要凝聚共識，SBE 是極佳的方法，但不是唯一方法。譬如對外使用者還要加上其他方法，才能更佳的溝通。對內部溝通也是一樣，SBE 也能配上 User Story，或著配上各種需求探索方法論，展現給團隊成員，更能凝聚共識。
SBE 不是寫好例子就好，可結合 User Story 的 5C 原則（Card, Conversation, Confirmation, Construction, and Consequence），持續追蹤改善，才能達到 SBE 的效果。
不是回去公司取消所有文件然後改用 SBE 模式，SBE 可以配合各種工具或方法一起使用，切忌不要走火入魔了。
四、驗收測試驅動開發
團隊透過 SBE，凝聚共識產生出各種實例後，這些實例就變成驗收測試案例，代表通過這些實例才能代表完成功能。既然已知這些實例，所以就一併寫成自動化驗證，這就是驗收測試。先寫驗收測試程式碼再開發 Production Code 就變成了驗收測試驅動開發。
一般驗收測試程式分成四層，分別為 Feature、Steps、Page Object、Driver 四層，詳細內容可參考之前我寫過的 TDD 文章（Day 2 與 Day 3）。先說明一下，這四層是最常見的，但不是絕對，依據實際狀況可以再多分幾層也沒問題，譬如：手勢功能於銀幕上先向下畫條直線，然後不間斷向右畫一條水平線，然後再往上直直畫一條線（ㄩ字形），假設這代表 Undo 功能好了，這種多個動作經過特定組合成一種功能，且功能適用於多個頁面上（代表會被覆用），這時就可以再切分出一層專門放這些組合性特殊功能。
另外，現在越來越常見相同功能但要做成 Web、ios、Android... 等版本。既然功能相同，代表這些實例（前提是實例夠抽象）是可以重複利用的。進一步意思是可以將驗收測試抽出來變成共用程式，一套驗收測試程式跑各平台程式。如何做到呢？可以關注 Odd-e 的 CSD 課程（推坑）。
寫好驗收測試是一門學問，也是一種藝術。
五、心得
這兩天課程超快就過去了。透過高效溝通，從需求開始，一路到自動化驗收測試，SBE 是貫穿這條路，將各環節串接起來的方法。在 SBE 前就有 ATDD 與 BDD 的概念，但命名太差了容易被誤會。SBE 花費更多時間在團隊溝通上面，結合 ATDD 和 BDD 概念，達到需求開發測試一體化。
這堂課強調高效溝通與團隊協作，很適合同間公司各種角色人員都來上這堂課，因為溝通絕對不是一個人的事。在公司中覺得花費很多時間在溝通上嗎？或者不知道如何開始驗收測試？這堂課相當適合導入自動化測試前的前置課程。
讓團隊一開始就凝聚共識，瞭解接下來衝刺目標，減少不確定性，透過自動化測試減少無謂的浪費，專注於更有意義的事情上。