行為驅動開發（BDD）認為軟件開發是現如今企業運營的根本，有助于改善企業利益相關者和軟件開發者之間的溝通。Kevin Smith在其一篇最近的博文中介紹了他使用BDD的工作經驗。
在進行了多年的敏捷項目后，Dootrix公司的技術總監和聯合創始人Smith注意到了敏捷開發的一些共同缺點：
由于用戶故事越來越多關注于用戶以及他的軟件需求，這樣很容易讓開發者忘記商業需求。 用戶故事生命周期較短，因此很容易忘記一個應用程序的整體規范。 由于用戶故事生命周期較短，基于用戶故事的驗收標準往往質量較低。 缺乏可以發現并解決業務問題的敏捷工具。 測試驅動開發（TDD）是目前常用的一種手段，但是往往這些測試僅僅驗證了細節，而沒有驗證功能是否正確的實現了。根據Smith過往的經驗，BDD可以幫助解決這些問題，尤其是在引入實例化需求（Specification by example）以及影響地圖（Impact mapping）等概念的時候。
Smith曾經實現了一個簡單的改變，他將用戶故事轉換為一個更加偏向于BDD風格的形式，他認為通過這樣可以讓人們將關注點轉移到商務價值上，并更多討論它：
為了<實現利益>，作為一個<角色>，我需要<功能>。
BDD強調要使用具體的用例來減少歧義。這些用例有助于建立共同的認識，并找到丟失的功能。當編寫驗收標準時，可以用正式的語言Gherkin來寫這些用例，并可以基于這些用例進行自動化測試。
構建軟件的一個常見的挑戰是如何創建正確合適的文檔。由于BDD關注于用用例來解釋行為，因此可以用于自動化生成文檔。這個文檔與實際實現的功能同步，我們通常稱其為活文檔。
雖然Smith認為BDD給我們帶來了很多方便，但它還是存在一些潛在的缺點值得我們的注意：
BDD沒有涉及到用戶界面，所以我們還需要使用原型和其他的工具來保證界面完好設計。 有很多現成的工具可以測試編寫的用例，但缺少可以管理運行哪個測試、何時運行的工具。 它很難開發一個很好的自動化測試套件，在短期內它較為昂貴。Smith最后指出BDD還是一個新興的想法，因此缺乏如同敏捷方法一般的生態環境。不過他相信這是幫助人們在搭建軟件的時候更好溝通的一個好方法。為了再一次激起人們對BDD的關注，他引用了BDD的作者Dan North的一句話：
BDD是促進合作并通過實例探索的一大選擇。
查看英文原文：Experiences with Behaviour-Driven Development
京公網安備 11010502049343號