經過前面10章內容的描述，我們瞭解故事、故事卡片，以用戶故事推動的項目開發流程。實際開發中，團隊往往會先得到巨大的故事（需求）。從產品角度，拆分意味着放棄部分功能，這種放棄引起的損失，會帶來更痛苦的感受，難以抉擇。從開發角度，拆分是建立在功能低耦合前提下，而這一點，又是基於程序早期合理的架構。但現實卻是，研發過程中爲了進度而採用速效方法（不會做太多長遠考慮，這也是技術債產生的原因），長期的合理性變得不那麼重要。基於以上種種，拆分過程就變得十分痛苦和堅辛。
然而，爲了及時評估產品和進度，同時滿足資源與時間限制、降低成本和實現商業目標的要求，故事拆分都是不二之選。
一、由誰來拆
最近在網上常常見看到嘲諷甲方的段子，怎麼會有那麼多乙方公司？後來仔細一看，發現很多發段子的“乙方”,和他們嘲諷的甲方都在同一家公司。而這其實就是工作中常會出現的“甲方-乙方反模式”。
甲方-乙方反模式
這一反模式的表現是，團隊成員之間是”食客-服務員關係“，即我想要什麼，你就要給什麼。具體爲甲方清楚自己想要什麼，並表達給乙方，乙方則傾聽理解，並找到解決問題的技術方法。然而，乙方承諾的排期會受各種原因的影響，若不能按時完成，乙方可以找各種理由爲延期辯解。而甲方最終拿到功能後，也有可能發現不是自己想要的。最終，圍繞解決問題的對話，變成了圍繞需求的扯皮，最壞的情況是沒有人成爲贏家。在這場對話中，真正的核心其實是甲方需要清楚自己遇到的問題，而不是預測什麼方法最合適。很顯然，這種問題的一方面原因是故事（需求）的解決方案是由單一方決策。那麼由多方共同決策是否就可以解決這一問題呢？
一人決策與多人決策方式
在大多數場景下，需求都是由單一方來負責並決策的。而團隊成員常常表現爲“你來決定，告訴我就好了”、“你要達到的效果是什麼？”，對於單一方決策而言，這一場景實在太爽——指揮千軍萬馬，指哪兒打哪兒的快感油然而生。等等，這裏是不是存在什麼問題？指揮固然爽，然而一旦出問題，那麼團隊成員也會說“這個是你定的”、“我只是照着你說的做而已”。正所謂成也蕭何，敗也蕭何。讓我們來分析一下：
- 用戶故事由模糊到具體的過程中，需要展開多次對話，一個人是無法完成的；
- 在流程中的各個環節由各人負責，那麼各人也將成爲卡住流程的瓶頸；
- 一個人的知識、視野和專業範圍是有限的。
既然單一方決策會成爲瓶頸，那麼多方決策是否會更好？也不盡然，一方面，當資源有限時，參與決策者會傾向於妥協，每個人都無法達成目的；另一方面，當資源無限時，大家傾向於做所有的事情。想想我們開會的時候，沒有一個人做最終決策的情況。
探索團隊
《用戶故事地圖》提供了另外一種決策方式——由跨部門、小型團隊協作的方式進行，如題，它就是稱之爲“探索團隊”的決策組織。在這個組織中，共有2〜4個人，包括產品負責人、用戶體驗設計師（設計師）、資深技術人員，所有參與人員必須具有一流的溝通和協作能力。
這個團隊應該由一個對業務願景、戰略以及產品服務的市場有深度理解的產品負責人主導。這個核心團隊應該有這樣的人，他理解用戶，可以自如地和用戶合作，力求瞭解他們的工作方式，並且可以開發簡單的UI原型。這個團隊也應該包括一個來自開發團隊的資深工程師。這個人需要理解系統目前的架構，知道哪些新的技術方案可以用來解決目前的難題。
探索團隊應從探索階段就開始介入，終止於“故事工作坊”以完成最後一次討論。在故事工作坊中，除了探索團隊成員之外，還要納入測試人員等，共同定義最佳的開發和測試用時。探索團隊通過用戶故事的一系列方式，抽絲剝繭般梳理和評定用戶故事，將故事拆分爲大小合適的模塊。這些模塊，將最終流入開發流程中。
二、故事（需求）拆分
探索團隊負責拆分故事，比較合適的模塊大小是“每個模塊開發與測試時間共計1〜3天”。如何做到呢？《用戶故事地圖》並沒有提供具體的執行方法，但有一些思路值得借鑑。打個比方，如果把軟件比做大蛋糕，那麼切分的結果應該是怎樣的？應該是很多紙杯蛋糕（一定有人想到刀子把蛋糕切成一塊一塊）。每一個紙杯蛋糕可以獨立交付，食譜也都類似，都是一點糖、一點麪粉、一兩個雞蛋什麼的。
那些需要被拆分的故事被稱之爲“史詩故事”，我們會從三個角度來對它們進行切分：
- 用戶角度：可以滿足某一需要；
- 開發角度：只需要幾天時間就可以完成開發和測試；
- 業務角度：有助於實現業務目標；
此外，還需結合在《用戶故事地圖（9）：開發流程之“研發-評估-交付”階段》中講到的研發的三個階段。對故事（需求）進行拆分，它有些像碎石的過程，無論是怎樣的石頭，碎石的結果是得到一堆同樣的小石頭——這明顯是一個技術活兒。
三、故事（需求）聚合
有時候，我們的需求池中會充拆大量的小需求，它們細碎而不值得大動干戈，但堆積太多又不知如何處理。此時，我們需要拿起另外一把工具，就是“聚合”——可以將那些細碎的小故事聚合爲“主題”。
“主題”用以歸類故事——收集需要下個版本發佈、同一功能的不同版塊、以某種其他方式關聯的一堆故事。內容不多時候，我會直接根據需要將一堆小故事聚合在一個卡片中。當然，當這種故事很多時候，也可以採用以下方法：
- 有便籤寫下所有需求；
- 邀請理解系統的項目成員；
- 尋找一面牆；
- 給每個人分一些故事卡片；
- 大家憑土目水之，把相似的卡片放在一起；
- 過程中，大家安靜的做，不要交流；
- 最後溝通不同分類觀點的卡片；
- 每每一組一個相對具體的大標題，凝練故事；
以上方式是《用戶故事地圖》中介紹的方法，看來就是用研中“卡片分類法”的方式。
——end——
全部內容鏈接：
用戶故事地圖（1）：體驗用戶故事
用戶故事地圖（2）：作用
用戶故事地圖（3）：故事與卡片
用戶故事地圖（4）：創建方法
用戶故事地圖（5）：開發流程之“機會”階段
用戶故事地圖（6）：開發流程之“探索”階段
用戶故事地圖（7）：開發流程之“設計”階段
用戶故事地圖（8）：開發流程之“故事工作坊”階段
用戶故事地圖（9）：開發流程之“研發-評估-交付”階段
用戶故事地圖（10）：開發流程之“回顧”階段
用戶故事地圖（11）：故事（需求）拆分
用戶故事地圖（12）：後記