引言
對于一個使用者需求，産品、開發和測試對這個需求的了解完全不一樣，最終傳遞的産品根本不是使用者想要的，這種情況在實際開發中非常普遍。
使用者故事也是一種将需求可視化的工具，它通過将需求拆分成一個一個的使用者故事，來組織軟體開發。每一個使用者故事都是軟體開發過程中相關角色溝通的媒介，是以使用者故事也是一種通過合作溝通的方式來了解使用者需求的工具。
軟體開發是團隊項目
随着軟體系統的規模越來越龐大，軟體開發過程中的分工越來越明細，靠單兵作戰來實作複雜系統越來越不現實。在企業中，無論是合同項目還是自有産品，通常采用項目管理模式，成立專門的項目組(Team),進行具體的研發工作。項目組通常由多種角色的成員構成，角色對應的職責如下：
(1)項目經理
項目的主要責任人，對項目的進度和品質負有主要責任。項目經理主要負責項目的日常管理，如計劃制訂、任務跟蹤、溝通協調、團隊建設、需求分析、技術稽核等
(2)産品經理
一般自有産品才會配備産品經理，主要負責市場調研、産品策劃、撰寫産品的需求、跟蹤産品的實作、協助市場人員進行産品的營銷、擷取使用者回報、産品的改進等
(3)架構師
主要負責系統的總體設計、詳細設計，撰寫設計文檔。
(4)軟體工程師
完成需求分析、軟體功能的開發和單元測試及相關文檔的撰寫。
(5)測試工程師
編寫測試用例，制訂并執行測試計劃，進行內建測試和系統測試。
上面隻是列舉了一個項目組通常具有的角色，每個項目的大小和類型不盡相同，項目對技術能力的要求及項目成員水準也各不相同，要根據自己的際情況來安排，團隊協作是個老生常談的話題，但真正做到高效協作并非易事。
什麼是使用者故事？
使用者故事之是以叫“故事”，是因為它是用來“講”，而不是用來“寫”的。它從使用者的角度來講述如何使用軟體的功能，帶來怎樣的收益。整個軟體團隊通過講使用者故事，讓大家獲得對軟體産品的一緻了解，然後共同創造出更符合使用者需求的産品。
如何"講"好使用者故事
就像上面提到的，使用者故事是用來“講”的，而不隻是“寫”的。上面的例子中，如果這個不讨論使用者故事，你能知道【立即顯示】是輸入 1 個字、 2 個字，還是有光标就能顯示呢？是以，“講故事”是本課時的核心觀點，使用者故事的關鍵就是“講”。那麼，怎樣才能“講”好使用者故事呢？
1、聚焦全景
軟體開發最終傳遞給使用者的是一個可以工作的軟體，這就需要先實作一個一個單獨的功能。是以，我們需要将一個大需求進行合理拆分，拆分後的需求就稱為“使用者故事”。
2、3C原則
3C 原則是在由 Ron Jeffries（羅恩·傑弗裡斯） 等人在《極限程式設計實施》一書中提出的。3C 原則描述的是為了更有效的使用使用者故事進行需求分析時應該遵循的原則：
卡片（Card）：在卡片上寫下所期望的軟體特性。
交談（Conversation）：聚在一起對要開發的軟體進行深入讨論。
确認（Confirmation）：對完成的特性進行确認。
1. 卡片（Card）
卡片是使用者故事的載體，用來記錄使用者想要的每一個産品特性，上圖中的每一個使用者故事卡片都對此有所展現。
通過這種方式，可以很容易地組織這些卡片，比如通過拖拽的方式選擇本次疊代需要傳遞的使用者故事，排列使用者故事的優先級等。
2. 交談（Conversation）
建立好卡片後，我們并不是直接将卡片甩給團隊中的其他角色。而是請相關人員圍繞卡片中的使用者故事進行讨論。在讨論過程中：
每個參與者都可以通過提問來表達自己的疑惑，其他參與者則可以幫助解答。如果在某個問題上有分歧，則所有參與人員共同讨論決定。
除了使用建立好的卡片之外，還可以借助像思維導圖、流程圖、原型圖等有助于了解的可視化工具，避免參與人員通過手勢對着空氣揮舞。
讨論中所涉及的問題都需要進行标記、并在事後進行修正整理。
總之，交談的目的是讓所有參與者對使用者故事達成一緻的了解，并一起努力找到解決問題的最佳方案。就像看到旅行照片一樣，團隊成員當看到這張卡片時就能回憶起當時讨論的細節。
3. 确認（Confirmation）
現在，團隊成員已經對使用者故事達成了一緻，這時就需要考慮如何判斷這個使用者故事是否已經完成開發，也就是明确驗收條件。
一般情況下，當開發完成後需要通過單元測試、SIT 測試、UAT 測試，通過測試後該使用者故事才算完成。剩下的就是根據業務需要随時釋出該功能到生産環境中，完成最終的使用者傳遞。
3、故事模闆
現在你了解了講好使用者故事需要注意的幾個方面，但作為軟體從業人員來說，這還不夠。相對于産品和市場人員來說，很多開發人員不知道如何去講使用者故事，也不習慣講使用者故事。這時，你需要使用使用者故事模闆，這樣就能夠對卡片上的内容有一個指引，友善讨論。如下圖所示：
為了達到更好的讨論效果，這裡羅列幾個讨論清單：
- 讨論使用者角色。 不要單純地将所有使用軟體的人抽象為“使用者”，要更加具體，比如企業使用者還是個人使用者，個人使用者又可以根據年齡、性别進行細分。每一個使用者群體對軟體的訴求是不一樣的。
- 讨論要做的功能。 不要隻讨論使用者能夠看得見摸得着的界面功能，也要考慮界面後所調用的背景服務，其他服務與服務之間的調用關系、服務調用時的鑒權功能等也需要考慮。因為這些才是軟體可工作的基礎。
- 讨論該功能的價值。 讨論為什麼使用者需要這個功能。提問也是一門藝術，可以通過 5 Why 提問法，多問幾個為什麼，就可以發現隐藏在背後的真正原因。
- 讨論異常情況。 讨論可能出現的異常情況，以及出現異常後的解決方案。
- 讨論開發周期。 讨論使用者故事什麼時間完成開發，什麼時間完成測試，什麼時間最終傳遞給使用者......為這些時間點提供一個預估的計劃表。
使用者故事及使用者故事地圖，很多企業的研發團隊中都有使用。就像開頭提到的那樣，軟體開發是一個團隊項目，在團隊中溝通協調是至關重要的。
總結
團隊協作一直是貫穿于軟體研發全流程，一套高效協同的工具或方法論，可以有效的提高研發效率、保障傳遞的品質，使用者故事在現如今軟體疊代速度越來越快的今天，是一個值得一試的工具。