琴瑟和鳴--SCRUM中「講」好用戶故事

在大多數軟體產品研發團隊中，一開始做敏捷轉型，往往先引入SCRUM框架，過了一段時間，如果團隊把框架運轉的較順暢了，你就會發現好像還有些地方不完整。有哪些地方不完整呢？

SCRUM是敏捷開發中流行的開發框架，能夠很好解決產品團隊迭代過程敏捷化的問題。但是，從軟體產品研發全價值鏈角度來考慮，團隊迭代過程敏捷化了，也需要前面產品需求的敏捷化。只有產品需求和迭代過程都實現了敏捷化，才能更大發揮敏捷方法在軟體產品研發過程中的效用。

怎樣實現產品需求的敏捷化呢？用戶故事。

用戶故事由1996年Kent Beck在極限編程中提出概念，2004年Mike Cohn把用戶故事的方法系統化。用戶故事的出現應對了產品需求敏捷化的問題，也是精益敏捷團隊產品需求敏捷化應該進行的第一步。

用戶故事，顧名思義，是關於用戶的故事。在敏捷開發中，如何用好用戶故事一直是個較難的話題，大家一開始使用時，往往會忽略了故事是「講」出來的這一關鍵點。那麼，在SCRUM迭代研發過程中「講」好用戶故事有哪些作用呢？

1. 需求獲取時講故事獲取真實需求

講故事的方式對於用戶來說易於接受和理解，易於產品經理與用戶在業務層面進行需求信息的詳盡溝通，能夠促進更容易獲取到用戶真實的需求。

作為產品經理，在這個階段應該避免把解決方案和用戶需求混成一談，在需求獲取階段與用戶大談解決方案，會導致用戶的真實需求信息被扭曲，會放大我們對用戶價值判定的偏離。對用戶進行引導式解決方案的帶入，應該在較全面獲取到用戶真實需求後的某個時間點。

2. 需求分析時講故事提煉需求

需求分析的時候需要相關干係人集思廣益共同進行需求的整理，用戶故事的交談討論方式便於相關干係人以價值為導向，在業務層面達成大家對需求分析的共識，從而形成產品功能需求。

3. 需求定義時講故事探索需求（非功能需求和技術類需求）

需求定義的時候開發人員廣泛介入，講故事的方式能夠讓開發人員易於理解功能需求從而進一步探索並形成非功能需求；講故事的方式也能夠讓產品經理更容易從價值層面理解技術需求。

4. 需求溝通（交底）時講故事達成一致

講故事能夠同步大家的溝通方式和思考維度，用戶故事的經典三段式描述使大家溝通方式簡單，用戶》價值》操作的遞進式思考，使大家的思考維度一致，從而促進團隊中各種角色真正的一致理解需求。

5. 產品Backlog梳理時講故事進行估算排序

團隊通過對用戶故事估算排序時進行的幾輪討論，通過彼此講述和隱性學習，能夠更加細化用戶故事的描述和驗收標準，從而促進整個團隊對於需求的理解更加深入地達成一致。

6. 迭代計劃時講故事進行澄清

迭代計劃會上PO對用戶故事的講述澄清，能夠進一步降低需求的不可預測性，與團隊的速率匹配後，能夠增加團隊迭代計劃的精準度。

7. 迭代進行中講故事進行調整

迭代中不同角色（產品、開發、測試等）持續的討論能夠促進用戶故事描述的需求本身及其驗收標準不斷細化；用戶故事間相對優先順序的討論判定，使團隊在迭代中遇到外來緊急需求或者事件時，能夠保證在交付最有價值的前提下對原有迭代計劃做出適應性調整。

8. 需求驗證時講故事進行內部驗收

開發一旦自己認為完成了滿足用戶故事驗收標準的工作，可以馬上召集產品、測試對所完成的工作進行內部的講解演示。開發對故事講解演示，產品和測試人員參與驗證，一方面能夠使團隊整體的迭代交付風險前移，另一方面能夠促進團隊對於用戶需求的深入理解，從而更有效率地實現故事的交付驗證。

9. 用戶反饋時講故事進行價值驗證

用戶故事的獨立性、場景化的定義和交付，使用戶的體驗更完整，更容易提出反饋和團隊進行溝通，從而能夠促進可工作軟體的價值性驗證。反饋的容易減少了產品團隊與用戶的反饋環長度，增加了單位時間內產品團隊與用戶之間的反饋頻次，最終縮短了產品版本的上市周期。

敏捷宣言中，個體與互動高於流程和工具。其實，用戶故事的講故事正是很好地體現了「互動」，所以，要想用好用戶故事，我們先從「講「故事開始吧！