【SBE】實例化需求及驗收測試驅動開發之課後心得

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 原則(CardConversationConfirmation, 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 概念,達到需求開發測試一體化。

        這堂課強調高效溝通與團隊協作,很適合同間公司各種角色人員都來上這堂課,因為溝通絕對不是一個人的事。在公司中覺得花費很多時間在溝通上嗎?或者不知道如何開始驗收測試?這堂課相當適合導入自動化測試前的前置課程。

        讓團隊一開始就凝聚共識,瞭解接下來衝刺目標,減少不確定性,透過自動化測試減少無謂的浪費,專注於更有意義的事情上。