「User Storying Mapping」讀書筆記 (9)

Ch 16. Refine, Define, and Build, Ch 17. Stories Are Actually
Like Asteroids & Ch 18. Learn from Everything You Build

定義問題並確認我們想開發的產品

前章講過，我們寫卡片是為了開啟對話，讓大家有更多的討論，並排出優先順序，哪些是比較有機會發展，哪些則是無關緊要的點子，我們把這些重要的故事收集起來，放入庫存清單之後，也要開始仔細想想，我們的產品究竟可能長怎樣。

我們會有一個工作坊，去順理流程和功能。參與者包含工程師、設計師、商業分析師、QA 測試者等。我們會確認使用者是誰？我們的產品怎麼解決他們的問題？為什麼要這樣做，對公司有什麼好處？要怎麼做？另外會確認適合開發大小的故事。

成員三到五人是適合討論的數量，太多人，反而大家比較不易合作，可能容易分心什麼的。但是外圍可以有不能說話的觀察者，當外圍的觀察者想說話的時候，就必須與內圍的人交換，這樣可以確保討論聚焦且更有產出，這個方法稱作「Fish Bowl Style Collaboration」。

就像第八章講過的，我們要把大故事，切分成易於開發的小故事，分成三個階段。第一階段只強調基本功能面，功能足夠可以幫助使用者解決問題，第二階段則是想辦法讓產品更好，第三階段則是我們想像產品最佳的樣子。就像前面提過，就像畫畫，會慢慢一層一層加上去，當你做完第一階段，也有可能原先規劃的第二階段可能要調整，因為第一階段完成後，使用者試用後，可能會和你原先預想的不同。

故事地圖的便利貼可以幫助我們切分開發階段外，也可以用來追蹤開發進度。我們可以用三種不同顏色的小圓貼，代表目前這個小故事是否完成，綠色代表完成，黃色代表正在實作中，橘色是計畫在下一個迭代實作。

故事地圖也讓我們容易理解整個開發的全貌，不會只看到目前開發的幾個功能，然後有點迷失，不知道我們最後產品大概的樣子是什麼。

切分並整合開發清單

其實故事就像一款很紅的機台遊戲「Asteroids」，打隕石的遊戲。大故事就像大隕石，移動速度慢，中隕石移動速度快，而小隕石移動速度最快，但破壞力也很強。很多人在開發小功能、調整小細節時候，就會抱怨看不到全貌。

在每個故事討論階段，就會有不同目的：

1. 機會：你會討論我們會誰設計？他們的問題是？他們和我們的商業策略有什麼關聯性？

2. 發現：會更具體誰會使用我們的產品？為什麼使用？以及如何使用？會確保產品是有價值、易用的以及有可實現性。在這個階段，就會把大故事切分成小故事，然後找出最小可行性產品，放入發布庫存清單內。

3. 計畫開發策略：會討論我們會有什麼風險？使用者會喜歡和採用嗎？技術可行性風險？我們想要利用這個先期產品的測試，學到什麼東西？怎樣的東西可以讓我們學到最多東西？

4. 計畫下一輪的開發：確認要開發的東西，還有怎樣才算完成開發的標準，大家都達成共識。

開發清單，其實也需要整理，有些太零碎的可以整合，有些好像重複的，可以刪除。

從過程中學習

當結束前一輪的開發時，我們需要反思上一輪的開發過程，包含產品面、規劃面與整個過程。

開發團隊

我們先從個人的檢討開始：

產品本身

• 使用者經驗的品質：介面和流程，給予 1–5 的評分。
• 功能面的品質：運作有沒有順暢？有沒有很多 Bug？給予 1–5 的評分。
• 程式的品質：程式是否容易維護和成長？給予 1–5 的評分。

開發進度

• 哪些故事已完成，哪些故事未完成。完成到哪裡？測試過了嗎？
• 你同意要完成的故事數量
• 未完成的故事數量
• 討論時間預估與運用

開發流程

• 討論前一輪決定改變的方式，在這一輪成果如何？是否能幫助整個開發流程？要保留還是要放棄這個方式？
• 在下一輪想要做的改變是什麼？

完成自評表後，再和開發團隊一起討論。

關係利益人

接下來可以在與組織內的其他利益關係人，一起檢視產品。

發現

• 簡單討論我們之前已經決定採用的機會點：為誰而做？我們為什麼要建造它？看到怎樣的成果，產品算成功？
• 討論和展示為了更加瞭解這個問題和解決方案，目前我們已經做的事。
• 討論和展示已做的原型與試驗。討論顧客和使用者對於這個解決方案，說了什麼。

遞交

• 針對每一個解決方案，檢視解決方案的目標顧客、使用者和成果。為什麼我們要建造這個？怎樣算成功？
• 討論並展示針對每個解決方案的故事結果。利益關係人可能會在此時給予回饋。
• 更全面的討論故事，告訴關係利益人，為什麼現在產品長這樣，因為我們可能才做到第一階段，後面還有二三階段，把產品慢慢修正到完整。
• 告知目前進度以及之後會做哪些事。

使用者

當我們產品一次一次發佈更新，有足夠的功能，讓使用者可以完成他們基本的需求時。我們可以藉由不同的研究方法，去看我們的產品是否存在任何問題。每一次迭代時，我們可以：

• 在產品裡埋點，可以追蹤新功能的使用情況。
• 安排時間，去觀察使用者怎麼使用新的功能。

準時發布才是王道

請記得：

• 軟體從來沒有做完的一天（Software is never really done.）
• 成果是無法被保證的（Outcomes are never insured.）
• 在產品發佈之後所做的改進是最有價值的（Improvements made after release are the most valuable.）

當時間接近預先承諾要發佈時間，這時候要評估每一個使用者主活動的完整度到哪。可能有 A+, A, A-, B+, B, B-, C+, C, C-, D+, D, D-，完整度低的，例如只到 D，你可以會想剩下的時間，把這個活動進度趕上，可能做到 B 的完整度即可。或是很多個在 C，你可以想他們都趕到進度 B，只把 D 那個移到下個版本發佈。