摘要：你覺得需求條目化怎么樣？
曾經，大概在2010年之后的幾年里，敏捷在國內變得越來越廣為人知，作為重要的敏捷需求實踐，用戶故事幾乎成為了標配。但實踐者們對於它，卻一直都有着非常多的疑問和困惑，尤其是用戶故事和用例的爭議，貫穿了國內幾乎整個發展歷程。雖然在我看來它們的關系很好理解、很簡單，Craig Larman在他的工作坊里面講得蠻清楚的，也是我個人比較認可的觀點。
簡單來說，就是如下這個用戶故事實踐，確實好用，實踐者往往也很容易就能喜歡上它，雖然實踐起來往往都偏離得比較厲害，首當其沖的就是極少有人會真的嚴格遵循它的三段式去表述。
其次，當然就是在較大規模組織里面實施敏捷的實踐者都會產生的困惑，故事數量多了，該怎么管理？已經完成的故事，怎么處理？跨團隊的故事應該怎么處理？
實踐者們解決這些問題的方法，主要是用戶故事地圖（User Story Mapping）和影響地圖（Impact Mapping），關於這兩個實踐，大家可以參考此創始者Jeff Patton、Gojko Adzic各自所著的同名書籍。用戶故事地圖解決了大故事到小故事的關系問題，以及故事發布排期的問題；影響地圖則側重於思考解決從業務目標到用戶行為到系統功能的關聯問題。
可惜的是，即便把這兩個實踐都用上，也還存在着沒有完全解決的問題。
在上家企業工作期間，給一個銀行研發中心做過挺長時間的敏捷轉型服務，剛進到項目不久，對方就問了我一個問題：“你覺得需求條目化怎么樣？”。那是我第一次聽說“需求條目化”這個詞，但我覺得這名字蠻有意思，挺好的。當時也覺得能延續客戶本身的實踐和術語概念有助於實踐落地，於是我就把用戶故事、故事地圖、影響地圖、UML部分圖表、ATDD等大量敏捷實踐揉在一起，以及價值主張、設計思維等實踐，作為“需求條目化”這個名字背后的操作內涵。從我的角度來看，這些實踐的揉合就是讓需求條目化從定義變成可操作性定義（出自戴明，Operational Definition）的關鍵。
為什么突然提到需求條目化？
因為它是我心目中讓用戶故事變得更有效、更落地的一種套路。
首先，需求條目化的需求結構如下：
我們可以認為它大致上可以對應到Epic、Feature、Story，但實質上，這三個級別是性質上的不同，而不是EFS那樣主要是需求規模大小的不同。需求概念位於問題域，澄清要解決的業務問題，比如為什么要啟動這個項目？為什么要開發這個新版本？條目則位於方案域，雖然對於研發部門/團隊來說，很容易把條目等同於系統功能，但實際上，是完全有可能而且是絕對存在不實現任何功能也可以解決問題的方案的。子條目位於實現域，主要是用來解決研發團隊之間分工協作的問題，比如不同模塊之間或前后台之間，對於較小型的團隊，沒有復雜的分工，那很有可能就不需要使用子條目。再往下，團隊內部可以再拆分為具體的工作任務，解決內部團隊成員之間的分工協作問題。
需求概念、條目、子條目，這三個級別，每個級別都是用戶故事，都要以用戶故事的質量要求對待，也即3C原則和INVEST原則。它們都要制定驗收標准，然后細化出測試用例、實現測試自動化（我個人堅持100%）、ATDD。關於驗收標准和測試用例的關系，可以看看這篇文章里我跟呂毅老師的不同觀點：《實例、接收標准和接收測試》。
具體來說這三個級別可以是什么呢？
- 概念：市場熱點、用戶痛點、競品參考等
- 條目：端到端需求，具有終端用戶使用價值的功能特性
- 子條目：比較小的端到端需求，或是因應組織現狀而將端到端需求拆分到不同架構層級、模塊或不同部門團隊的技術型需求，例如某個端到端特性的前端呈現和后台處理功能
值得注意的是，這三個級別需求的澄清，並不追求要全部拆分清楚、羅列完畢才開始下一步具體的研發工作，而是采取邊澄清邊研發的滾動刷新模式。當然這是有前提的，要產生好的實效，這個前提必須做到，就是要有好的可以錄入並持續刷新維護三級需求結構的工具，簡單來講就是敏捷需求工具。
澄清需求后，就是對應地納入各級計划，此處也假設采取的是敏捷規划模式。嚴格來說是以敏捷規划模式為前提，傳統模式通常都要求早期澄清所有或絕大部分需求才能啟動研發，敏捷規划模式則強調逐漸細化、增量規划，這些主張跟需求條目化如出一轍。
按照時間順序來講，大致過程如下。
確定項目/版本的核心目標並進行優先級排序，剔除低優先級、雞肋型目標，我個人認為不管項目大小、人員多少，都應該聚焦到1-3個核心目標。人多、項目大，那需求概念就大；人少、項目小，那需求概念就大。但不管怎樣，再順着三級結構拆解，至少到子條目都能夠成為滿足團隊迭代排期的顆粒度。
然后呢，就是畫場景圖，要從用戶角度畫。用戶角度、用戶角度、用戶角度！用戶≠客戶、用戶≠客戶、用戶≠客戶！用戶是廠商所提供服務、產品或功能的實際使用者。場景圖也不難，就是理清楚用戶和廠商之間的交互過程和觸點，比如，應該是用戶和華為之間的交互，而不是用戶和華為某個網站或某個系統之間的交互。這些交互過程和觸點的組合，就是條目，也略等於現在的JTBD這個術語的意思。
把場景圖里面的廠商部分，再按照系統架構層級或者服務層級或者模塊拆分成不同的泳道，將場景圖中廠商部分的觸點細化為內部不同系統、模塊或團隊的交互過程，變成子條目。
需求條目化的實踐對於工具的要求是很高的，至少我心目中100分標准對工具是有很高要求的。比如上面的整個過程，核心關鍵在於有一個系統維護着這個三級結構，概念、條目、子條目每一級又可以展開需求詳情（比如 Wiki）。需求驗收標准拆分出來的測試用例要關聯至自動化測試腳本，或者本身就是可執行的，最好是跟前面的需求關聯起來，形成可執行需求。而且整個結構和各節點除了易於閱讀的模式，也即Wiki、Word文檔或系統里的表單格式之外，最好還能夠以一種純文本化、代碼化的形式存儲，可以像代碼一樣進行版本化管理，並支持工具自動生成完整的需求文檔，需求、測試、代碼的任何修改都能夠觸發整個流水線執行驗證，真正成為實例化需求所主張的活文檔（Living Documentation）。
本文分享自華為雲社區《用戶故事不是銀彈》，原文作者：kaverjody。