【文思不藏私】使用者故事對照 Part 3
故事的分解
每一個產品需求都有一個中心目標（Goals），我們可以透過『影響地圖』了解『為什麼（Why）？』『是誰（Who）？』『如何（How）？』『是什麼（What）？』來可視化產品需求及其背後的假設與影響（Impact）。
其次才是預期『交付的產物』（Deliverables），由這些『交付的產物』衍伸出的則是『使用者故事集』（User Activities）。有些時候我們也會用『主題』（Theme）這個詞來描述這一群相關聯的『使用者故事集』。『使用者故事對照』把這個過程稱為『岩石分解』，將大岩石分解成小岩石，也是就是將大故事分解成小故事的過程。其中分解岩石的槌子就像是分解故事用的『對話』一樣。
『對話是分解大故事的最佳工具之一』
故事的發掘
同時間發掘（Discovery）一些問題，認真檢視我們的假設並且驗證他們。這些最後產生出來的
- 『你相信哪些客戶和使用者將使用你的解決方案？』
- 『沒有你的解決方案，他們目前如何滿足他們的需求？』
- 『你的解決方案將如何改變他們的世界？』
- 『你的解決方案可能採用什麼樣的行為與外觀？』
- 『你的解決方案可能花費多久時間建造？』
『對話』的目的在於傳播資訊與分享共同的理解。讓開發者、使用者、及參與軟體建造的其他團隊成員一起進一步討論，深入細節中並同意『確認』的事項，產生出每個故事的驗收條件（Accptance Criteria）。最後將這些達成共識的故事就會被帶進下一回合的開發衝刺（Sprint）或迭代（Iteration）。這些過程的目的是幫助理解產品與需求，可能在『衝刺規劃』（Sprint Planning）、『待處理項目精煉會議』（Product Backlog Refinement）或『每日站立會議』（Daily Standup Meeting）發生。
故事的評估
不管你是不是有跑 Scrum，產品的開發過程中需要有停下來進行審查與反思的時間。停下來，好好的檢視目前故事的開發品質，計劃是否有效呢？做出來的東西跟預期的一樣嗎？比預期花更多或更少時間呢？這是一個讓我們調整跟改變的最佳契機，讓產品有更好的品質，讓事情能按預期的完成。
- 跟客戶與使用者一起評估、測試
- 跟利害關係人一起評估、測試
- 定期釋出並且持續的進行評估、測試
