用戶故事驅動的敏捷開發 – 1. 規劃篇

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

今天想跟大家分享的是用戶故事的計劃進程，對如何使用用戶故事驅動團隊的開發進程，后續會有更新。

用戶故事的主要問題

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

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

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

用戶故事的需求整理方式與傳統需求的整理方式有很大的不同，傳統軟件開發中我們依賴用戶需求，技術需求，規格說明書等工具試圖使用規范的文檔來解決需求搜集和傳遞的問題。在這個進程中，我們將用戶的需求轉換成技術可以理解并可實行的規格。對已習慣了這類方式的人來講，要轉換成使用用戶故事的方式需要比較大的思惟方式轉變，大家常常遇到的疑問也是，難道使用用戶故事就不需要規格了嗎？其實不然，首先我們要了解用戶故事究竟是甚么。

用戶故事究竟是甚么？

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

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

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

故事講給誰？

在真正開始將故事之前，我們首先要確保正確人都參與進來。對計劃1款產品來講，你最少需要：終究用戶代表，產品經理（或類似Scrum中的PO），項目經理（或類似Scrum中的ScrumMaster），團隊中的技術骨干（那些對實現的業務很熟習，對所要使用的技術或系統很熟習的技術人員），技術骨干又可以分成架構，開發和測試3個不同技能的人。這樣看來，你最少需要6個人參與這個講故事的進程（除非有些人可以相互替換）。

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

• 終究用戶代表：這些人1般會作為講故事的主角，由于他們是最了解故事的人。但是終究用戶代表只能用用戶的角度來描寫故事，這里會缺失很多技術細節。當他們開始講故事的時候，技術人員就需要補充這些細節，將那些從用戶角度看上去可能很簡單的故事后面所觸及到的復雜度暴露出來。
• 產品經理和項目經理：這兩名成員基本起到調和人的作用，1般產品經理（PO）偏向用戶，項目經理（ScrumMaster）偏向團隊。我們希望他們的這類偏向性能夠在討論進程中體現出來，將故事的優先級，重要程度，實現難度等問題進行歸納總結，構成我們的項目計劃。同時，這個故事討論的進程1般都是以會議情勢進行，這2個人應當作為會議的組織者（主持人）出現，引導團隊高效的完成討論進程。
• 技術骨干：首先技術人員要明確自己也是主角，而不單單是旁聽。很多人都有這樣的體會，明明很簡單的1個功能，為啥做起來會那末慢？這里面有2個緣由，第1個是用戶自己就沒有吧這個所謂的“簡單”功能想明白；第2個是1個對用戶“簡單”的功能，對技術來講恐怕沒有那末簡單，但這個信息1般很難跟用戶講明白，所以很多技術就偏向于不說或說的很少。結果就是雙方對難度的認知不1致。技術骨干參與這個講故事的進程的目的，主要就是為了幫助用戶從技術實現的角度理解故事，同時自己也能夠將技術實現的思路想明白。

怎樣講故事？

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

找線索 – 畫出故事的主角

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

這里我們可以借助2個工具來協助找線索：影響地圖和用戶畫像

關于影響地圖：【Impact Mapping 影響地圖 讀書與演練心得】

TODO: 完善使用影響地圖找出故事主角的進程

關于用戶畫像
http://www.zhihu.com/topic/19647591
http://cdc.tencent.com/?p=4898

你會發現，當團隊開始整理不同的類型的用戶的時候，他們已開始自然的講述故事，由于要把1個角色說清楚，你就必須斟酌他要做的事情，故事自然就出來了。但是在這個階段，我們切記不要過于發散，明確我們的目的是整理用戶畫像，只要不同用戶類型間的邊界清晰了，就能夠結束，不要為細節糾纏。另外，在后續的進程中我們也會發現可能有些角色還需要添加進去，那末就到時候說。

終究將我們整理出的每一個用戶類型用1張即時貼粘在白板的最左邊，以下圖：

1般我會依照距離終究用戶的遠近來擺放這些即時貼，同時對每一個角色進行編號，以便后續可以很容易的進行援用。

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

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

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

• WHY：我們這個用戶故事是甚么？為何我們要做這個故事？
• WHO：這個故事里面都有哪些角色？
• HOW/WHAT：這些用戶為了完成這個故事，需要做些甚么，怎樣操作？

請參考：【影響地圖中HOW的理解與對照】

如上圖：是1個標準的“新用戶注冊”的用戶故事，大家1定都非常熟習。基本上這個故事就是閱讀者通過 登錄->注冊->填寫信息->驗證郵件提交注冊，管理員審核，成為已注冊用戶后首次登錄->完善資料。但通過卡片的方式將每一個步驟放入白板后你會發現，全部團隊可以很好的聚焦到很細節的問題上，同時又對全部故事具有全局觀。如果不借助這類可視化方式，那末團隊可能很容易丟失當前討論的主線，從1個細節延展開到其他的部份去了。

注意這里對每一個用戶故事進行了ID標注，一樣也是為了后續可以容易進行援用。

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

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

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

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

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

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

這個進程中，我們希望綜合斟酌架構和測試的輸入，這兩個角色需要從自己的角度確保每一個故事的分解都滿足架構的要求，并且是可以進行測試的。由于每一個用戶故事都會穿越多個功能區域，架構師必須協助團隊確保架構的擴大性，復用性和性能等要求。對測試來講，要確保每一個用戶故事都是可測試的才能確保后續的測試計劃和用例可以配合團隊的開發進程，并依照故事逐一交付給用戶。

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

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

關于用戶故事地圖：【用戶故事地圖(User Story Mapping)之初體驗】
注：這篇文章對地圖頂層的解釋稍有不同，這是我當時對用戶故事地圖的理解還不深入釀成的。

如何組織需求討論會

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

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

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

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

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

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

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

請關注微信公眾號 【devopshub】，獲得更多關于DevOps研發運維1體化的信息

?

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈