目錄
前言：
第1章 需求拆分的原則
1.1 了解需要背後的客戶價值
1.2 參考：使用者故事的定義方法
1.3 系統需求的層次
1.4 需求拆分的INVEST原則：小而整
1.5 需求拆分的三個準則：一個使用者、完整價值、不依賴。
第2章 9 種常見的垂直切分模式
2.1 按工作流程不同的操作步驟來切分（一個使用者操作入口、多個不同的操作步驟）
2.2 按使用者不同的操作類型切分 （使用者多個不同的操作類型）
2.3 按不同的業務規則拆分
2.4 按不同的資料類型或來源來切分
2.5 按不同的操作頁面切分
2.6 按不同任務進行切分
2.7 按不同的功能進行切分
2.8 按照不同非功能性需求拆分
2.9 按照不同的業務邏輯流程進行劃分
他山之石
前言：
在一個大規模複雜的系統中，通常需要采用某種方法來拆分客戶的需求，對需要的拆分是撰寫需求規範中必然遇到的一個問題，同時也是軟體架構設計中必然遇到的一個問題。如何拆分需求，不僅僅影響目标系統的架構、性能，同時也影響項目管理中軟體代碼實作的時間。相同的使用者需要，不同的拆分方法，導緻軟體開發的總的時間有可能會出現較大的差别，也會導緻系統的故障的個數有較大的差别。本文将探讨拆分需求常見的原則與方法，這些原則和方法同時也适用于系統架構設計。需求的垂直切片，本質上是将大的需求縱向拆分成小但有價值的、可獨立傳遞的小的需求。
第1章 需求拆分的原則
1.1 了解需要背後的客戶價值
在正式開始拆分需求之前，團隊應該花一些時間梳理和确定工作目标，充分了解工作範圍，比如涉及的利益相關者、需求驗收标準等等。其中，明确需求價值是最為重要的。
将研發需求進一步的拆分，本質上是對傳遞增量做出的進一步細分。如果待拆分的需求沒有明确的價值引導，那麼研發工作就極有可能進入錯誤的方向或者「死胡同」，導緻前功盡棄。
了解需求背後的客戶價值和對組織的價值，是拆分需要的高階思維。
1.2 參考：使用者故事的定義方法
[需求管理-5]：需求分析 - 如何進行有潛在商業價值需求的帥選？使用者故事的定義方法？_文火冰糖的矽基工坊的部落格
1.3 系統需求的層次
（1）功能性需求
（2）非功能性需求
1.4 需求拆分的INVEST原則：小而整
好的使用者故事除了格式規範、要素完整外，還應該遵循INVEST原則：
- 自身角度：獨立；
- 客戶角度：可協商、有價值
- 管理角度：可評估
- 開發角度：足夠小
- 測試角度：可測試
（1）Idependent（獨立的）-- 使用者故事自身的角度
要盡可能的讓一個使用者故事獨立于其他的使用者故事。
使用者故事間保持獨立性不僅便于排列和調整優先級，使得釋出和疊代計劃更容易制定，便于獨立地了解、跟蹤、實作、測試以及頻繁傳遞，也使得使用者故事的大小估算所涉及的範圍更清晰，進而估算偏差更小。
（2）Negotiable（可協商的）-- 客戶的角度
一個使用者故事的内容要是可以協商的，使用者故事不是合同。
一個使用者故事隻是對使用者故事的一個簡短的描述，不包括太多的細節；
具體的細節在溝通階段産出。
一個使用者故事帶有了太多的細節，實際上限制了使用者、團隊的想法和溝通。
（3）Valuable（有價值的） -- 客戶的角度
每個故事必須對客戶具有價值（無論是使用者、購買方還是公司内部角色）。
使用者故事對于最終的使用者是有價值的，是以應該站在使用者的角度去編寫，描述的是一個一個的feature，而非一個一個的task。
這個特點促進團隊的開發和測試成員由傳統的指令式工作方式向自驅動的價值導向工作方式轉變，使團隊中的每個人知道自己每天做的工作對客戶的價值。
（4）Estimatable（可評估）-- 項目管理的角度
計劃會議裡面一個很重要的環節，那就是故事點（工作量）的估計。
實際上就是對要開發的User Story進行一個粗量級的工作量的估算，以便于團隊能夠知道這個user story的複雜度（工作量）。
重點放在目前疊代裡能否按照該使用者故事的接收條件和團隊定義的DoD(完成标準)來完成這個使用者故事，如果不能完成，給出理由，由PO來決定是否拆分或者重新設計使用者故事。
開發者難以估計故事的原因：對于業務領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。
（5）Small（小的） -- 開發的角度
一個好的故事在工作量上要盡量短小。
最好不要超過10個理想人/天的工作量, 至少要確定的是在一個疊代中能夠完成。
使用者故事越大，在安排計劃，工作量估算等方面的風險就會越大。
備注：這裡給出的10個人天，并不适合所有的場合，主要适合網際網路的使用者功能，在無線通信領域，隻要一個10人的以内的小團隊在一個疊代周期内能夠完成，就可以認為已經足夠小了。
（6）Testable（可測試的）-- 測試的角度
一個使用者故事要是可以測試的，以便于使用者确認它是可以完成的。
如果一個使用者故事不能夠測試，那麼你就無法知道它什麼時候可以完成。
一個不可測試的使用者故事例子：軟體應該是易于使用的。
（7）補充：大小相等原則 -- 開發的角度
垂直拆分後的故事的開發工作量應該大緻相等，確定開發團隊能夠平穩地開發軟體需要。
1.5 需求拆分的三個準則：一個使用者、完整價值、不依賴。
（1）一個使用者
隻包含一個使用者，因為多個使用者常常有細微的差别。
一般是典型的使用者，常常有共同的某類需求。
（2）完整價值
完整地傳遞一個客戶價值。
一個完整的使用者故事意味着這個故事完成後，使用者可以達成一個明确的、有意義的目标。
（3）不依賴
依賴性的三種常見類型是：重疊、順序和包含。
重疊關系在故事之間功能點之間需要避免的；
順序關系是現實存在，在多數情況下可以通過一些手段解決；
包含關系對複雜系統是有幫助的，利于把複雜功能分解成簡單功能，但對排定釋出和疊代計劃的影響需要注意。
- 重疊依賴
重疊依賴是帶來最多困擾的依賴形式，特别是多個使用者故事包含多個不同的重疊部分時，很難找到一組使用者故事可以代表該最小可行産品的功能集合，該集合應該包含且僅包含一次需要的功能。
重疊導緻兩個故事重複實作某種功能，容易導緻邊界混亂和不清晰。
解決方式：
将重疊部分單獨剝離出來做為獨立的使用者故事；
合理拆分使用者故事，并且将重疊部分隻保留在一個最有内聚性的使用者故事中；
使用Scrum開發模式。
- 順序依賴
順序依賴是指要使某使用者故事完成，另外的一個或多個使用者故事必須在它之前完成。
順序依賴通常是無害的，在現實軟體開發是也是常見的現象。從靈活開發的角度，整個系統是從初始的最小可行産品逐漸演化為強大的産品，後面的每一步是建立在前面的基礎之上的。
但從另外的角度，不必要的順序依賴使得排列和調整優先級變的比較困難，進而影響制定釋出和疊代計劃，也使得使用者故事的大小估算更難以把握。（順序依賴主要影響項目管理）
解決方式：
一個疊代内的使用者故事盡量做到沒有内在依賴；
保持疊代之間隻有單向依賴，在時間上隻有後面疊代的故事對前面疊代故事的單向依賴（前向依賴）；
剝離出核心依賴作為獨立的故事，不要把有依賴和無依賴的需求混在一個故事裡。
盡可能把可以獨立的故事獨立出來。
- 包含依賴（自頂向下、自底向上）
包含依賴是指在組織使用者故事時使用分層級的管理，比如常見的特性－故事兩級管理，一個特性包含多個使用者故事，這樣就構成了特性對其屬下故事的包含依賴。
解決方式：
使用者故事一級用來做疊代計劃，避免用特性一級做粗粒度疊代計劃，特性一級可以用來做釋出計劃；
特性一級同樣可以進行拆分，直至拆分到最小市場化特性的程度，并将其包含的使用者故事分别歸到新拆分出的特性中去；
遵從最小可行産品的理念，一個特性分多個使用者故事多個疊代實作，每一個疊代可形成潛在可傳遞或者提供内部或外部回報。
第2章 9 種常見的垂直切分模式
聚合：使一個簡單的功能組合、聚合、疊加成一個越來越複雜的功能。
分解：把一個複雜的功能分解無數個越來越簡單的功能。
切分的本質，就是對使用者不同次元的行為進行分類，或按照時間次元或按照空間次元：
（1）根據操作的行為分類
（2）操作操作的資料分類
（3）根據操作的步驟分類
2.1 按工作流程不同的操作步驟來切分（一個使用者操作入口、多個不同的操作步驟）
工作流程是指工作事項的活動流向順序。工作流程包括實際工作過程中的工作環節、步驟和程式。
完整的工作流程可能會非常長，考慮的異常情況也可能很多，當開發完整的工作流程所需要的工作量很大的時候，就需要對工作流程進行拆分。
依照工作流程的步驟順序，将大需求拆分成一個個邏輯連續的、有獨立價值的使用者故事是最常見的拆分模式。如何把一個工作流程拆分成多個子流程呢？
（1）方法1：分段法
把一段流程的M個步驟，均勻的拆分成n個段，每個端的步驟 L = M/n。
這種方法的優點：簡單。
但這種方法有一個缺點：每一段隻是完整流程的一小段，無法構成端到端的使用者業務，無法為使用者提供端到端的服務。隻有全部分段都完成時，才能為使用者提供服務。
（2）方法2：主流程閉環，即 Happy Path法。
這是參考如何建構一個完善的、周全的工作流程的角度來看，如何拆分完善的、周全的工作流程。
這種方法：先找出完整流程的頭尾環節，逐漸加入更多的中間流程和異常處理子流程；
一頭一尾步驟，為使用者提供了開始和結束的完整流程，有了完整的架構，隻是中間過程不完善而已。為了使得整個流程更加的豐滿和完善，可以逐漸加入更多的中間流程和更多的異常處理子流程。根據二八定律指出，最有價值的流程往往隻占 20%，其餘的 80% 通常是次要的。是以，遵循先抓取最重要的工作流程，然後再逐漸擴大和豐富需求，增加新的故事集。
如下圖所示：
（1）先建立主流程的User Story
（2）逐漸把中間流程轉變成新的User Story
（3）逐漸把異常處理流程轉變成新的User Story
這樣一個大的業務流程，就可以分解成無數個User Story集合。或者說，通過豐富User Story集合，就可以豐富大的業務流程，使得一個業務流程越來越複雜。
2.2 按使用者不同的操作類型切分 （使用者多個不同的操作類型）
當一個大的功能需求與「管理」或「配置」等描述詞相關時，可以将其按照不同的使用者操作切分成更小的故事。常見的使用者操作有：增、删、減、查、更新等。如下圖所示：
每個獨立的操作，都可以拆成一個獨立的使用者故事和使用者功能需要。
2.3 按不同的業務規則拆分
業務規則是指對業務定義和限制的描述，用于維持業務結構或控制和影響業務的行為。不同的規則，控制目标系統的不同行為。
業務規則技術的基本思想是将系統處理的業務邏輯從程式代碼中抽取出來，将其轉變為簡單的業務規則，以結構化的業務規則資料來表示和控制業務行為，采用類自然語言來描述，并集中存儲在規則庫中。業務規則由業務人員建立、實時更新和調試，業務規則之間的複雜邏輯關系由規則引擎處理。業務規則技術改變了傳統的、以過程形式處理業務邏輯的方式。
比如Linux IP table就是基于業務規則來工作的，電影院賣票系統也可以定義各種規則。
此時，就可以按照業務規則來切分複雜的功能需要，每個規則就可以是一個User Story。
例如，線上售票系統的購票流程通常隐含對數量限制、排他性等規則，研發團隊可以先實作沒有限制條件的購票流程，再進一步實作不同限制規則相關的使用者故事，每個限制條件，就可以定義成一個使用者故事。如下圖所示：
2.4 按不同的資料類型或來源來切分
一個系統，如果處理不同類型或來源的資料對象，就可以根據不同的資料類型或資料來源，拆分大型需求，這在處理輸入/輸出操作的業務場景中，這是一種常用切分需求的手段。
團隊可以根據不同資料子集的優先順序，在一個疊代内專注一種資料類型的實作，以快速傳遞故事價值。最終支援所有類型的資料集。如下圖所示：
2.5 按不同的操作頁面切分
當待拆分需求涉及多個互動系統或多個使用者頁面的使用時，可以按照不同的使用者界面拆分多個使用者故事集。不同的使用者頁面，完成不同的功能。
2.6 按不同任務進行切分
2.7 按不同的功能進行切分
對于一些複雜的大型需求而言，在研發早期将全部情況都考慮并且實作是很困難的，是以可以先傳遞最基本的簡單版本，再依據其他的拆分模式做進一步擴充，将需求拆分為不同的故事合集，通過一個個更複雜的故事傳遞，逐漸實作大型需求。每個故事都是一個新的功能。
2.8 按照不同非功能性需求拆分
不同的非功能需求，都可以建構一個使用者故事