第一次使用 BDD 開發專案

BDD(Behavior-driven development)是一個敏捷軟體開發的技術,可以讓
PM(產品經理)、PG(開發人員)、QA(測試人員)或其他角色,採用共同的方法與自然語言來溝通,這能夠更容易達成共識,同時也能有效降低轉換領域的成本ーー就是指溝通成本。

簡介 BDD

要完成一項軟體開發的任務,常見的組織協作,會需要 PM、PG、QA 一起完成。PM 決定產品的樣貌並撰寫規格文件、PG 透過 PM 提供的規格文件開發軟體、QA 依照規格文件來安排測試案例。

三個角色的專業與職責都在不同領域裡,因此必須要透過溝通才能完成任務。面對面或 IM(即時訊息)等直接的溝通方法對於簡單的事物會很有效率,但要是資訊量太過龐大時,更常見的做法是撰寫規格文件溝通。在上述的協作流程裡,規格文件會由 PM 產出,交由 PG 和 QA 閱讀並轉換成各自領域的內容。

以開發者為例,網路上有非常多文獻都在說明,開發過程有更多時間都在讀程式,而不是寫程式,因此如何寫出好閱讀的程式碼,是非常困難,同時也非常重要的。然而,PM 寫出來的規格文件真的是大家能夠閱讀並理解的嗎?這就不一定了。

如同程式碼能夠透過單元測試來輔助理解,規格文件可以透過「描述行為」來輔助理解。說穿了,「描述行為」就是像下面這些的東西:

  • 使用案例(Use Case,雖然很像測試案例,但它不是)
  • 更完整的使用者故事(User Story)
  • 文字版的領域故事(Domain Storytelling
  • 當規格大家聽不懂時,PM 就會說:舉個例子好了…
  • 反過來的例子,PG 描述太技術無法理解時,通常也會使用舉例溝通

先把「描述行為」準備好之後,PG 再開始開發軟體,這就稱為 BDD,因為 PG 是根據使用者行為(behavior)來確認軟體的樣貌,並依照這個理解開發軟體。

回頭看一下開始說的:「BDD 是一個敏捷軟體開發的技術」,引用敏捷軟體開發宣言如下:

個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃

同時又提到,敏捷比較重視左邊的粗體字。然而,「描述行為」是完全符合敏捷宣言的。

它能夠幫助 PG 和 QA 用更短的時間去理解 PM 心裡所期望的軟體樣貌,同時也是合作溝通很有效的方法(上面也有提到,PM 跟 PG 都很常舉例說明);更重要的是,描述行為等同於描述一個可用的軟體,這一類的文件對團隊執行任務是非常有價值的。

實際的方法也非常簡單:用講故事的方法來描述使用者如何操作軟體。例如,共用的身分驗證服務會有的故事可能是下面這樣:

當 使用者進入登入頁
並且 輸入正確的帳號 [email protected] 與正確的密碼並按下登入
那麼 使用者成功登入

然後最重要的是:把故事加入規格文件中,這個意思就是,這些使用者的故事應該要是規格的一部分。

也許會有人(通常是 PM)質疑做這件事的必要性,這裡來說明「沒有故事」會影響開發任務有多大。

  1. 最常見的,開發人員當對某個規格描述不清楚時,當然一定要找 PM 釐清。這時可以使用世界上最好用的釐清方法--舉例,而舉例正是講故事:「當使用者進入登入頁…」
  2. 開發人員只從規格文件去開發軟體,通常都是完成功能,不一定是完成流程,因此這時就會需要找 PM 確認,什麼樣的情境會使用到這個功能。這時可以使用世界上最好用的溝通方法--舉例,而舉例正是講故事:「當使用者進入登入頁…」。
  3. 反過來說,PM 如果完成了規格文件,但沒有試著「講故事」的話,這就表示規格沒有被驗證過。這時可以使用世界上最好用的驗證方法--舉例,而舉例正是講故事:「當使用者進入登入頁…」

其實講故事就是在描述情境(Scenario),PM 對於描述情境可能會有種種困難,但有個最核心的理由,所以情境必須要由 PM 開頭寫:

產品經理的職責是決定使用者情境。

雖然沒有看過有文獻會這樣寫,但是透過反證法:PG 和 QA 無法決定使用者情境,因此是確實由產品經理來決定的。

PG 可能會有技術限制無法完成 PM 的需求,這時會提出建議的替代方法,但這依然會由 PM 做最終決定。

做這件事真的不容易,它對開發團隊也非常有價值,因此能夠成功完成這件事的 PM 真的很厲害。

第一次的經驗

事實上,這不是我第一次嘗試 BDD。早在很多年前,我有試著跟當時 PM 協調,當時話語權不夠,也不大會溝通,因此最終 PM 還是沒有寫出任何一個情境,最後我也就放棄了。

這次合作 PM 要做的專案是把關鍵重要的流程重新設計,影響層面非常大,剛好前一個專案在開發期間有非常多 bug,上線後也發現有些情境是規格文件沒有考慮到,因此會出現非預期的結果。

這次的專案記取教訓,請 PM 列出這個專案想實現哪些重要的情境,最終將規格文件和重要情境交付給 PG 和 QA。這兩個專案的比較表如下:

前一個專案 現在的專案
重要的情境確認 共 38 個,其中有 10 個涵蓋了前一個專案
PM 情境確認時間 N/A 約 3 天
規格文件修改次數 10+ 5 次以內,甚至有的規格修改是 PG 順手改改而已
團隊討論次數 修改次數多,討論就越多 較少(體感上)
錯誤數(Bug 數) 20+ 1

從上表可以看到三個重點:

  1. 規格文件修改次數變少(因為想情境就是在確認規格正確性,後續也有證明想情境的過程中,有發現規格錯誤)
  2. 團隊對規格的共識大大地提高(討論次數變少,證明共識有提高)
  3. 開發品質大大地提高(bug 數證明)

目前單從這兩個專案的比較來看,PM 寫情境的投資報酬率非常高的,真的誠心建議要寫,因為寫情境對於團隊來說,真的是找不到其他缺點了。

小插曲之一

這個專案是前一手 PM 交接給合作 PM 的,而情境是合作 PM 寫的。

有天前一手 PM 來跟團隊說規格文件裡面的流程圖畫錯,我當下第一件事是確認情境有沒有寫錯,結果發現:情境是對的,而 PG 是照情境寫,所以 PG 寫的結果也是正確的。

這個過程發現了幾件事:

  1. 只有流程圖其實是不好驗證的,必須要用情境來驗證。
  2. PG 在寫程式的時候沒看流程,可能是因為情境相較於流程圖比較好理解。
  3. 合作 PM 在寫情境的時候,也沒有看之前的流程圖。但重點來了:合作 PM 有辦法很自然地寫出正確情境,這更代表情境更像是在「驗證」,而不單只是規格。

小插曲之二

前面有提到兩個專案的比較。其中,這兩個專案都有做 A/B 測試,在討論開放流量比例的時候,PM 對這兩個專案有極大的不同。

  • 前一個專案:可能因為在「測試過程中」,有發現很多沒考慮的問題,做了多次規格調整,因此在討論開放流量的比例時,PM 在決策過程可以看得出態度是很害怕的。
  • 現在的專案:在「上線後的內部測試時」,有發現團隊完全沒想到的情境,這會造成使用者無法操作。但 PM 對開放流量決策的態度是勇敢果斷的,甚至可以接受有問題的狀態下開放流量。

註:開放流量決策,最終決議是不開放。

這個差異的關鍵在於,PM 因為沒有確認過情境,對前一個專案掌握度低,因此對於上線對系統的影響是無法預期的;現在的專案則相反,因為情境掌握是確實的。

從第兩個小插曲更證明,決定並確認使用情境是 PM 必要的任務,因為這是掌握產品最直接的方法

避開誤區

BDD 對於開發軟體的過程非常好用。但真正在團隊協作時,要避免幾個誤區:

  1. 不是每一種需求都一定要描述情境,例如:修改已知情境的細節,這時就可以沿用相同的情境。
  2. 描述重要的情境,而不是把所有可能的情境全列出來。例如,「打開兩個視窗操作」通常在驗證防呆操作,這就不應該由 PM 來撰寫。除非它真的是一個「重要的情境」,例如:開發瀏覽器。
  3. 要描述情境,而不是程式行為,因此要用使用者角度來寫。如果出現技術字眼就需要重新檢視,有可能會踩到誤區。例如,「清除 Cookie」通常不會是使用者角度會做的事,這個情境就不應該由 PM 撰寫。
  4. 要描述情境,而不是像操作手冊一步步說明如何操作。這點可能會有點難判斷,因為情境與操作手冊都是使用者角度撰寫出來的內容,以我目前的經驗來看,一個有效的判斷方法是:將內容口頭描述給最終使用者聽,如果相較少的內容可以讓最終使用者理解,那就可以採用;反之,應該有必要的步驟未描述,才會造成最終使用者困惑。

註:最終使用者並不容易找得到,因此有幾種替代的方法,原理都是找離執行相較「遠」一點的角色:

  1. 中高階主管。執行者的直屬主管通常也離執行端很近,因此要找上一位的主管。
  2. 客服。在分工明確的組織中,最接近客戶的,就是客服。
  3. 老闆。在組織相較小的時候,就只能找老闆了。