成功的團隊如何交付正確的軟體——寫在《Specification by Example中文版》即將上市之際

前 言

你手裡正拿著或正在螢幕上翻看的這本書，是基於一系列研究的成果，我們調查了世界各地 的多個團隊如何在很短的週期內說明需求、開發軟體，並交付正確的、無缺陷的產品。本書呈現 的是集體智慧，從公共網站到內部支援系統，涉及大大小小約50個專案。這些專案包含了各種各 樣的團隊，有在一個辦公室裡辦公的小團隊，也有跨越大洲的集團公司，他們使用了眾多過程， 包括極限程式設計（XP）、Scrum、看板（Kanban）以及一些類似的方法（通常附帶有敏捷或精益的 字眼）。這些專案有個共同點——其具體實踐使得需求說明和測試能夠良好配合，從而使專案獲 益良多。

例項化需求說明

如何處理需求說明與測試，不同的團隊使用不同的名稱，但這些名稱都有一套通用的核心原 則與思想，而我認為它們在本質上是一致的。很多團隊使用以下這些名稱來命名這類實踐：

 敏捷驗收測試

 驗收測試驅動開發

 例項驅動開發

 故事測試

 行為驅動開發

 例項化需求說明

相同的做法卻有如此之多的名字，這事實上也反映了當前在這一領域內，有著大量的創新。 同時它還反映了一個事實，本書描述的這些做法，影響了團隊的需求描述、開發和測試等方面。 為保持一致，我必須選擇一個名字。我採用例項化需求說明這個名稱，在本書其餘部分都會使用 這個名字。關於為何這樣選擇，我稍後會在“關於術語”的小節裡詳細解釋。

現實世界

我通過案例研究和採訪來呈現這個話題。之所以選擇這種方式，是為了讓讀者能看到目前真 的有團隊正在這麼做，並且從中獲益良多。例項化需求不是一門神祕藝術，雖然有些主流媒體會 使人這麼覺得。

書中的一切幾乎都是來自於現實世界、真實的團隊以及切實的經驗。有一小部分實踐是作為 建議提出的，並沒有真實案例研究的支援。我認為這些思想對將來會很重要，也正是因為如此， 我才明確地提出它們。

我很確定，我所主導的研究以及我得出的結論，雖然促成了本書的編寫，但由於這並不是一 項嚴肅的科學研究，將會被那些號稱敏捷開發不可用、業界應該回到“真正的軟體工程”的懷 疑論者所排斥。那也沒關係。相比一項嚴肅的科學研究所需的資源，編寫本書時我接觸到的資源 是十分有限的。但即使我擁有那些資源，我也不是一個科學家，而且我也不用偽裝我自己。我是 一名實踐者。

誰應該閱讀這本書？

如果你像我一樣，是一名實踐者，並且靠軟體謀生，那麼這本書可以提供很多幫助。有些團 隊已經嘗試去實施敏捷過程，並且碰到了低質量、返工以及未達客戶預期等問題，本書主要就是 寫給這些團隊的。（沒錯，這些都是問題。簡單地迭代只是權宜之計，並非解決方案。）例項化需 求說明、敏捷驗收測試、行為驅動開發，以及其他不同叫法所指的這個實踐，都能解決這些問題。 無論你是測試人員、開發人員、業務分析師，還是產品負責人，這本書都可以幫助你開始實施這 些實踐，並學習如何用它們在團隊中做出更多貢獻。

幾年前，我在大會上碰到的大多數人都沒聽說過這些思想。而現在，我碰到的大部分人都或 多或少知道這些實踐，但是很多人都未能妥善落實。在實施敏捷開發的過程中，團隊碰到的問題 通常都很少有文字記載，所以每一個受挫的團隊都認為，自己遇到的問題比較特殊，而這些理念 無法在他們的“現實世界”裡發揮作用。只需聽他們述說短短五分鐘，我就能猜中三四個他們碰 到的最大問題，這讓他們覺得驚訝。而當他們得知其他團隊也有同樣的問題時，他們更是完全驚 呆了。

如果你也在這樣的團隊當中，那麼本書為你做的第一件事情，將是告訴你“你並不孤單”。 本書中我所採訪的那些團隊並不完美——他們也曾遇到數不清的問題。但他們在碰壁之後，並沒 有放棄，而是決定圍繞這些問題思考，並逐一分析。瞭解這一點通常能鼓舞人們一種眼光去看待 自己的問題。我希望你在讀罷這本書後也有同樣的感受。

如果你正在實施例項化需求說明，本書將就如何解決你當前的問題提供非常有用的建議，同 時也能讓你瞭解未來會發生什麼事情。我希望你可以從別人的錯誤中汲取經驗，並且完全避免發 生同樣的問題。

本書也寫給有經驗的實踐者，以及那些在實施例項化需求說明的過程中相對成功的人們。在 採訪開始之初，我本以為這些事情我都已胸有成竹，只是在求證而已。結果我發現，人們在實施 過程中居然有如此之多的想法，這是我始料未及的。我從這些案例中學到了很多，希望你也如此。 這裡所描述的實踐和想法，應該會激發你的靈感，促使你對自己的問題嘗試變通方案，或者讓你 在見過類似的故事之後，意識到可以如何改善團隊的過程。

書裡有什麼內容

在第一部分，我會介紹例項化需求說明。我不會說服你為什麼應該遵循本書描述的原則，而 是向你展示——用例項化需求說明的方式——團隊從這個過程中獲益的例子。如果你在考慮購買 這本書，請瀏覽一下第1章，看看有哪些好處可以帶到你的專案中。第2章介紹了關鍵的過程模式 和例項化需求說明的關鍵工件。在第3章，我會更詳細地解釋活文件的概念。第4章我會展示一些 改變過程和團隊文化的最常見的切入點，也會就開始過程實施時需要注意的地方給出一些建議。

本書寫作的一個目的是為團隊在實施例項化需求說明時使用的這些模式、想法和工件建立一 致的語言。整個實踐在社群裡有許多名稱，裡面各種要素的名稱更是多出一倍。不同的人分別將 同一個東西叫作功能文件、故事測試、BDD文件、驗收測試等。正因為如此，在第2章中我會對 所有的關鍵要素介紹一些我感覺不錯的名字。即使你非常有經驗了，我還是建議閱讀這一章，以 確保我們對本書中的關鍵名字、用詞和模式的理解是一樣的。

在第二部分，我會展示案例中的團隊用來實現例項化需求說明原則的關鍵性實踐。不同環境 中的團隊會做非常不同的事，有時甚至為了達到相同效果採取的措施是相反的或衝突的。除了 實踐外，我還記錄了團隊在什麼樣的環境裡貫徹了基本原則。第二部分差不多按照過程區域分 成7章。

在軟體領域沒有最佳實踐，但是確實有一些好的想法我們可以嘗試在不同的環境中去使用。 在第二部分中，有些小節標題旁邊會有拇指向上或向下的圖示，代表的是調查中一些團隊覺得有 用的做法，或者是他們經常遇到的問題。請根據建議做適當的嘗試或迴避，但不要完全照搬套用。 箭頭圖示出現的地方代表的是各種做法的精髓。

軟體開發不是靜態的——團隊和環境都在改變，過程也必須隨著改變。在第三部分中，案例 分析展示了一些團隊的實施歷程。我記錄了他們的過程、約束條件和環境，並分析了這些過程 是如何演化的。這些故事對你邁開第一步或讓你更進一步，並發現新的想法與做事方式都能提 供幫助。

本書的最後一章，我總結了我從促成本書的案例分析中學到的關鍵要素。

進階

在傳統的學習模型守破離（Shu-ha-ri）中，本書處於破的層次。破是說要打破陳舊的規則， 並證明成功的模型有很多。在我的Bridging the Communication Gap一書中，我展示了我的模型及 經驗。本書中，我儘量不帶進以前的背景。只有當我覺得有重要觀點需要證明，並且本書中提到 的其他任何團隊都沒有類似情況的時候，我才會展示那些我自己參與過的專案。從這個意義上講， 本書在Bridging the Communication Gap的基礎上更進了一步。

我會在第2章簡單介紹一些基本的原則。即使你以前從未聽說過這些想法，第2章的簡介也應 該可以給你足夠的資訊去理解本書的其餘部分，但我不會過多地深入基礎的內容。有關例項化需 求說明的基礎內容在Bridging the Communication Gap一書中有詳細的描述，我不想在本書中重複。

如果你想更詳盡地重溫那些基礎內容，請訪問http://specificationbyexample.com，登記你購買 了本書，就可免費獲得Bridging the Communication Gap的PDF版本。

我想今後我不會就這一主題續寫“離”這個層次的書籍——因為該層次是超越書籍的。另一 方面，我相信本書可以幫助你到達“離”這一層次。一旦你開始覺得選擇什麼工具已經無關緊要， 那麼你就已經達到了這個層次。

本書沒有原始碼，也不介紹任何工具

本書沒有原始碼，也沒有特定工具的使用說明。我覺得必須事先說明這一點，因為在出版過 程中，我就曾多次向別人解釋這一點（典型的問題有“什麼意思？一本沒有原始碼的軟體開發書？ 這怎麼可能！”）。

例項化需求說明的原則和實踐主要影響軟體交付團隊中的人員溝通，以及他們如何同使用者 和專案干係人進行協作。我確信許多工具供應商會試圖賣給你一套技術方案。如果有工具可以立 即消除遇到的問題，許多經理會樂於為此買單。不幸的是，他們遇到的主要是人的問題，而不是 技術問題。

比爾·蓋茨說過：“在企業中應用任何一項技術時，首要的法則是，在有效率的系統中匯入 自動化，將使效率倍增。第二條法則是，在缺乏效率的系統中匯入自動化，會使效率更低下。” 很多團隊在使用例項化需求說明的時候失敗了，他們使用自動化工具反而導致他們的過程更加低 效。我不想把注意力放在特定的工具上，相反，我想側重分析團隊努力實現這些想法的真實原因。

一旦你們能正確地溝通和協作，你們就可以選擇適合的工具去使用。在閱讀本書後，如果你想知 道更多支援例項化需求說明的工具，請訪問http://specificationbyexample.com並檢視資源部分。

關於術語

如果這是你首次聽說例項化需求說明、驗收測試驅動開發、敏捷驗收測試、行為驅動開發， 或者人們為這類做法所起的任何其他名字，你應該慶幸自己沒有被這些誤導性名字所困擾。你應 該放輕鬆些，而且你可以跳過這個部分的介紹。如果你已經接觸過那些做法，我在本書中使用的 名字可能會讓你感到驚訝。請接著讀下去，這樣你就能理解為什麼我使用這些名字，並且你也應 該開始使用他們。

在我編寫本書的時候，我也遇到了實踐者們在編寫他們的自動化需求說明時經常遇到的問 題。術語應該要一致，這樣才能易於理解，當把內容編寫成文時很有必要明白這一點。本書是一 系列訪問的產物，很多我交談過的人使用不同的名字來指稱同一件事情，這樣的話，要想保持所 講故事的一致就是相當困難的。

我意識到，例項化需求說明的實踐者，包括我自己，通常會因為使用技術術語，導致我們自 己以及其他嘗試實施這些實踐的人都很迷惑，這讓我們感到內疚。因此我決定，編寫本書的其中 一個目標，就是要改變社群中使用的術語。讓業務人員更多地參與進來，是這些實踐的一個主要 目標，為此我們必須使用適當的名字去描述那些正確的做法，不要再讓人們感到困惑。

當我們編寫我們的需求說明時，這個教訓是顯而易見的。我們都知道應該要保持術語的一致 性，避免使用具有誤導性的術語。但當我們談論過程的時候，我們沒有那麼做。例如，當我們在 例項化需求說明的環境中說持續整合的時候，我們並不是說要執行整合測試。因此，為什麼要使 用這個術語，然後不得不給其他人解釋驗收測試與整合測試的不同？在我開始使用需求說明工作 坊這個名字來代表有關驗收測試的集體會議前，很難說服業務人員去參加。一個簡單的名字變更 就解決了這個問題。通過使用更好的名字，我們可以避免許多毫無意義的討論，馬上就讓大家走 上正確的道路。

為什麼使用“例項化需求說明”這個名字

首先我想解釋一下，為什麼我選擇例項化需求說明作為這些實踐的總稱，而沒有使用敏捷驗 收測試、行為驅動開發或者驗收測試驅動開發。

在2010年的倫敦領域驅動開發交流大會上，Eric Evans跟別人爭論說敏捷作為一個術語，已 經失去了一切意義，因為現在什麼都可以稱為敏捷。很不幸的是，他是正確的。儘管有大量的著 作講如何正確地實施極限程式設計、Scrum以及其他不那麼流行的敏捷過程，但我見過太多太多的團 隊，試圖去實現冠以敏捷一詞的過程，但那些過程又顯而易見地違背了敏捷的精神。

為了避免這種關於敏捷是否可行（以及什麼是敏捷）的無意義爭論，在本書中，我儘量避免 使用敏捷這一術語。只有當我提到的團隊基於敏捷宣言概括的原則定義了良好的過程，並開始實 施時，我才會使用它。由於不會經常提到敏捷這一術語，敏捷驗收測試這個名稱也就無從談起了。

這裡描述的實踐沒有形成一個成熟的軟體開發方法論。它們可以補充其他方法論——無論是 基於迭代還是基於工作流的——使需求說明和測試更加嚴謹，增強不同專案干係人和軟體開發團 隊成員之間的溝通、減少不必要的返工，並讓改變更加容易。因此我不想使用任何“驅動開發” 之類的名字，尤其不會使用行為驅動開發（BDD）的字眼。不要認為這說明我反對BDD。恰恰 相反，我喜歡BDD，而且我認為本書實際上主要在講BDD的核心內容。但BDD同樣有名字歧義 的問題。

關於BDD到底代表了什麼，這點總是在變化之中。關於什麼是BDD，什麼不是BDD，Dan North 是最具話語權的。在2009年的敏捷需求說明、BDD以及測試交流大會上，他說BDD是一種方法 論。（事實上，他將其稱為“第二代的、由外而內的、基於拉動的、多專案干係人、多尺度的、 高度自動化的敏捷方法。”）為了避免在North所說的BDD和我理解中的BDD之間產生任何混淆和 歧義，我不想使用這個名字。本書講的是一組寶貴的實踐，在很多方法論中你都可以使用，包括 BDD（如果你能接受BDD是一種方法論的說法）。

我也想盡量避免使用測試這個字眼。很不幸地，很多經理和業務人員認為測試是一種技術輔 助活動，不是他們想參與的事情。畢竟，他們有專門的測試人員去處理這件事情。例項化需求說 明要求專案干係人以及交付團隊的成員（包括測試人員、開發人員、業務分析人員）積極地參與 進去。只要我們在標題中不放入測試這樣的詞彙，那麼故事測試、敏捷驗收測試以及其他類似的 名字自然就不會出現。

這讓例項化需求說明成為了最有意義的名字，因它的負面影響最小。

過程模式

例項化需求說明由一些過程模式（Process Pattern）組成，後者是更廣義的軟體開發生命週期 的組成要素。本書中我用的名字是在英國敏捷測試使用者組會議、敏捷聯盟功能測試工具郵件組以 及工作坊中經過一系列討論得到的。其中有些名字已經用了一段時間，而另一些大多數讀者還比 較陌生。

社群裡流行用一個實踐或工具的名字來描述過程的一部分。功能注入（Feature Injection）就 是一個很好的例子——用它來描述從商業目標獲取專案中範圍這一過程，就很受歡迎。但是功能 注入只是其中一種技術，還有其它方法可以達到同樣的目的。為了討論不同的團隊在不同的環境 中做什麼，我們需要更巨集觀的概念來囊括所有這些實踐。一個好的名字能很好地說明預期的結果， 並且清晰地指出這些實踐的關鍵性區分元素。以功能注入與類似實踐為例，其結果就是專案或里程碑的一個範疇。與其它定義範圍的方法相比，關鍵區別在於，我們專注的是商業目標。因此我提出從目標中獲取範圍（deriving scope form goals）這一概念。

在例項化需求說明過程中，團隊碰到的最大的一個問題是：誰應該在什麼時候寫些什麼東西。

所以我們需要一個好名字來明確地說明大家都應參與（需要在團隊開始編碼或測試前做），因為 我們要使用驗收測試作為開發的目標。測試先行（Test First）是個不錯的技術名詞，然而商業用 戶並不能理解，更何況它沒有包含合作的意思。我建議我們關注通過協作制定需求說明（specifying collaboratively），而非測試優先或寫驗收測試。

聽起來很普通，只是把每個數字上的可能性考慮進自動化功能測試裡。如果自動化了，我們 為什麼不這麼做？但是如此複雜的測試作為溝通工具是無法使用的，在例項化需求說明裡，我們 是要用測試來溝通。因此不是編寫功能測試，而是關注舉例說明（illustrating using examples）， 並且期望它能輸出關鍵例項（key examples）這些例項表明我們只需要恰當地描述所需的環境就 可以了。

關鍵例項是原料，但是如果僅僅關注驗收測試，為什麼不乾脆就用50列100行的複雜表格來 作為例項，並且不帶任何說明？反正是機器來測試。用了例項化需求說明，測試既是給機器看的， 也是給人看的。我們需要說清楚的是，使用例項說明後，還有一個步驟，就是抽取屬性和例項的 最小集合來說明業務規則，並加上標題和描述等。我建議把這個步驟稱為提煉需求說明（refining the specification）。

提煉的結果既是需求說明，同時也是開發的目標、檢查驗收的客觀方法以及之後的功能迴歸 測試。我不想叫它驗收測試的原因是，它很難說明為什麼文件要用領域語言來寫、可讀性要高， 還要容易理解。我認為我們應該將提煉的結果稱為帶例項的需求說明（specification with examples）直接指出一個事實，就是需求說明需要基於例項，但是包含的比原始資料要多。將這個工件稱作 需求說明可以明顯地指出大家都需要關注它，而且它需要易於理解。除此之外，關於是否用這些 檢查來自動驗收軟體或自動拒絕不滿足需要的程式碼，還有另外一種截然不同的觀點。

我不想再花時間和那些買了QTP的人爭論，告訴他們QTP對驗收測試完全沒有用。只要我們 談論測試自動化，總有人推銷測試人員已經用來做自動化的可怕玩意兒。敏捷驗收測試和BDD 工具與QTP之類的工具有很大的差別，它們處理完全不同的問題。不應將需求說明解釋成一種自 動化的技術。我們把在不歪曲任何資訊的情況下將驗證自動化稱作自動化驗證而不改變需求說明 （automating validation without changing speciications），而非稱作驗證自動化。不改變原有 需求說明的自動化驗證可以幫助我們避免可怕的指令碼，並能幫助我們在測試需求說明中直接使用技術類 庫。可執行的需求說明應該與在白板上看到的一樣，而不應該轉譯成Seleninum命令。

在將需求說明驗證自動化後，我們可以用來驗證系統。事實上，我們得到了可執行的需求說 明（executable specification）。

我們要頻繁地檢查所有的需求說明，確保系統還在按所期望的執行，同樣重要的是，確保需 求說明還能描述系統的行為。如果我們將這稱作迴歸測試，那麼很難向測試人員解釋為什麼他們 不應該在之前既小又好，而且準確的需求說明中再加500萬個測試用例。如果再提到持續整合， 我們將很難解釋為什麼不總是端到端地執行這些測試，並檢查整個系統。對於一些遺留系統，我 們需要針對一個部署好的正在執行中的環境來執行驗收測試。技術上的整合測試應在部署前運 行。所以我們不談迴歸測試或持續整合，我們談頻繁驗證（validating frequently）。

例項化需求說明具有長期回報，前提是擁有一個對系統自身功能的引用，該引用具有與程式碼 一樣的價值，但是更易讀懂。長期來說，這使得開發有效率得多，能促進與商業使用者的合作，促 成軟體設計和商業模型的一致，並且使大家工作更簡單。但是要做到這點，該引用必須有意義， 必須有人維護，而且還必須內部保持一致，並與程式碼保持一致。我們不應該有大量的測試還在用 數年前使用的術語。你很難讓忙碌的團隊回過頭去更新測試，但是在重大改變之後回頭去更新文 檔，這是大家所願意看到的。所以我們不要關注那些含有數百個測試的資料夾，讓我們把注意力 放到演化活文件系統（evolving a living documentation system）上。這樣就更容易解釋，為什麼很 多事情必須不言而喻，為什麼商業使用者也需要使用這些，為什麼需要良好地組織以方便查詢。

所以情況就是這樣：我選擇了這些名字，不是因為它們以前很流行，而是因為它們有意義。

這些過程模式的名字必須建立一種思考模型，該模型可以明確地指出那些重要的事，並且減少困 惑。我希望你能明白這點，並接受這個新的術語。

本書作者有5年的相關工作經驗，已幫助眾多團隊實現“specification-by-example”這一實踐，且為多個支援通過示例實現規範的開源專案做出了貢獻。常在領先的軟體開發和測試會議上發表演講，且管理著UK Agile Testing User Group（UK敏捷測試使用者組）。