本系列的第二篇【使用者故事驅動的敏捷開發（建立backlog）】
敏捷開發現在已經不是新鮮事物了，我們都從各種渠道聽到過不同的團隊實施敏捷的勝果，聽的時候覺得很美，回到家就發現那都是別人家的團隊，結合自己的情況一看就發現問題一大堆。就算是最終打算一試，也經常會不知如何開始。這就是我希望編寫這份文件的原因，能夠找到乙個遵循的敏捷專案管理模型，雖然我們都知道沒有乙個放之四海而皆準的方法，但在更高的層面上我覺得這仍然是可行的。也就是說，管理模型是一致的，但是其中採用的方法可能各有不同，最終目標是唯一的：打造一支可以快速適應變化的高質量團隊，並輸出高質量的產品！
今天想跟大家分享的是使用者故事的規劃過程，對於如何使用使用者故事驅動團隊的開發過程，後續會有更新。
使用者故事可以幫助開發團隊從使用者的角度來理解需求，同時在交付的過程中按照使用者可用的場景進行交付，確保了開發團隊可以持續的交付使用者關心的功能。但是在實際開發中，團隊往往不知道如何入手。
使用者故事的需求整理方式與傳統需求的整理方式有很大的不同，傳統軟體開發中我們依賴使用者需求，技術需求，規格說明書等工具試圖使用規範的文件來解決需求收集和傳遞的問題。在這個過程中，我們將使用者的需求轉換成技術可以理解並可實施的規格。對於已經習慣了這種方式的人來說，要轉換成使用使用者故事的方式需要比較大的思維方式轉變，大家往往遇到的疑問也是，難道使用使用者故事就不需要規格了嗎？其實不然，首先我們要了解使用者故事到底是什麼。
大家可能覺得既然我們使用使用者故事來替代傳統需求，那麼使用者故事就是記錄需求的方式了。其實，使用者故事不是用來編寫的，而是用來討論和跟蹤的。
通過以上分析，我們可以看到使用者故事如何編寫並不重要，重要的是它所驅動的過程，通過這個過程，我們可以把使用者和技術團隊緊密結合，並讓大家產生對交付內容的統一認識。所以，使用者故事是一種溝通工具，而不是編寫工具或者需求模板！
在真正開始將故事之前，我們首先要確保正確人都參與進來。對於規劃一款產品來說，你至少需要：終端使用者代表，產品經理（或類似scrum中的po），專案經理（或類似scrum中的scrummaster），團隊中的技術骨幹（那些對實現的業務很熟悉，對所要使用的技術或者系統很熟悉的技術人員），技術骨幹又可以分成架構，開發和測試三個不同技能的人。這樣看來，你至少需要6個人參與這個講故事的過程（除非有些人可以互相替代）。
你的故事是講給這裡面每個人聽的，同時也希望每個人都能夠在講故事的時候有所輸入，不僅僅是在聽。
講故事的過程我們通過3個步驟進行：找線索 -> 畫主線 -> 規格化
使用者不知道從**開始講故事，這是我們會遇到的第乙個問題。其實這時候使用者的內心感覺就如同看完一部電影以後走出電影院，試圖給沒有看過這個電影的朋友講述。想一想在這個場景下你會如何開始？比如，大話西遊大家都看過吧；那麼講故事的方式是，孫悟空在500年前如何如何….，然後紫霞仙子如何如何… 你會發現，你永遠都會從某個角色開始講述。其實讓使用者講故事的方式也一樣，我們首先要引導使用者說出這個故事裡都有誰。一部電影是多個角色的故事線交織的結果，乙個產品也是一樣。有了這些角色，我們就有了可以抽取故事的線索。
你會發現，當團隊開始整理不同的型別的使用者的時候，他們已經開始自然的講述故事，因為要把乙個角色說清楚，你就必須考慮他要做的事情，故事自然就出來了。但是在這個階段，我們切記不要過於發散，明確我們的目的是整理使用者畫像，只要不同使用者型別間的邊界清晰了，就可以結束，不要為細節糾纏。另外，在後續的過程中我們也會發現可能有些角色還需要新增進去，那麼就到時候說。
一般我會按照距離終端使用者的遠近來擺放這些即時貼，同時對每個角色進行編號，以便後續可以很容易的進行引用。
有了故事的主角，講故事就相對容易了。在這個階段，我們希望能夠幫助團隊盡量將故事的每乙個步驟的都想清楚，通過在看板上進行視覺化，我們就可以達到這個目的。這裡， 我們可以使用簡化版的影響地圖，如下圖：
標準的影響地圖上有4個列，分別是why who how和what，這種結構在進行比較大和模糊的目標討論的時候，如：戰略規劃，會很好用，因為how和what比較容易區分；但是用在討論使用者故事的步驟時候，其實how和what區別不大，如果堅持使用規範的影響地圖會讓團隊感到迷惑。所以，我建議將how/what合併。具體來說：
why：我們這個使用者故事是什麼？為什麼我們要做這個故事？
who：這個故事裡面都有哪些角色？
how/what：這些使用者為了完成這個故事，需要做些什麼，怎樣操作？
如上圖：是乙個標準的「新使用者註冊」的使用者故事，大家一定都非常熟悉。基本上這個故事就是瀏覽者通過 登入->註冊->填寫資訊->驗證郵件提交註冊，管理員審核，成為已註冊使用者後首次登入->完善資料。但通過卡片的方式將每個步驟放入白板後你會發現，整個團隊可以很好的聚焦到很細節的問題上，同時又對整個故事具備全域性觀。如果不借助這種視覺化方式，那麼團隊可能很容易丟失當前討論的主線，從乙個細節延展開到其他的部分去了。
注意這裡對每個使用者故事進行了id標註，同樣也是為了後續可以容易進行引用。
你可能會問，那我用個思維導圖一類的工具不是更好麼？電子化工具的好處是對資訊的儲存和分享方便，但是在團隊討論中，我們更加重視團隊討論的氛圍，聚焦和整體效率，如果使用電子化工具，就無法讓每個人都可以同時對這張圖進行操作，而必須由乙個人操作，其他人很容易走神，如果工具不熟練還會耽誤時間。所以看上白板是個很low的工具，其實對於團隊討論來說，它的效率高於任何的電子化工具。
如上圖：這是我作為敏捷教練參與的一次使用者故事討論，你可以看到大家都聚集在白板周圍，整個討論都是站立進行，任何人都可以隨時發表意見，用手指著某個即時貼就可以開始說：「這個」步驟怎樣怎樣。如果沒有視覺化工具，或者使用電子化工具，希望每個人都可以用「這個」來聚焦所有人的注意力是很困難的，你可能需要解釋「這個」到底是什麼，又或者需要在電子工具中滑鼠來點，如果操作者不是講解者，那會更加麻煩。細節決定效率！
有了故事主線，我們就可以進行下一步的功能細化。這一步所產出的其實就是傳統軟體開發過程中的軟體規格說明書。軟體規格說明書對於開發人員實現產品功能非常重要，是軟體開發中不可缺少的部分。很多人認為敏捷開發不需要文件，其實這是個巨大的誤解。但是敏捷開發中的文件確實和傳統的需求文件有很多區別：
規格化的過程中我們可以使用使用者故事地圖的方式來進行，團隊一起根據故事主線中的每個步驟進行討論，分析出在產品的特定區域（模組）中的功能點，並使用技術人員容易理解的方式來描述這部分的功能。這整個過程就是從將需求從使用者角度的描述轉換到技術實現角度描述的過程。在這個過程中你會發現一些在故事主線中看不到的技術細節。
這個過程中，我們希望綜合考慮架構和測試的輸入，這兩個角色需要從自己的角度確保每個故事的分解都滿足架構的要求，並且是可以進行測試的。由於每個使用者故事都會穿越多個功能區域，架構師必須協助團隊確保架構的擴充套件性，復用性以及效能等要求。對於測試來說，要確保每個使用者故事都是可測試的才能確保後續的測試計畫和用例可以配合團隊的開發過程，並按照故事逐個交付給使用者。
（1）凡是會議，必有主題；
（2）凡是主題，必有議程；
（3）凡是議程，必有決議；
（4）凡是決議，必有跟蹤；
（5）凡是追蹤，必有結果；
（6）凡是結果，必有責任；
（7）凡是責任，必有獎罰；
（8）凡是獎罰，必須透明。
針對需求討論會，我們至少需要有以下安排
會議分工：
會議交付物：
需求討論會的過程就是按照以上3個步驟討論故事和分析故事的過程，我們可以按照以下流程進行
討論會過程
注意事項
以上是如何使用使用者故事來驅動產品規劃和設計的過程，後續我會對如何再借助kanban和scrum來驅動開發和交付過程。
使用者故事驅動的敏捷開發（建立backlog）
本系列的第一篇 使用者故事驅動的敏捷開發 規劃篇 跟大家分享了如何使用使用者故事來幫助團隊建立需求的過程，在這一篇中，我們來看看如何使用這些使用者故事和功能點形成產品backlog。產品backlog是敏捷開發中用來管理需求列表，排定優先順序，形成迭代計畫，組織開發 測試和交付過程的工具。可以說，產...
敏捷開發的使用者故事怎麼寫？
以下是近期對敏捷開發中由以往 調研 文件 討論 文件 開發 文件 向新的開發方式的學習一些總結，和大家分享，有任何好的想法歡迎和我溝通。如何編寫使用者故事？1 使用者故事不要用技術語言來描述，要使用使用者可以理解的業務語言來描述 不要提及任何有關語言邏輯，資料庫，軟體，欄位的客戶無關描述。2 格式 ...
敏捷開發使用者故事系列之五 使用者故事的分類
這是敏捷開發使用者故事系列的第五篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 在之一 之二 之三中，我們曾經提到了 作為乙個 可以 以便 的使用者故事描述方式，還提到應該如何描述使用者故事，才能更好地反映客戶價值。下面請嘗試一下描述這兩個故事 1.如果把 儲存按鈕 統一放在頁面上端而非下...