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

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

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

用戶故事的主要問題

---

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

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

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

用戶故事的需求整理方式與傳統需求的整理方式有很大的不一樣，傳統軟件開發中咱們依賴用戶需求，技術需求，規格說明書等工具試圖使用規範的文檔來解決需求收集和傳遞的問題。在這個過程當中，咱們將用戶的需求轉換成技術能夠理解並可實施的規格。對於已經習慣了這種方式的人來講，要轉換成使用用戶故事的方式須要比較大的思惟方式轉變，你們每每遇到的疑問也是，難道使用用戶故事就不須要規格了嗎？其實否則，首先咱們要了解用戶故事究竟是什麼。

用戶故事究竟是什麼？

---

你們可能以爲既然咱們使用用戶故事來替代傳統需求，那麼用戶故事就是記錄需求的方式了。其實，用戶故事不是用來編寫的，而是用來討論和跟蹤的。

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

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

故事講給誰？

---

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

你的故事是講給這裏面每一個人聽的，同時也但願每一個人都可以在講故事的時候有所輸入，不只僅是在聽。

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

怎樣講故事？

---

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

找線索 – 畫出故事的主角

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

這裏咱們能夠藉助2個工具來協助找線索：影響地圖和用戶畫像

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

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

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

你會發現，當團隊開始整理不一樣的類型的用戶的時候，他們已經開始天然的講述故事，由於要把一個角色說清楚，你就必須考慮他要作的事情，故事天然就出來了。可是在這個階段，咱們切記不要過於發散，明確咱們的目的是整理用戶畫像，只要不一樣用戶類型間的邊界清晰了，就能夠結束，不要爲細節糾纏。另外，在後續的過程當中咱們也會發現可能有些角色還須要添加進去，那麼就到時候說。

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

通常我會按照距離最終用戶的遠近來擺放這些即時貼，同時對每一個角色進行編號，以便後續能夠很容易的進行引用。

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

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

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

• WHY：咱們這個用戶故事是什麼？爲何咱們要作這個故事？
• WHO：這個故事裏面都有哪些角色？
• HOW/WHAT：這些用戶爲了完成這個故事，須要作些什麼，怎樣操做？

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

如上圖：是一個標準的「新用戶註冊」的用戶故事，你們必定都很是熟悉。基本上這個故事就是瀏覽者經過 登陸->註冊->填寫信息->驗證郵件提交註冊，管理員審覈，成爲已註冊用戶後首次登陸->完善資料。但經過卡片的方式將每一個步驟放入白板後你會發現，整個團隊能夠很好的聚焦到很細節的問題上，同時又對整個故事具有全局觀。若是不借助這種可視化方式，那麼團隊可能很容易丟失當前討論的主線，從一個細節延展開到其餘的部分去了。

注意這裏對每一個用戶故事進行了ID標註，一樣也是爲了後續能夠容易進行引用。

你可能會問，那我用個思惟導圖一類的工具不是更好麼？電子化工具的好處是對信息的保存和分享方便，可是在團隊討論中，咱們更加劇視團隊討論的氛圍，聚焦和總體效率，若是使用電子化工具，就沒法讓每一個人均可以同時對這張圖進行操做，而必須由一我的操做，其餘人很容易走神，若是工具不熟練還會耽誤時間。因此看上白板是個很Low的工具，其實對於團隊討論來講，它的效率高於任何的電子化工具。

如上圖：這是我做爲敏捷教練參與的一次用戶故事討論，你能夠看到你們都彙集在白板周圍，整個討論都是站立進行，任何人均可以隨時發表意見，用手指着某個即時貼就能夠開始說：「這個」步驟怎樣怎樣。若是沒有可視化工具，或者使用電子化工具，但願每一個人均可以用「這個」來聚焦全部人的注意力是很困難的，你可能須要解釋「這個」究竟是什麼，又或者須要在電子工具中鼠標來點，若是操做者不是講解者，那會更加麻煩。細節決定效率！

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

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

• 敏捷開發重視的是文檔產生的過程，但願經過透明化的過程和集體討論來確保內容的完整性和信息在過程當中的傳遞。對於文檔自己的格式卻是沒有具體的要求，只要確保討論中的內容都被記錄就能夠。
  – 敏捷開發中的文檔並非用來傳遞需求的主體，人才是傳遞需求的主體。
• 敏捷開發的文檔是一份活的文檔，因此咱們更但願經過系統來記錄需求，而不是傳統的word或者excel等靜態文檔來記錄。這些文檔的做用是幫助團隊成員來回憶和講述，同時也做爲過程追蹤的手段。
• 傳統軟件開發中每每有2份項目計劃，一份列出需求並在需求上進行估算以便推導出預算；另一份是時間和資源計劃，這份計劃又每每是按照階段來進行規劃的。敏捷開發只有一份項目計劃，就是按照用戶故事來組織時間，資源和各個階段的跟蹤 – 這其實就是用戶故事驅動的敏捷開發的含義。

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

這個過程當中，咱們但願綜合考慮架構和測試的輸入，這兩個角色須要從本身的角度確保每一個故事的分解都知足架構的要求，而且是能夠進行測試的。因爲每一個用戶故事都會穿越多個功能區域，架構師必須協助團隊確保架構的擴展性，複用性以及性能等要求。對於測試來講，要確保每一個用戶故事都是可測試的才能確保後續的測試計劃和用例能夠配合團隊的開發過程，並按照故事逐個交付給用戶。

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

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

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

如何組織需求討論會

---

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

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

針對需求討論會，咱們至少須要有如下安排

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

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

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

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

 

 

---

請關注微信公衆號 【devopshub】，獲取更多關於DevOps研發運維一體化的信息

​