商業分析BA:用戶故事怎麼拆？

什麼是User Story其實我以爲要對User Story作一個定義仍是挺難的。
曾經的我覺得，所謂User Story是User來說述的Story。
你看啊，User Story的編寫範式：
As a role, I want to do something or a piece of functionality, so that I can achieve some business value or statement of intent.
可是，隨着真正的實踐，我發現，User老是一個缺席的定義者。
咱們期望User來定義User Story，而大部分狀況下是由咱們這羣BA來定義的。
我曾經和一名敏捷教練討論，咱們BA老是在臆想用戶的須要而寫User Story，這樣有意義嗎？
這名來自美國的副總裁回答我說，至少大家從用戶的角度來思考了，不是嗎？
不過，並無解答個人疑問，我也相信有不少人和我有一樣的問題：User Story究竟是從哪裏來的？誰來寫？
也有不少人認爲需求提出方應該來寫User Story，至少也應該來確認User Story是否恰當。
但實際狀況是，不少時候咱們真的只能靠想象，充分利用咱們的「同理心」來想象。
我翻了一下BABOK中對於User Story的定義：
A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
——《BABOK 3.0》
這樣看來，User Story只是用來描述能夠帶給User的價值的功能或質量需求，而非必須由User提供。
後面這段描述更加明確的指出了這點：
With a focus on stakeholder value, user stories invite exploration of the requirements by promoting additional conversations with stakeholders and grouping functional requirements for delivery.
——《BABOK 3.0》
這裏，咱們暫停一下，敲個黑板：價值。
User Story是強調給用戶帶來價值的。
OK，咱們繼續。
廣爲人知的拆分原則User Story寫起來並不複雜，可是從敏捷的小步快走的角度出發，大部分的User Story是須要進行拆分的。
而各類敏捷著做中都有寫明 User Story拆分的INVEST原則：
Independent：獨立性User Story必須高內聚，也就是擁有獨立性，不依賴於其餘User Story的實現而實現。
若是你將一個User Story拆成前臺和後臺，那確定不符合這個原則，由於這兩個Story的依賴性很是高。
Negotiable：可協商User Story並不該該是一我的的一言堂。
以前有個小夥伴問我，是否是應該由BA來寫User Story。我說，BA提供的是初稿，最終稿須要讓團隊全部相關人員達成一致。
Valuable：有價值再次敲黑板，價值！
價值是User Story的關鍵所在，這個Story若是對用戶是沒有價值的，那就須要從新拆分或者重寫。
Estimable：可評估在以前的Scrum文中，其實我提到了關於User Story的Point評估問題。
咱們必須保證User Story的可評估，由於User Story是全部實現的基礎，咱們須要根據評估的結果進行計劃、追蹤和回顧。
Small：足夠小這個原則也決定了User Story要拆得足夠小，至於要拆多小，這個我我的以爲應該由團隊協商一致，至少也應該是在一個Sprint能夠完成的程度。
我在以前的團隊裏，當評估的點數大於3的時候，咱們就必定要拆。
由於根據咱們以往的經驗，5點及以上的User Story會致使咱們的Sprint失敗，很是可能作不完或者測不完。
而拆分的過程也是一個再次思考和討論的過程，你們頗有可能會發現以前被隱藏和遺漏的地方。
Testable：可測試爲用戶帶來價值的User Story必須是能夠測試的。
請反覆讀一下我上面這句話。
之因此稱以上原則爲「廣爲人知」是由於你們都知道拆User Story的時候要遵循這些原則，可是依舊不知道要怎麼拆。
怎麼拆都怪怪的？還記得我上面敲黑板的兩個字嗎？
價值
全部User Story的拆分都要以價值爲導向，在拆完後也須要經過「這個小的User Story有給用戶帶來業務價值嗎？」來校驗是否拆的合適。
這麼說可能有點抽象。我來舉個例子。
有這麼個圖書館借閱系統的User Story：做爲一個用戶，我但願能夠找到知足條件的書籍信息，以便我能夠在書架上找到它。
這個User Story有點大，好吧，不是有點大，是很是大。
若是你拿這個User Story去和你們討論，會面臨如下問題的解答：
?這個用戶是註冊用戶，仍是訪問用戶？
?不一樣類型的用戶操做是同樣的嗎？
?所謂的「知足條件」指的是哪些條件？書名？做者？ISBN……
?要展現的書籍信息包括什麼？書名？索書號？館藏狀態？
……
因而你們討論了下，決定要拆。那這個User Story給你，你怎麼拆呢？
如下是一種拆法，拆成兩個User Story：
第一個：創建圖書信息表，裏面包括書籍的各類屬性。
第二個：按照原型，畫三個前臺界面，包括：搜索界面和搜索結果界面，以及圖書信息展現界面。
還嫌大？
那我就把第二個拆成三個，每一個界面一個User Story，夠小了吧？
有沒有以爲哪裏不對勁？
有人說，由於沒有按照User Story的格式來寫，沒有寫：做爲一個用戶，我但願能夠查看搜索界面，這樣我就能夠開始準備搜索了。
更奇怪了，是吧？
來，想一下，這些被拆出來的Story對用戶來講有業務價值嗎？
你提供一個前臺頁面給用戶，不能搜索，只能看，是準備打印出來掛到美術館裏面「供人瞻仰」去嗎？
那麼應該怎麼拆呢？
我這裏提供一個思路，你們能夠揣摩一下。
大的User Story：
做爲一個用戶，我但願能夠找到知足條件的書籍信息，以便我能夠在書架上找到它。
第一個 User Story：
做爲一個用戶，我但願能夠經過圖書名稱找到圖書的書名、做者、館藏狀態以及索書號信息，以便我能夠在書架上找到它。
第二個 User Story：
做爲一個用戶，我但願能夠經過圖書做者找到圖書的書名、做者、館藏狀態以及索書號信息，以便我能夠在書架上找到它。
或者這麼拆：
大的User Story：
做爲一個用戶，我但願能夠找到知足條件的書籍信息，以便我能夠在書架上找到它。
第一個 User Story：
做爲一個用戶，我但願能夠經過圖書名稱找到圖書的書名以及索書號信息，以便我能夠在書架上找到它。
第二個 User Story：
做爲一個用戶，我但願能夠經過圖書做者找到圖書的書名、做者、館藏狀態以及索書號信息，以便我能夠在書架上找到它。
有感受到什麼嗎？
嗯，這樣就萬事大吉了嘛？
我只能說，圖樣圖森破……
由於這裏還有一個延伸的問題，就是程序猿GG看到這樣的User Story拆分，很想打人。
爲何？
由於在代碼實現的時候，其實在作第一個User Story的時候，能夠「順手」把第二個User Story的邏輯實現了。
而若是不順手實現，那麼意味着在作第二個User Story的時候會須要改才交付完成的第一個User Story的代碼。
就好像咱們裝修房子。
以前的拆分方法是：水電進場開工、瓦工進場開工、木工進場開工、漆工進場開工、傢俱及軟裝進場。
而我後面的兩種拆分方法是：先把客廳的水電、地磚、牆面、傢俱軟裝都搞定後，再來依照這個順序搞一遍衛生間，再搞一遍臥室……
可是，看出差異了嘛？
前面的拆分方法一個工種幹完，下一個接着幹，只有當全部的都幹完了，房子才能交付。
然後面的拆分方法至少保證第一個User Story能夠交付一個完整的客廳給用戶，這對用戶來講是有價值的。
這也是敏捷的奧義所在。
可是，工人們確定不樂意了，我水管先鋪一段到客廳的，後面我還要把鋪到客廳的一部分拆了再鋪到衛生間去……
哈，也從另一面說明了敏捷方法明顯不適合工程裝修。
那麼你要怎麼說服你們接受User Story的價值導向的拆分方式呢？
關鍵在於，敏捷的另一項重要工做：重構。敏捷的開發過程其實很強調重構、自動構建等等。因此，這也是爲何我一直以爲敏捷的框架和流程是一個完整的體系。你不能拋開重構談User Story拆分，你也不能無視價值來寫User Story。
我大概花了兩三年的時間才摸索出來寫和拆User Story的感受，固然這和業務熟悉程度也有必定的關係。
我想要說的是，想要拆好User Story是須要本身不斷的去摸索的過程，沒有辦法說我今天看了一篇文章或者聽了一堂課，我就能把User Story寫好、拆好了。
重點是要親自動手去拆，去寫，去試錯。
說了這麼多，你在拆User Story的時候遇到了什麼問題？
這篇文能夠解答你的問題嗎？