摘要：你覺得需求條目化怎麼樣？
曾經，大概在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。
點選關注，第一時間了解華為雲新鮮技術~