敏捷開發現在已經不是新鮮事物了，我們都從各種渠道聽到過不同的團隊實施敏捷的勝果，聽的時候覺得很美，回到家就發現那都是別人家的團隊，結合自己的情況一看就發現問題一大堆。就算是最終打算一試，也經常會不知如何開始。這就是我希望編寫這份文件的原因，能夠找到一個遵循的敏捷專案管理模型，雖然我們都知道沒有一個放之四海而皆準的方法，但在更高的層面上我覺得這仍然是可行的。也就是說，管理模型是一致的，但是其中採用的方法可能各有不同，最終目標是唯一的：打造一支可以快速適應變化的高質量團隊，並輸出高質量的產品！

今天想跟大家分享的是使用者故事的規劃過程，對於如何使用使用者故事驅動團隊的開發過程，後續會有更新。

使用者故事的主要問題

使用者故事可以幫助開發團隊從使用者的角度來理解需求，同時在交付的過程中按照使用者可用的場景進行交付，確保了開發團隊可以持續的交付使用者關心的功能。但是在實際開發中，團隊往往不知道如何入手。

如何用好使用者故事需要解決幾個關鍵問題：

• 如何產生使用者故事，讓使用者將故事講清楚？
• 如何將使用者故事的內容原汁原味的傳遞給開發團隊？
• 如何將使用者故事中的內容轉換為開發功能點，識別與其他功能點的依賴，形成詳細的產品規格？
• 如何在使用使用者故事進行增量開發的過程中保持架構的穩定性？同時驅動架構的優化和演進。
• 如何在開發過程中按照故事進行交付，協同開發，測試，架構以及UI/UE等團隊？
• 如何使用各種開發工具和平臺，藉助如任務跟蹤，分支計劃，持續整合，持續釋出，自動化測試等工具讓開發過程變得更加高效？

使用者故事的需求整理方式與傳統需求的整理方式有很大的不同，傳統軟體開發中我們依賴使用者需求，技術需求，規格說明書等工具試圖使用規範的文件來解決需求收集和傳遞的問題。在這個過程中，我們將使用者的需求轉換成技術可以理解並可實施的規格。對於已經習慣了這種方式的人來說，要轉換成使用使用者故事的方式需要比較大的思維方式轉變，大家往往遇到的疑問也是，難道使用使用者故事就不需要規格了嗎？其實不然，首先我們要了解使用者故事到底是什麼。

使用者故事到底是什麼？

大家可能覺得既然我們使用使用者故事來替代傳統需求，那麼使用者故事就是記錄需求的方式了。其實，使用者故事不是用來編寫的，而是用來討論和跟蹤的。

• 使用使用者故事，我們的目的是讓使用者可以自然的講述需求，這樣才能確保資訊的真實性。因為任何軟體產品都是為了幫助使用者完成某種任務，可以說任何的軟體產品或者系統都是通過互動來解決問題的，而互動的雙方可能是人和系統，也可能是系統和系統，也可能是模組和模組。這樣理解的話，任何的需求其實都是某個個體（人，系統或者模組）在和其他個體進行互動的過程中，我們希望的行為方式。使用者故事的3個關鍵點：人，過程和目的；可以幫助我們將這個行為方式講清楚。在講故事這個過程中，我們應該專注於故事主線，而不是如何實現。
• 一旦使用者講清楚了故事，下一步我們需要產生相應的可開發的功能點。這裡我們需要專注於如何實現。一般來說，我們很難通過一個功能點來滿足一個使用者故事，而必須要不同的功能點配合完成。但是我們仍然必須確保討論的範圍是僅僅圍繞當前的故事，這時候技術人員非常容易發散，會考慮一些和當前功能點相關，但是和當前故事不相關的內容，如：這個功能可能以後還要用到的，所以我們還要這樣這樣等等。這時，使用者故事可以起到控制討論範圍的作用。你可能會覺得，技術人員的角度是對的，因為可擴充套件，可複用等是軟體設計的基本原則。但是我們應該從發展的角度來看待這些問題，假設我們可以預見的其他使用者故事確實會影響這個功能點，那麼這樣考慮是ok的，但是應該到討論那個使用者故事的時候再去考慮；如果我們沒有其他可以預見的故事會影響這個功能點，那麼這些所謂的擴充套件性複用性設計就是浪費，因為你不知道是否會需要。
• 討論清楚了功能點，進入開發以後，使用者故事是控制技術團隊開發進度和交付進度的引線，也就是我們應該按照故事一個個的進行開發測試和交付。這樣才能確保我們交付的永遠和使用者預期一致，所有的開發，測試投入都是可以產生使用者認可的價值的。這個時候使用者故事起到了跟蹤和驅動開發過程的作用。

通過以上分析，我們可以看到使用者故事如何編寫並不重要，重要的是它所驅動的過程，通過這個過程，我們可以把使用者和技術團隊緊密結合，並讓大家產生對交付內容的統一認識。所以，使用者故事是一種溝通工具，而不是編寫工具或者需求模板！

故事講給誰？

在真正開始將故事之前，我們首先要確保正確人都參與進來。對於規劃一款產品來說，你至少需要：終端使用者代表，產品經理（或類似Scrum中的PO），專案經理（或類似Scrum中的ScrumMaster），團隊中的技術骨幹（那些對實現的業務很熟悉，對所要使用的技術或者系統很熟悉的技術人員），技術骨幹又可以分成架構，開發和測試三個不同技能的人。這樣看來，你至少需要6個人參與這個講故事的過程（除非有些人可以互相替代）。

你的故事是講給這裡面每個人聽的，同時也希望每個人都能夠在講故事的時候有所輸入，不僅僅是在聽。

• 終端使用者代表：這些人一般會作為講故事的主角，因為他們是最瞭解故事的人。但是終端使用者代表只能用使用者的角度來描述故事，這裡會缺失很多技術細節。當他們開始講故事的時候，技術人員就需要補充這些細節，將那些從使用者角度看上去可能很簡單的故事後面所涉及到的複雜度暴露出來。
• 產品經理和專案經理：這兩名成員基本起到協調人的作用，一般產品經理（PO）偏向使用者，專案經理（ScrumMaster）偏向團隊。我們希望他們的這種傾向性能夠在討論過程中體現出來，將故事的優先順序，重要程度，實現難度等問題進行歸納總結，形成我們的專案計劃。同時，這個故事討論的過程一般都是以會議形式進行，這2個人應該作為會議的組織者（主持人）出現，引導團隊高效的完成討論過程。
• 技術骨幹：首先技術人員要明確自己也是主角，而不僅僅是旁聽。很多人都有這樣的體會，明明很簡單的一個功能，為啥做起來會那麼慢？這裡面有2個原因，第一個是使用者自己就沒有吧這個所謂的“簡單”功能想明白；第二個是一個對使用者“簡單”的功能，對於技術來說恐怕沒有那麼簡單，但這個資訊一般很難跟使用者講明白，所以很多技術就傾向於不說或者說的很少。結果就是雙方對於難度的認知不一致。技術骨幹參與這個講故事的過程的目的，主要就是為了幫助使用者從技術實現的角度理解故事，同時自己也能夠將技術實現的思路想明白。

怎樣講故事？

講故事的過程我們通過3個步驟進行：找線索 -> 畫主線 -> 規格化

找線索 – 畫出故事的主角

使用者不知道從哪裡開始講故事，這是我們會遇到的第一個問題。其實這時候使用者的內心感覺就如同看完一部電影以後走出電影院，試圖給沒有看過這個電影的朋友講述。想一想在這個場景下你會如何開始？比如，大話西遊大家都看過吧；那麼講故事的方式是，孫悟空在500年前如何如何….，然後紫霞仙子如何如何… 你會發現，你永遠都會從某個角色開始講述。其實讓使用者講故事的方式也一樣，我們首先要引導使用者說出這個故事裡都有誰。一部電影是多個角色的故事線交織的結果，一個產品也是一樣。有了這些角色，我們就有了可以抽取故事的線索。

這裡我們可以藉助2個工具來協助找線索：影響地圖和使用者畫像（1、2）

你會發現，當團隊開始整理不同的型別的使用者的時候，他們已經開始自然的講述故事，因為要把一個角色說清楚，你就必須考慮他要做的事情，故事自然就出來了。但是在這個階段，我們切記不要過於發散，明確我們的目的是整理使用者畫像，只要不同使用者型別間的邊界清晰了，就可以結束，不要為細節糾纏。另外，在後續的過程中我們也會發現可能有些角色還需要新增進去，那麼就到時候說。

最終將我們整理出的每個使用者型別用一張即時貼粘在白板的最左側，如下圖：

一般我會按照距離終端使用者的遠近來擺放這些即時貼，同時對每個角色進行編號，以便後續可以很容易的進行引用。

畫主線 – 使用影響地圖畫出故事主線

有了故事的主角，講故事就相對容易了。在這個階段，我們希望能夠幫助團隊儘量將故事的每一個步驟的都想清楚，通過在看板上進行視覺化，我們就可以達到這個目的。這裡， 我們可以使用簡化版的影響地圖，如下圖：

標準的影響地圖上有4個列，分別是WHY WHO HOW和WHAT，這種結構在進行比較大和模糊的目標討論的時候，如：戰略規劃，會很好用，因為HOW和WHAT比較容易區分；但是用在討論使用者故事的步驟時候，其實HOW和WHAT區別不大，如果堅持使用規範的影響地圖會讓團隊感到迷惑。所以，我建議將HOW/WHAT合併。具體來說：

WHY：我們這個使用者故事是什麼？為什麼我們要做這個故事？
WHO：這個故事裡面都有哪些角色？
HOW/WHAT：這些使用者為了完成這個故事，需要做些什麼，怎樣操作？

如上圖：是一個標準的“新使用者註冊”的使用者故事，大家一定都非常熟悉。基本上這個故事就是瀏覽者通過 登入->註冊->填寫資訊->驗證郵件提交註冊，管理員稽核，成為已註冊使用者後首次登入->完善資料。但通過卡片的方式將每個步驟放入白板後你會發現，整個團隊可以很好的聚焦到很細節的問題上，同時又對整個故事具備全域性觀。如果不借助這種視覺化方式，那麼團隊可能很容易丟失當前討論的主線，從一個細節延展開到其他的部分去了。

注意這裡對每個使用者故事進行了ID標註，同樣也是為了後續可以容易進行引用。

你可能會問，那我用個思維導圖一類的工具不是更好麼？電子化工具的好處是對資訊的儲存和分享方便，但是在團隊討論中，我們更加重視團隊討論的氛圍，聚焦和整體效率，如果使用電子化工具，就無法讓每個人都可以同時對這張圖進行操作，而必須由一個人操作，其他人很容易走神，如果工具不熟練還會耽誤時間。所以看上白板是個很Low的工具，其實對於團隊討論來說，它的效率高於任何的電子化工具。

如上圖：這是我作為敏捷教練參與的一次使用者故事討論，你可以看到大家都聚集在白板周圍，整個討論都是站立進行，任何人都可以隨時發表意見，用手指著某個即時貼就可以開始說：“這個”步驟怎樣怎樣。如果沒有視覺化工具，或者使用電子化工具，希望每個人都可以用“這個”來聚焦所有人的注意力是很困難的，你可能需要解釋“這個”到底是什麼，又或者需要在電子工具中滑鼠來點，如果操作者不是講解者，那會更加麻煩。細節決定效率！

規格化 – 使用使用者故事地圖進行功能分析

有了故事主線，我們就可以進行下一步的功能細化。這一步所產出的其實就是傳統軟體開發過程中的軟體規格說明書。軟體規格說明書對於開發人員實現產品功能非常重要，是軟體開發中不可缺少的部分。很多人認為敏捷開發不需要文件，其實這是個巨大的誤解。但是敏捷開發中的文件確實和傳統的需求文件有很多區別：

• 敏捷開發重視的是文件產生的過程，希望通過透明化的過程和集體討論來確保內容的完整性和資訊在過程中的傳遞。對於文件本身的格式倒是沒有具體的要求，只要確保討論中的內容都被記錄就可以。
• 敏捷開發中的文件並不是用來傳遞需求的主體，人才是傳遞需求的主體。
• 敏捷開發的文件是一份活的文件，所以我們更希望通過系統來記錄需求，而不是傳統的word或者excel等靜態文件來記錄。這些文件的作用是幫助團隊成員來回憶和講述，同時也作為過程追蹤的手段。
• 傳統軟體開發中往往有2份專案計劃，一份列出需求並在需求上進行估算以便推匯出預算；另外一份是時間和資源計劃，這份計劃又往往是按照階段來進行規劃的。敏捷開發只有一份專案計劃，就是按照使用者故事來組織時間，資源和各個階段的跟蹤 – 這其實就是使用者故事驅動的敏捷開發的含義。

規格化的過程中我們可以使用使用者故事地圖的方式來進行，團隊一起根據故事主線中的每個步驟進行討論，分析出在產品的特定區域（模組）中的功能點，並使用技術人員容易理解的方式來描述這部分的功能。這整個過程就是從將需求從使用者角度的描述轉換到技術實現角度描述的過程。在這個過程中你會發現一些在故事主線中看不到的技術細節。

這個過程中，我們希望綜合考慮架構和測試的輸入，這兩個角色需要從自己的角度確保每個故事的分解都滿足架構的要求，並且是可以進行測試的。由於每個使用者故事都會穿越多個功能區域，架構師必須協助團隊確保架構的擴充套件性，複用性以及效能等要求。對於測試來說，要確保每個使用者故事都是可測試的才能確保後續的測試計劃和用例可以配合團隊的開發過程，並按照故事逐個交付給使用者。

如上圖，將以上使用者登入這個故事分解為功能點，展示在使用者故事地圖上，這是標準的使用者故事地圖格式：

• 最上面2層是產品的功能區域（模組）
• 每個模組下面功能點，這些功能點來自於使用者故事中的某個步驟的分析
• 每個功能點的即時貼上標註出使用者故事的ID，這樣便於我們比對影像地圖找到對應的功能點
• 一些在影響地圖中沒有明確列出的內容在這張圖上被顯示出來，比如上圖中後臺管理和系統功能部分的內容

如何組織需求討論會

講故事的過程我們一般通過需求討論會的形式來進行，確保以上應該參與的人員都到場。既然是個會議，我們就必須確保會議的高效，這裡可以參考三星高效會議的8點原則：

（1）凡是會議，必有主題；
（2）凡是主題，必有議程；
（3）凡是議程，必有決議；
（4）凡是決議，必有跟蹤；
（5）凡是追蹤，必有結果；
（6）凡是結果，必有責任；
（7）凡是責任，必有獎罰；
（8）凡是獎罰，必須透明。

針對需求討論會，我們至少需要有以下安排

• 會議主題：XXX產品需求討論會，目的是在4小時內對XXX產品的XXX內容進行討論
• 會議議程：
  
  • 組織者：產品經理XXX或者專案經理XXX
  • 參與者：業務方或終端使用者，產品/專案經理，團隊技術人員（架構，開發，測試等）
  • 討論內容（按照優先順序排序的故事列表）
• 會議分工：
  
  • 主持人：由產品經理和專案經理輪換組織
  • 需求記錄人：由技術團隊內某人承擔，負責在討論過程中將使用者故事和所產生的功能點進行詳細記錄，形成文件或者錄入系統。
  • 問題記錄人：由技術團隊內某人承擔，負責在討論過程中將無法現場確認的問題進行記錄，形成文件或者錄入管理系統。
• 會議交付物：
  
  • 針對議程中的每個使用者故事所產生的文件或者管理系統記錄
  • 討論過程中所記錄的問題列表或者管理系統記錄
  • 針對使用者故事文件的下一步操作，如：制定開發計劃，預算等等
  • 針對問題的跟蹤方式，如：問題列表的狀態由誰負責維護，每個問題由誰負責解決跟進，每個問題預計解決的時間。

需求討論會的過程就是按照以上3個步驟討論故事和分析故事的過程，我們可以按照以下流程進行

• 討論會前期準備
  
  • 可以在進行正式的需求討論會前先進行一次頭腦風暴，邀請使用者和技術一同參與，在這個過程中大家可以自由討論。目的是讓大家現對產品的大致情況有所瞭解。
• 討論會過程
  
  • 首先由主持人（產品經理PO/專案經理ScrumMaster）向團隊列出會議所要討論的故事列表，這個過程不用討論細節，目的是讓大家知道會議的內容和目標，便於控制進度。
  • 根據所列出的故事列表優先順序，從第1個故事開始梳理故事主線，分解功能點，並由專人負責記錄
  • 重複以上過程直到完成列表中所有故事的討論
• 注意事項
  
  • 一定要按照故事列表逐個討論，每個討論都要細化到功能點並完成記錄，再進入下一個故事的討論；不要先討論所有故事主線，在一併分解功能點。這樣做的目的是讓團隊可以聚焦，避免多條線索交織造成干擾。
  • 在討論每個故事的時候，不要討論與當前主線無關的內容；特別是技術團隊容易從一個功能點擴散到其他功能點，因為這是技術團隊對產品的視角；這種擴散會降低效率。主持人在看到這種情況的時候應該適時制止，告訴團隊其他的功能點可以留到其他故事中討論，只要的產品的一部分，我們在後續的故事中肯定會涉及。
  • 完成每個故事的討論後可以進行短暫休息，在討論過程中要確保每個參與成員都集中精力，避免形成小組討論的形式。建議每個故事的討論都站立在白板前進行。
  • 主持人可以由PO和ScrumMaster按照故事進行輪換，主持人的主要職責是確保過程的順暢，團隊精力的集中。
  • 待確認事項
  • 建議在白板上開闢一片區域對討論中出現的團隊無法當場確認的問題進行記錄，避免在這些問題上糾結太久，影響會議效率。

以上是如何使用使用者故事來驅動產品規劃和設計的過程，後續我會對如何再借助kanban和Scrum來驅動開發和交付過程。

（責編/錢曙光，關注架構和演算法領域，尋求報道或者投稿請發郵件[email protected]，另有「CSDN 高階架構師群」，內有諸多知名網際網路公司的大牛架構師，歡迎架構師加微信qshuguang2008申請入群，備註:姓名+公司+職位。）