我在兩年多前寫過類似的這樣一篇文章。
現在我的想法轉變成：我認為不應該導入，而是應該導入 MDD ( Money Driven Development ) 。
到底現在這篇文章是要闡述什麼邪魔歪道？
重看我當年的那篇文章，我想我寫那篇文章時犯下跟很多程式師，以前從來沒想過的一個問題：對 startup 定義錯誤。
在繼續講下去之前，我想我要把我近兩年來理解到的一些名詞再重新寫一次，後面的文章脈絡才能拓展開來。
Startup
Startup 是有一個點子，你認為可行，於是你想要嘗試這個商業模式，或者是將你想像的概念轉換成商業模式。
Company
而 Company 是你有一個已經稍有形狀的商業模式了，你想固定下來，以一個商業組織的形體去營運。
程式設計師加入多半的是 Company 不是 Startup
絕大多數的程式設計師都是加入 Company（因為 Company 才有錢付給工程師去每天專心優化塑形商業模式），而不是 Startup。只是很多大家以為的 Company 根本連商業模式沒有，天真的以為程式寫出來，交付正確的 Spec ，消費者就會自動買單。
Startup 需要的是不斷探索什麼行為是真的可以賣錢的。為了達到這件事，未必需要寫程式，可以是放需求表單，可以是用露天拍賣，可以是用 FB 訊息交易，可以是用 FB 養觀眾。
這些，可不可以自己寫程式達到？可以，只是成本超級高，高到難以想像的地步。同時，程式設計師通常也不希望做這樣的工作，因為他們會覺得「老闆是王八蛋，什麼都沒有想清楚就叫他們做。」
所以程式設計師通常本質上加入的是一個 company，只有已經確定要做什麼了，程式設計師拿到「確定的需求與模式」，將之塑形。
正常的業界
接下來要討論，為什麼有這樣的爭議。原因在很多的「公司」，進行軟體專案的方式是在一般人眼中是很奇怪的。
首先，他們會任命一個不懂生意也不懂技術的人，其實是一個跑腿人物，負責「跟老闆或 BD搜集需求」再「寫 Spec」再「請工程師完成」，擔任一個翻譯的工作。這個職位叫 PM。這也是大部分專案完蛋的原因。
既然是「翻譯」，那中間的那個人兩邊的語言都不會說，你覺得會發生什麼事情？當然是交付錯誤（與 BD 所要的的解決方案不同）。程式設計師為了解決「翻譯者」能力低落的問題，主張中間應該不需有翻譯。所以開始主張 BDD。
實作一個軟體時，需求者應盡量提供原始情境：
1) 誰會使用這個軟體
2) 使用者在操作時會產生什麼情境。
3) 基本邏輯
4) 什麼是必要的，什麼是應該可以有的，什麼是完全不能做的。
5) 以 Story 敘述，而不是 Spec。
讓程式設計師，可以盡量出設計貼近可以解決原始需求（程式設計師稱之為『正確』）的方案。
好了。回到 Startup 與 Company 的話題。這套手法在 Company 行得通，也必須。因為中間需要經過太多的合作人員，所以我們要透過這樣的手段，盡量減少「翻譯」Cost。
Startup 本來就不是規模化自動化的階段
但是 Startup 需要 BDD 嗎？Startup 都沒人沒錢沒時間耗一天到晚在實驗新需求了，怎麼會是需要用到 BDD 這樣的技巧。Startup 所需要的是 Money Driven Development。只做賺錢必須的功能，找到幾個有錢賺的模式，能 Scale 需 Scale，那時候大家才有興致談 BDD 。
所以 Startup 前期應不應該導入 TDD / BDD？我現在認為這兩個名詞根本不是可以放在一起討論的東西。
就跟我覺得 Startup 跑 Scrum 是奇怪的做法一樣。
（我不是反 Scrum，Scrum 的一些手段對於釐清時程，Story ，權重。不管是專案大小都很有幫助。但是不是每個團隊都可以導入或適合這套流程的。）