敏捷觀念 - 使用者故事User Story

【敏捷觀念 - 使用者故事User Story】

前一陣子替團隊整理了一下，關於User Story的觀念釐清，不小心就做了一百張簡報。
參考網站  Ruddy Lee、使用者故事對照、如何寫出 User Story、不可或缺的精益、敏捷需求實踐....，網路上資料很多，但也相對零散，所以需要的話，可以去上CSPO的課程，會有較系統性的資訊，或者去上相關課程也能讓觀念較為完整!

這次主要在做的事，是針對團隊狀況過濾訊息，依團隊目前狀態需要的資訊做系統性整理，大原則就是「夠用就好」。

既然取之於社會(網路)，那我也就用之於社會，回饋一下內容。

簡報內容大致如下：

先講結論，敏捷對於VUCA環境的適應性很大，所以，要跑敏捷前，請先確定好，你們是真的在VUCA環境，而不是為了潮而跑。否則，也只是會精通錯誤的技巧和觀念而已。
先確定好自己目前狀態位置是否適合。沒問題也認同的話，我們再來重新定義一下，對於User Story的想像一不一樣。

請記得一件事，聽一則好故事，是需要時間的。相同的，專案沒有足夠的討論時間與空間，就別太糾結一定要用"使用者故事"。適當的情況下，用正確的規格描述，做出同等價值的產品，這才是敏捷阿!

要用對故事和用對方法，不然它也是會變成隕石的可能。

既然是"故事"，我們就先來看場微電影吧!了解一下，什麼叫故事 - 阿嬤的衛生紙，
如果要拆解這故事，我們會用哪些方法來寫劇本呢?

大多數的人在說使用者故事的時候，會卡卡或不踏實的原因，是因為使用者故事本身就是一種抽像的描述，是拿來討論的，也必需是開放思考的描述。但忘了先給這個故事一個情境，
讓它還是在焦點內做發散討論。有時也沒給上下文的想像空間，造成做出來的功能不符，如果最後還沒討論，那就更慘了。

講故事前，請先把構想描繪出來(故事全貌)。

沒錯，就是用影響地圖(Impact Mapping)、使用者故事地圖(User Story Mapping)來做故事情境與上下文。

影響地圖：透過視覺化的方式，建立商業目標與產品功能的關係，以及背後關聯的假設。
使用者故事地圖：透過視覺化的方式，建立使用者場景與技術規格間的聯繫，輔助團隊有效溝通。

那.....

使用者故事
5C原則：Card、Conversation、Consequence、Confirmation、Construction
四個基本要件：抬頭、故事、場景、註釋

技巧：畫面、使用者故事+流程圖、實例化需求、驗收標準(Acceptance Criteria)、INVEST原則、DEEP特性、目標
避免：異想天開、身份不明確、太過詳細、已有解決方案
鼓勵人人參與設計、鼓勵延後細節

【結論】
不管是故事還是規格書，只要用對產生價值，都是好方法，沒有誰比較好或比較高級，也沒有規定用敏捷就一定要用User Story，只是提供另一種選項。
所以，還是要回頭檢視一下，目前所在團隊狀況、專案性質與壓力、成員能力...等因素，做些平衡取捨，讓產品以最高價值的狀態產出，才是最終目的。

提供團隊成員上課後的心得回饋。
1.今天一個新的發現是什麼?
2.我們今天學習到什麼?未來可以應用在哪個地方?
●User Story的重點，是在引導後續的討論&抽象化原則
●目前專案不適合用完全的敏捷，但可取部份方法。未來可用在從無到有的專案
●需求探索的好方法-藉由影響地圖建立探索
●共識才是敏捷核心。加深敏捷觀念，期望未來能應用
●方法是多樣的，可以擇自己需要的使用
●抽像的描述利用場景，讓相關人員共同討論，幫助了解真正的需求
●系統化的圖像或可視化的影響地圖與使用者場景，是個很好的工具
●建立User Story未來可用於未知產品的開發上
●新產品可以使用，並且以集合大家智慧為優先
●再次複習User Story相官的結構與存在目的與意義
●User Story的精神與目前專案狀況有很大差異
●User Story寫法。應用在新需求討論上。

另一種使用者故事運用，群體需求探索確認：https://cunnyyun.blogspot.com/2020/05/user-story.html

黑先生：https://www.facebook.com/Mr.Black.AgileLife