能用的規格：打造敏捷系統的關鍵

本文已取得 Scrum Inc. 官方授權翻譯，原文為：Enabling Specifications: The Key to Building Agile Systems https://www.scruminc.com/enabling-specifications-key-to-building/ (全文視情況刪減或調整，以幫助閱讀；斜體字是我新增的部分)

之前，我討論了「敏捷需求」的概念，這個概念被埋入 Nokia 測試（Nokia Test）中。敏捷需求沒有被普遍認同的定義，所以我現在用一個更好說明的標準概念來談。對於許多應用程式來講，特別是網路應用程式，一個故事（Story）只需要在卡片或便利貼上做筆記和驗收測試即可。對於某些應用程式，例如給醫師使用的手機應用程式，除非有完整設計之有經過被仔細挑選的醫師測試群的原型（prototype），使用者就會拒絕在醫院中安裝該應用程式。因此，一個完整設計之能用的規格，配合一個完整能使用的原型．需要在被刪調一行程式前被同意。Apple 經常使用這個「為何你不能像 Apple 一樣創新（Why You Can’t Innovate Like Apple）」。PatientKeeper 在 2003 到 2008 年間，使用了這項策略，這也就是為什麼他們成為我見過的最快的公司範圍相關的 Scrum 團隊的原因之一。我在 Agile 2005 上稱他們為「Scrum 的未來（The Future of Scrum）」。有些人說 PatientKeeper 看起來更像看板（Kanban）而非 Scrum，因此他們也是有史以來最快的看板團隊。從 1993 年以來，我也在 Scrum 內做看板，因為 Scrum 是 Takeuchi 和 Nonaka 對 Lean 團隊的看法。然而，我們嘗試了最小化看板，就像 Taiichi Ono 和 Toyota 今天做的那樣。

在 2007 年，我拜訪了 PatientKeepers 專利律師，因為我們的 CEO 想要取得一項專利，把這項專利用在一種分析醫師費用支付的報告策略的發現上，這項策略將在使用的第一個月內．讓醫院收入提高了 30%。我要求 Product Owner 帶來她讓律師審查的文件。這裡面有一個三頁的敏捷規格。這是 PatientKeeper 的 Product Owner 用來描述功能整體概念的文件。使用者故事（User Story）是根據該文件制定的。

我們的目標是和律師合作，以了解專利申請需要多少文件。律師們指出，專利申請是一種「能用的規格」。這是一個用來描述允許該領域的一般知識淵博的人，在沒有討論的狀況下創造這個功能的文件的法律術語。

律師確定我們的三頁敏捷規格不是能用的規格。而要做一份能夠獲得美國專利局批准的文件的話，我們需要五頁紙。

事實證明，能用的規格最大幅度地提高執行使用者故事的流程效率所需要的部分。運用使用者故事的團隊之平均流程效率約為 20%。這是指一個需要理想一天工作時間的故事，需要五個日曆天才能交付。 Systematic Software Engineering 是一家 CMMI 成熟程度為 5 的公司，從它的大規模數據（has extensive data）可看到，將故事流程效率提高到 50% 以上的團隊，會使每個團隊的 velocity 有系統地翻倍。 （PatientKeeper 的運行速度是我們在印度採用瀑布式的合作夥伴的 10 倍。）

「能用的規格」的定義是美國專利法的一部分，已被法院廣泛裁定，因此，它已不僅僅是一個被普遍認同的概念，你也能把需求帶到法庭，讓法官會告訴你是否符合能用的規格。

通常，需求不是能用的規格。在一家大型跨國公司的最近的一個專案中，我們發現數百頁的需求，沒有能用的規格。平均 60% 的文件內容，對開發人員而言沒有用。它導致評估增加了一倍。更糟糕的是，開發人員實現軟體所需的 10% 功能，並不在需求中。

PatientKeeper 使用的能用的規格，提供了一個功能組合的全面描述，該功能組合被制定為有螢幕截圖、商業邏輯和數據結構的輕量使用者故事。能用的規格被用於生成使用者故事，然後形成 Product Backlog。整體功能描述由 Product Owner 團隊定期更新，並且成為對系統狀態的參考，這項參考允許開發人員查看 Product Backlog 中的使用者故事從哪裡來。

使用者故事需要成為敏捷團隊以最佳運作的迷你能用的規格。如果不是，則需要在 Sprint 期間與 Product Owner 繼續討論，來瞭解清楚故事的意涵。這樣做會降低故事流程的效率並且減少 velocity。

使用者故事包含模板、筆記、驗收測試，以及暗示與 Product Owner 的對話。因此，假如對話在 Sprint 開始之前是清楚的，那麼對話也許是迷你能用的規格的一部分。一個簡單的應用程式，它可以寫在一張卡片上，而且即使對於像 PatientKeeper 平台這樣複雜的關鍵任務和危及生命的應用程式，它（能用的規格）也不會超過 3 到 5 頁。

如同律師所指出的，主要功能的能用的規格不用超過 5 頁。因此，對於一個中等規模的功能的所有需要的文件（包含轉錄所有的對話），應該應該在 3 到 5 頁內。這就是我指的「敏捷規格」的意思。而我現在認為「能用的規格」是更好的術語。