Specification by Example——團隊如何交付正確的軟體

這個禮拜終於斷斷續續用了空檔時間讀完了一本買了卻一直沒時間坐下來好好研究的書

這本書給我一種很奇妙的讀後感，因為書中既沒有程式碼，也不介紹任何工具，甚至實際軟體例子也很少，篇幅最多的甚至是模糊的團隊訪談。

但讀完了以後，卻讓我在軟體開發上流程上有了更大的啟發。

交付錯誤的軟體的原因

我是一名職業的軟體開發者。前前後後寫過的軟體專案也有50 個, 60 個。目前也以開發軟體為生。在我的職業生涯裡面，其實我有一個從來沒有跟人講過的祕密困擾。這個困擾，我相信許多同業們可能也有。那就是— 一個專案開發下來，「我們竟然時常比我們的客戶或PM，更瞭解它的生意邏輯與流程」

但這個問題帶來更大的困擾是：「客戶在它的Spec 裡面卻指定了完全不可行或者是成本效益極低的作法」。因為簽了合約或領了老闆的薪水，我們被迫在明知不可而為之的狀況下，進行了一個徹底失敗的專案。

技術很好，團隊也強大，產品也有市場。但還是失敗，因為– 「交付錯誤的軟體」。

軟體工程沒教的課題: 交付正確的軟體

市面上有很多書，教人如何敏捷開發，教人測試驅動開發（TDD)。它們可以帶給開發者的好處是可以利用這些技巧將工程時間大幅縮短，降低軟體內發生Bug 的頻率。

這些技巧對於進行軟體專案不是沒有作用，因為早點完工（把功能實做出來），專案早點失敗，專案可以及早軸轉到較接近成功的方向。

對於正在營運中的公司，內部專案早點失敗，及早軸轉到較接近成功的方向。往往是可接受的。因為總體目標是儘快交付到貼近正確方向的軟體。

但對於目標是交付一個軟體的專案，「交付錯誤的軟體」卻往往是糾紛的起源。但卻也是一個千古難解的課題。對於業主來說，他付錢是希望得到一個「正確的軟體」。但於對於被委託的開發者也往往有苦難言，因為他們得到的指示是「按照業主精確的功能敘述去實作軟體」，「正確與否」不是他們的最終責任。而是否「正確」通常往往也得等到上線之後，客戶根據使用者實測反應才能得知（雖然開發者往往是開發階段就往往能猜測出是否失敗的那一群人）。但這從來也不在合約的責任之內。

而這本書也就是在探討這個課題：怎麼樣的軟體流程，才能交付正確的軟體。

大家沒想到的答案: BDD

這本書繞了很多遠路去講解什麼是Specification by example，但這也是作者的用意：刻意不使用專業定義字眼如「敏捷」、「測試驅動開發」去輔助解釋，避免整個梳理的流程被大家腦海裡面的術語印象所綁架。

但總體來說，這個結論毫無疑問就是Behavior Driven Development (BDD)。不過這個BDD 卻跟我當初學到的BDD ( from Cucumber ) 印象很不一樣。這也是為什麼這次會花上幾個小時謄下這篇心得。

裡面有幾段quote 我很喜歡，實際擊中困擾的核心：摘錄如下：

「實現範圍（Implementation scope）含有對業務問題的解決方案或達成業務目標的手段。很多團隊在開始實現軟體之前（在此之前發生的一切往往被軟體開發團隊所忽略），期望客戶、產品負責人或商業使用者來確定工作的範圍。在商業使用者明確說明他們的需求後，軟建交付團隊就依此時現。這樣本應該會讓客戶滿意。但事實上，這正是構建產品開始出現問題的時候。

如果軟體交付團隊依賴客戶給出使用者故事、用例清單或其他相關資訊，那麼他們其實是在讓客戶設計解決方案。但是商業使用者不是軟體設計師。如果我們讓客戶去界定範圍，那麼專案就無法從交付團隊已有的知識受益。這樣開發出來的軟體是客戶所要求的，卻不是他們真正想要的。

成功的團隊不會盲目的接受軟體需求，將其作為未知問題的解決方案，相反，他們會從目標中獲取範圍。他們以客戶的業務目標為起始，然後通過協作界定可以實現目標的範圍。團隊與商業使用者一起工作確定解決方案。商業使用者專注於所需功能希望達到的目的，以及他們期望由此帶來的價值，這樣有助於所有人瞭解所需的功能。然後團隊提議一個解決方案，這樣比商業使用者自己想出來的方案更實惠、更快，並且更容易交付或維護。」

「與我一起共事過的商業使用者和客戶，大多喜歡把需求描述成解決方案；他們很少會去討論想要達到的目標，或者亟待解決的問題具有什麼特殊性質。我見過太多的團隊有一種危險的誤解，他們認為客戶總是正確的，客戶要求的東西總是一成不變的。這導致很多團隊盲目的接受客戶建議的解決方案，然後竭盡全力去實現。」

「在構建正確軟體產品的過程中，確定範圍扮演著重要的角色。沒有正確的範圍，其餘的工作只是在作無用功。」

「人們告訴你他們自己認為需要什麼，通過問他們『為什麼』，你可以找到背後的目標。許多組織不能明確地指出他們的商業目標。然而，一旦你獲得了目標，就應該再反過來從已確定的目標上獲取範圍，可能你會丟棄掉原先假定出來的範圍」

一個實際的例子：對VIP 免費送貨的需求

Specification by example 強調的是對於需求，我們必須設計出一個可以被實現的方案，這個方案可以被單獨測試驗證。並且從這個方案與程式碼中演化出LiveDocument。

原文連結：http://blog.xdite.net/posts/2012/10/01/specification-by-example/