敏捷系列 | 什麼是使用者故事(User Story)？
導讀：Mike Cohn的使用者故事：敏捷軟體開發應用之道第一章內容
今天與大家導讀《Mike Cohn的使用者故事：敏捷軟體開發應用之道》這本書的第一章，在讀這本書的時候，覺得作者Mike Cohn對於如何在一個軟體開發的情境中執行敏捷專案管理的概念滿有獨到見解，且也滿適合當作敏捷新手的讀物，因此想分享一下這本書的內容，希望對於大家在敏捷的道路上有所幫助。
一、什麼是使用者故事？(User Story)
作者第一章就直接破題，直接跟大家闡述他對於使用者故事的想法，如果有在進行敏捷專案的朋友，想必對於使用者故事一詞一定非常熟悉，最常見的說明使用者故事的方式應該是：「As a ….(誰), I want to….(什麼), so that….(用來解決或滿足什麼樣的需求)」
而作者Mike Cohn對於使用者故事的定義為：「使用者故事為描述對使用者或購買者具有價值的系統或軟體功能」
剛開始我看到這段的時候覺得有點文謅謅的，但作者有再進一步解釋這句話的涵義：
使用者故事可以從三個面向來構成：
- 一段書寫的故事描述，用於規劃與作為提醒
- 和故事有關的各種對話，用戶具體描述故事細節
- 各種測試，用於表達與紀錄故事細節，並可用來確認故事何時完成
假設今天有一個使用者故事是這樣撰寫：「身為一個求職者，我希望可以在求職網站上搜尋到我想要的職缺訊息」，這會是一個好的使用者故事嗎？
我們試著Mike Cohn對於使用者故事的定義來逐一檢視上面這個使用者故事。
第一點「一段書寫的故事描述，用於規劃與作為提醒」，他確實針對求職者想要有一個搜尋的功能來幫助他在求職網站上找到職缺的訊息，我們可以把這個故事的描述寫在卡片上用於規劃與提醒。
第二點「和故事有關的各種對話，用戶具體描述故事細節」，使用者在網站上找尋職缺時，可以透過用搜尋的方式來與網站進行對話，但如何找到我想要的職缺訊息好像並未詳加描述，例如：我是可以透過用職務類別的方式搜尋到我想要的職缺？，還是我可以用工作地點的方式來搜尋呢？
第三點「各種測試，用於表達與紀錄故事細節，並可用來確認故事何時完成」，上面的這個使用者故事沒有說明什麼時候要完成，以及他大概測試的方式什麼，因此很有可能他就會一直等不到實作做出來的那天。
因此我們可以把「身為一個求職者，我希望可以在求職網站上搜尋到我想要的職缺訊息」這個使用者故事改寫成：
使用者故事：身為一個求職者，我希望可以在求職網站上搜尋到我想要的職缺訊息搜尋職缺的方式為：關鍵字搜尋(模糊比對)，地點篩選、職位篩選測試方式：
1.用關鍵字搜尋的職缺結果不能有非關鍵字以外的搜尋結果，關鍵字最多為5個字元
2.若同時勾選地點篩選、職位篩選時，職缺的搜尋結果要以交集的方式呈現
3.若使用關鍵字搜尋，就不能選擇用地點篩選或職位篩選的方式搜尋職缺上線時間：預估1個sprint內完成
假如我們在sprint的需求評審會議時，開發人員認為這個使用者故事還是很難在1個sprint內完成，我們還可以再把原先的使用者故事拆解成兩個：
使用者故事A：身為一個求職者，我希望可以用「關鍵字搜尋」的方式在求職網站上搜尋到我想要的職缺訊息搜尋職缺的方式為：關鍵字搜尋(模糊比對)測試方式：用關鍵字搜尋的職缺結果不能有非關鍵字以外的搜尋結果，關鍵字最多為5個字元上線時間：預估1個sprint內完成
使用者故事B：身為一個求職者，我希望可以用「地點」或「職位」的方式在求職網站上搜尋到我想要的職缺訊息搜尋職缺的方式為：地點篩選、職位篩選測試方式：
1.若同時勾選地點篩選、職位篩選時，職缺的搜尋結果要以交集的方式呈現
2.若使用關鍵字搜尋，就不能選擇用地點篩選或職位篩選的方式搜尋職缺上線時間：預估1個sprint內完成
當然，如果我們在sprint的需求評審會議時，開發人員認為這個原本沒有做拆分的使用者故事可以有保握在1個sprint內完成，但關於搜尋職缺的方式還想再進一步確認細節的話，例如：除了關鍵字、地點篩選、職位篩選等職缺搜尋方式外，有沒有考慮新增薪資範圍，公司名稱，或刊登日期等，都可以在開發人員檢視這項使用故事上做補充或註記，讓團隊能夠更清楚知道這項使用者故事所涵蓋的需求範圍到哪個程度。
二、誰來寫使用者故事？
當我們確認玩使用者故事的撰寫方式後，再來就是誰應該要來寫使用者故事？
根據作者的描述，他認為使用者故事的撰寫者應該是客戶團隊，客戶團隊的成員會可能包含：「測試人員、產品經理、真正的使用者，以及互動設計師(UX設計師)」。
他認為使用者故事應該由客戶團隊來寫，而不是開發人員來寫主要有兩個理由：
- 每個故事都必須以商業語言，而不是技術術語來撰寫，這樣一來客戶團隊就能排定每個故事的優先等級，並將他們納入sprint中做討論
- 客戶團隊是最主要的產品構想者，因此他們最適合敘述產品特性的人
我在閱讀到這段時，覺得實務上在客戶團隊中要包含到真正使用者不是一件簡單的事情，一方面是真正的使用者的定義方式，是忠誠客戶嗎？，還是用登入次數衡量？，另一方面是在產品迭代的過程中一定都會有顆粒度大小不同的專案需求，假若每個專案需求都要去找一位真正的使用者加入，可行上也不高，因此我覺得Mike Cohn對於客戶團隊的成員想表達的是：「根據不同的專案需求大小，來配置客戶團隊的組成成員」。
假設這是一個Epic顆粒度的專案，例如新開發一套客戶關係管理系統，那客戶團隊可能就會需要包含真正的使用者(目前在執行客戶關係管理的業務單位)，邀約它們來進行用戶訪談，與我們分享並了解他們對於客戶關係管理的需求，如果他是一個Story顆粒度的專案，例如在職缺網站上讓用戶可以用關鍵字搜尋到職缺，或許就不一定要將真正的使用者放入到客戶團隊中。
三、如何評估使用者故事的開發時間？
客戶團隊完成撰寫使用者故事後，在每一次的發布規劃階段時(一個發布會由一個或是多個迭代組成)，就可以來評估這些使用者故事的開發優先序。
客戶團隊在評估優先序時，可以從三個面向來考量：
- 功能性對廣大的使用者或客戶的吸引力
- 功能性對少數特定重要的使用者或客戶的吸引力
- 故事與其他故事之間的關係。例如A故事本身的優先序不高，但如果把他與B故事(優先序)放在一起的話，會呈現互補的關係，因此A故事的優先度也會提高。
例如前面提到的用戶可以用關鍵字、地點篩選與職位篩選的方式來搜尋職缺，如果單就用職缺搜尋的彈性的角度來看上述這兩個使用者故事，地點篩選與職位篩選的需求優先度，應該不會比關鍵字搜尋的優先度來的高，但如果就使用者搜尋方式的完整度來看，關鍵字、地點篩選與職位篩選的使用者故事就同等重要了。
因此到底哪個使用者故事應該往前放，那些故事應該往後放，從不同的視角來檢視，就會出現不一樣的優先順序，因此客戶團隊與開發人員可以在發布規劃階段一同來討論並做排序。
當我們排定優先順序時，Mike Cohn有提醒可以把開發的成本一併考量，開發的成本主要是由開發人員來評估，在評估使用者故事的開發成本時，會使用故事點(Story Point)一詞來表達，很類似於人天的概念。
假如一個團隊最多在一個sprint裡面可以吃下15個故事點，當我們把我們想要在這次sprint中完成的需求排序下來的結果為：
- A項目，Story Point：3
- B項目，Story Point：3
- C項目，Story Point：5
- D項目，Story Point：2
- E項目，Story Point：4
- F項目，Story Point：2
- G項目，Story Point：5
- H項目，Story Point：6
- I項目，Story Point：2
- J項目，Story Point：4
以15個故事點為衡量基準，我們最多只能完成A、B、C、D這四個項目(3+3+5+2=13)，這樣計算下來其實還剩2個故事點可以應用，或許也可以把I項目往前移到這次sprint中來做，這樣就可以完全15個故事點的需求，但是否一定要做排序上的調整，或是讓他留一些剩餘時間做彈性應用，可以在發布規劃階段時，開發團隊與客戶團隊一起做討論，來取得一個共識。
今天與大家導讀了《Mike Cohn的使用者故事：敏捷軟體開發應用之道》的第一章，分享了關於什麼是使用者故事？，誰該寫使用者故事？，以及該如何評估使用者故事的開發時間？
下一篇將繼續與大家分享該如何辨別什麼樣的使用者故事才是一個好的使用者故事。
感謝各位朋友的支持與鼓勵!
當你／妳閱讀完這篇文章後，請依喜歡與實用程度給我1–10個拍手。
讓我能了解各位朋友寶貴的回饋意見，撰寫更優質的內容分享給你/妳!
