User Story 是一種新的敘述方式，強調透過簡單的語境，具體描述產品在「使用者」的手上，怎麼樣被「操作」。
這裡是一些 User Stories 的範例：
大骨架
- 使用者可以在網站上張貼履歷，以達到履歷曝光的效果。
- 使用者可以搜尋有哪些工作，以提升檢索效率。
- 公司可以張貼新工作，以曝光職缺。
- 使用者可以限制誰可以看到他的履歷，以避免被前東家發現要跳槽。
一口吃的大小
- 廣告可以單獨設定溢價比例。
- 寫一支機器人程式，每五分鐘抓取一次 CoinMarketcap 上綜合價格並存取在資料庫。
- 全站每5分鐘更新價格，並刷新列表。
- 把溢價比例與全站價格做連動。
User Story 的訣竅：
- 控制難度，控制角色複雜度。
- 在非常早期，就找出真正有價值的功能，其餘儘量捨棄或變通。
- 點出地圖上的終點，讓團隊第一時間都知道最終要蓋出什麼。
- 平行開發，沒有誰擋誰的進度。
- 每個人都喜歡一口氣「破關」的感覺，把任務切到可以「一口吃」的大小。
一般來說，User Story 寫到第五版。大致上的骨架就會出來。
- 大骨架在完稿時大概會是20條上下的主要框架。
- 中骨架是在大骨架下繼續展開的 Must Have 功能，展開後大概會有100條。
- 這100條裡面有更小的細節，最後擴展最終會達到大致1000條左右的規模。
我們會在大骨架完稿後，先做一版流程圖，確定業務邏輯方向不會被這些細節分散。
白話來說，維持在主線，就不至於「過度開發」。
舊方法：瀑布式開發
先蒐集完備規格，然後再開工
問題是：「仔細規劃，完美執行上線」，存在的機率非常渺茫。
假設一個產品需要六個月，以下是最常出現的時程：
- 花了3、4個月訪談需求。
- 花1個月請美術設計視覺與介面，以及反覆修改。
- 最後，剩下不到兩周再請RD 進場寫程式。