關於使用者故事(User Story)的實際運用

【關於使用者故事(User Story)的實際運用】

先從敏捷宣言切入，其中

個人與互動重於流程與工具

可用的軟體重於詳盡的文件

換言之，可用的軟體是互動、討論出來的，不是由企劃獨自規劃寫出。

剛接觸敏捷的人，可能會有些誤解與想像，會以為是不是就不需要規格書就可以進行開發?

當然不是，取而代之的是"溝通"，而中間的溝通媒介就是"故事"。

講一個故事絕對比描述一個需求來的吸引人。如果使用的故事會讓人想追問為什麼，這絕對是個好故事，而這一來一往的問答，就是溝通的開始。

故事應用在軟體開發，為了能更聚焦討論，我們會以"使用者"作為起點。

以使用者的角度出發，故事就有所依據和標準界定，描繪出更貼切、更合理的情境描述。

因為，只要不合理，一下就會被質疑，他真的會想要這功能嗎?

所以，在提出這個US前，要以這角色去蒐集更多數據來佐證，加強功能的合理性與價值。

使用者故事：我是誰___(角色)，我想要_____(功能)，因為______(利益/價值)。

在使用上有沒有種經驗，雖然格式簡單，但真的實際運用卻好像渾身不對勁?不知道要怎進行?

分享我的經驗讓大家參考，有二種使用情境，

一種是，PO/企劃獨自準備好US、AC需求來跟團隊討論；另一種是，一群人的需求討論。

● PO/企劃獨自準備好US需求，準備好背景故事

可以把US當作"摘要"，拿來濃縮整個故事情境脈絡。也就是說，不能只單單寫下US，還要把上、下文表達清楚，而不是只丟一句US格式的文字，就想讓整個團隊對它非常有想法進而拆解出任務。

一句話的背後，上下文、數據、情境、流程圖、草稿圖..等，都會透過表達、呈現讓團隊知道，最後歸納出的US，會在Planning meeting時讓團隊來想像、發問、溝通、理解。

如果真的只有US一句話就給團隊，那跟許願/隕石/命令沒什麼差別。

●一群人的需求討論，拿來收斂使用

團隊會先經過大量討論和探索需求，在團隊互動過程中，可能會畫出線稿，也可能會做競品蒐集、分析與討論。團隊經過一段時間發散、共識溝通，最後的收斂就會使用US來呈現與確定先前的討論，否則需求只會停留在大家腦中的想像。

我們會使用US來確定先前討論的功能，到底有沒有價值、值不值得做。團隊成員各自用便利貼寫下US，來描述剛剛討論的那些功能。大家在書寫、沉澱過程中，透過US格式，會去更加確定這功能到底要不要。假如寫不出US格式中的價值，就要去質疑是否真的要做。

有了US之後，寫下匹配的AC，更加完整故事的架構。

回頭說明，為何分二種US的使用情境呢?

端看團隊面對的市場的VUCA程度，越是VUCA越傾向以整個團隊來探索需求，但也越花費時間成本。

※結論

- 不要試圖去把US寫詳細，因為它原本設計的用意就是拿來溝通的，寫的太詳細反而會以為都不需要討論、規格都確定且定案了。

- 寫不出使用者的價值/利益，就要思考一下到底要不要這功能，畢竟每個功能都會產生實際要做的任務，是有成本的。

- 同一個功能用不同使用者(角度)詮釋，功能會更加全面檢視。

- 使用者故事的使用者，來自於影響地圖(Impact Mapping)的WHO。如果突然冒出來新角色，不要忘記回頭檢視、調整影響地圖。

- 使用者故事可以用在流程圖、原型、示意圖的輔助說明，更能清處表達需求。

- US它不是新的寫文件方式，是拿來溝通用的，也一個非常好用的輔助思考框架。順著這格式思考，就會強化你的功能值不值得做。最後呈現給團隊成員一起檢視、溝通，拆解出要做的任務。

最後，敏捷開發沒有規格書，是用溝通、理解取代。不是真的沒有文件，而是在開發完功能後，針對成品的功能寫下說明書或操作手冊，取代在還沒開發功能就寫下詳盡的規格書。

黑先生