能用的規格：打造敏捷系統的關鍵
閱讀時間約 5 分鐘
本文已取得 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 頁內。這就是我指的「敏捷規格」的意思。而我現在認為「能用的規格」是更好的術語。
9會員
28內容數
一生懸命在「改善臺灣職場與職人能力」的使命，有十餘年產品和團隊管理經驗。期待透過推廣產品管理知識與管理實務，改善對臺灣職人能力，讓企業因此而更有競爭力，因此創立臺灣產品人學會 （POA) 。
現任：
- 臺灣產品人學會 (POA) 理事長
- 生活和職涯教練
- 臺灣百大企業 Agile Coach
留言0
查看全部
你可能也想看
Google News 追蹤
「"衝刺 Sprint"是“敏捷開發 Agile Development”的“爭球法 Scrum”中的用語。
首先設定一個產品使用流程作為目標，
然後在一週至一個月期間內，將能夠做到這個使用流程的功能製作出來。
這段預設用來迅速進行開發工作的期間，就叫做衝刺期間。」
「精
敏捷開發的實踐方式有很多，其中以簡單、易懂的 Scrum 框架最廣為大家接受。 2024年7月 LeSS 網站發布了新一版的《Scrum 指南》，其中調整的內容我覺得讓這個框架更符合實務上的應用，因此就其內容並結合個人經驗與見解撰寫這篇短文，希望幫助大家快速了解這套能幫助團隊適應變化的敏捷開發方法。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
敏捷開發方法已成為現代軟體開發領域的一個關鍵趨勢。其主要目的是通過快速和增量的開發過程，提高開發效率和應對變化的能力。本文將深入探討Scrum和Kanban這兩種流行的敏捷方法的基本原理，實際應用案例，以及實施過程中可能遇到的挑戰和解決策略。
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
本文介紹了在公司專案中採用敏捷(Agile)方法，並分享了Scrum的好處、成員負責工作以及工作流程。希望可以掌握Scrum的核心：透明度、檢視和調整的核心，來推動敏捷工作。
當投標截稿時限緊迫時，該怎麼辦？
敏捷就很重要，不只拿A，更要衝刺拿A
我於2018研讀Jeff所寫SCRUM(敏捷)一書，
感到相見恨晚，恰逢其時。
把我過去準備投標或執行專案經驗，
在本書已整理出一套更有系統論述，
值得推薦你去學習並應用在工作上，
敏捷強調執行專案要有兩種能
本文討論如何運用敏捷開發的概念到人生，以打造人生產品並驗證自己的喜好。透過市場見解，敏捷開發可以幫助我們快速迭代，以不斷納入新資訊制訂下一波戰術。同時，設計思考和建立人脈也能運用敏捷迭代。此外，我們也討論了計畫如何做才完整、產品藍圖的重要性以及應對科技債的建議。
敏捷測試能有效幫助科技公司應對網路興起、軟體當道和資訊爆炸的挑戰，透過小型、跨功能團隊的協作與快速執行，並以用戶反饋進行快速迭代以測試產品假說。本文談到敏捷開發的迷思、MVP的重要性以及風險的注重，以及精實創業中如何驗證市場假說。同時提出敏捷的問題點，並結合同理心設計以滿足消費者情感上的需求。
本文探討了科技公司打造成功產品背後的三大關鍵：策略制定、敏捷開發和數據分析。透過觀察市場需求、建立MVP測試、數據統計與分析，科技公司可以更好地執行產品策略，提高產品成功的機會。另外，也介紹了產品經理的角色與重要性，以及深入分析用戶需求和產品設計的方法。
「"衝刺 Sprint"是“敏捷開發 Agile Development”的“爭球法 Scrum”中的用語。
首先設定一個產品使用流程作為目標，
然後在一週至一個月期間內，將能夠做到這個使用流程的功能製作出來。
這段預設用來迅速進行開發工作的期間，就叫做衝刺期間。」
「精
敏捷開發的實踐方式有很多，其中以簡單、易懂的 Scrum 框架最廣為大家接受。 2024年7月 LeSS 網站發布了新一版的《Scrum 指南》，其中調整的內容我覺得讓這個框架更符合實務上的應用，因此就其內容並結合個人經驗與見解撰寫這篇短文，希望幫助大家快速了解這套能幫助團隊適應變化的敏捷開發方法。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
敏捷開發方法已成為現代軟體開發領域的一個關鍵趨勢。其主要目的是通過快速和增量的開發過程，提高開發效率和應對變化的能力。本文將深入探討Scrum和Kanban這兩種流行的敏捷方法的基本原理，實際應用案例，以及實施過程中可能遇到的挑戰和解決策略。
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
本文介紹了在公司專案中採用敏捷(Agile)方法，並分享了Scrum的好處、成員負責工作以及工作流程。希望可以掌握Scrum的核心：透明度、檢視和調整的核心，來推動敏捷工作。
當投標截稿時限緊迫時，該怎麼辦？
敏捷就很重要，不只拿A，更要衝刺拿A
我於2018研讀Jeff所寫SCRUM(敏捷)一書，
感到相見恨晚，恰逢其時。
把我過去準備投標或執行專案經驗，
在本書已整理出一套更有系統論述，
值得推薦你去學習並應用在工作上，
敏捷強調執行專案要有兩種能
本文討論如何運用敏捷開發的概念到人生，以打造人生產品並驗證自己的喜好。透過市場見解，敏捷開發可以幫助我們快速迭代，以不斷納入新資訊制訂下一波戰術。同時，設計思考和建立人脈也能運用敏捷迭代。此外，我們也討論了計畫如何做才完整、產品藍圖的重要性以及應對科技債的建議。
敏捷測試能有效幫助科技公司應對網路興起、軟體當道和資訊爆炸的挑戰，透過小型、跨功能團隊的協作與快速執行，並以用戶反饋進行快速迭代以測試產品假說。本文談到敏捷開發的迷思、MVP的重要性以及風險的注重，以及精實創業中如何驗證市場假說。同時提出敏捷的問題點，並結合同理心設計以滿足消費者情感上的需求。
本文探討了科技公司打造成功產品背後的三大關鍵：策略制定、敏捷開發和數據分析。透過觀察市場需求、建立MVP測試、數據統計與分析，科技公司可以更好地執行產品策略，提高產品成功的機會。另外，也介紹了產品經理的角色與重要性，以及深入分析用戶需求和產品設計的方法。