用戶故事驅動的敏捷開發 – 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

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

最終將我們整理出的每個用戶類型用一張即時貼粘在白板的最左側,如下圖:

319097120849371345

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

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

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

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

  • WHY:我們這個用戶故事是什么?為什么我們要做這個故事?
  • WHO:這個故事里面都有哪些角色?
  • HOW/WHAT:這些用戶為了完成這個故事,需要做些什么,怎樣操作?

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

446557478620373757

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

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

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

userstory-impactmapping

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

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

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

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

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

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

146238159438701057

如上圖,將以上用戶登錄這個故事分解為功能點,展示在用戶故事地圖上,這是標准的用戶故事地圖格式:

  • 最上面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研發運維一體化的信息

qrcode_for_gh_b7c158df1fd1_430


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com