相信我這天一定會來臨，當你們遇到人生重要關卡時，你永遠不會覺得自己是『準備妥當』的。但其實，你根本就不需要準備妥當。因為你在意外中可以找到希望、在挑戰中找到勇氣、在孤獨的道路中能找到願景。 -- 蘋果CEO庫克

PM視角：
依照之前規畫的甘特圖，到今天應該畫面要出來一半，系統、情境應該都要完成了。

但是……

並沒有!!

我沒有空去管工程師設計的功能之後會不會用到，這很可能會重工。
想不出來完整的方案，總覺得缺了什麼……
但是時程不能再delay了，必須要有東西出來。
這時我能想到的，只有把任務再細分，才有可能達成。

使用者故事

使用者故事，通常是用來了解產品、專案初期需求的工具，大致上的流程如下：
As a ______, I want to ______, so that ______.
身為 ______，我需要一個方法來 ______，因為 ______。
和前面提到的設計思考相比，他是用角色與價值、會遇到的可能情怳來發掘需求。
優點是能從這些故事中截取需求，並細分為一個一個的任務。
當然，也會有缺點的，其中一種可能的缺點，就是如果你假設的情況與實際有出入，可能反而和使用者需求完全不同。
而我現在需要的，則是他拆分任務的功能。

拆分 User Story

• 用「SPIDR 法」將使用者故事細分成不同條件的描述。
  SPIDR 法：
  1.Spikes: 分階段的去拆解一個任務。(例如：開發、測試、上線)
  2.Paths: 用不同的使用條件來看能不能完成。
  3.Interfaces: 在不同平台及環境的狀態。
  4.Data: 用資料的來源或類型區分。
  5.Rules: 查看在同一條件下，不同邏輯的表現(時間區間，以週或以年為單位、使用者登入，是有綁定還是訪客)。

實際拆解

以我的產品來說，使用者故事會是這樣的：
使用者，想從玩我的遊戲中，獲得最大的成就感。

• 試著加入企畫，描述一下情境：

1. 固拉多從google play上下載了「30天煉成」這款遊戲，他很好奇能在這遊戲中得到什麼樣的成就感。
2. 打開遊戲後，映入眼簾的是遊戲的登入畫面。在這裡，有著動態的主畫面及開始的按鈕，還可以調整設定。
3. 最一開始是新手教學的環節，並報名第一次的煉成。
4. 過程中會有固定事件及夥件隨機事件的發生，對練成中的角色會造成不同的數值及效果影響。
5. 一輪煉成共會有三十個回合，每一回合在事件結束後，都要想辨法寫出文章。
6. 如果有一回合沒有寫出文章，就會煉成失敗，煉成成功有多種結局呈現，是收集要素的一環。
7. 煉出的角色能在放置中得到資源，資源可以用來強化夥伴卡，讓下一次煉成的更好。
8. 其中不論數值還是遊戲進度，都會有大量的成就可以領取(虛寶、數質、獎牌、里程碑)。
9. 能和好友一起刷活動。
10. 跨平台的特性讓這遊戲能讓更多的人一起遊玩。
    固拉多獲得了成就感的滿足，他終於找到屬於他的遊戲了。

補足了很多細節，但沒有畫面、沒有細節，
這樣的幻想只會讓工程師難做事。

• 試著拆分成階段性任務吧。

1. 首要平台為google play，先成為該平台開發者(已完成)，並創立商店(Interfaces拆分)
2. 一開始的畫面只要登入、主頁、故事能正常運作即可(Paths拆分)
3. 正式前先都用「訪客」身份遊戲即可(Spikes拆分)
4. 完成登入、主頁後，故事部份先不加數值影響，確定每一個小遊戲(寫文章)能正常運作(Rules拆分)
5. 最重要的成就系統，先確定數值與獎碑能正確呈現(Data拆分)

通過拆分，我們知道，設計只要先能出來前面的畫面，工程師就能先用原本的Flutter串起架構，
之後才進入遊戲的部份。依照這些條件，每天的工作分配及進度要求就會比較好掌控了。

今日需完成工項：

1. Google play上架準備 - 開專案
2. 登入、主頁視覺設計 - 用Figma進行
3. 將前幾天的練習Widget化，並變回用MaterialApp串連框架及訪問

參考
產品管理流程中，使用者故事（User Story）常見的三種使用情境
編寫有效的用戶故事 (user stories)
如何寫一個「User Story」
以「蜘蛛法」拆分過於龐大的 User Story
Scrum: Sprint循環8個步驟