幾個月前，因為社群夥伴的邀約，推了在坑邊猶豫的我一把，就這樣的參與了呂毅老師兩天的 CSPO 課程。在團隊中，我算是個兼任的 Scrum Master，在幾個月前的動機僅僅是想更了解 PO 該怎麼樣更好的和團隊協作。但就在最近，因為公司計畫變更，我面臨了更多不一樣的考驗。就在這樣搞不清楚的狀況下參與了課程，我甚至不知道哪邊有問題，只是很多不太自在之處，對於需求端僅能弱弱的吐出「需求變動時怎辦？」、「這不能即時反應市場吧」、「能早點做出 MVP 開始賺錢嗎？」、...。
經過這次課程洗禮，我不知道為什麼，好像突然茅塞頓開，一切都疏通了。但其實課程中並沒有特定的章節可以直接解答我的狀況，只是好像一切都串連起來了，問題清晰了，也甚至有解答冒出來了。（以下還不會談到我想通了些什麼，希望日後經過實際案例的檢驗，再行分享。）
團隊其實也 run 了 Scrum 一年半以上，我也上過些關於 Scrum 的課程，對於 Scrum 已有基礎的認識。課程中對於 Scrum 架構的教學，對我來說更像是健檢，試圖尋找那些我們自創的 Scrum 「BUT」。找到的「BUT」 不多，找到的是更多的啟發，讓我更能以終為始的好好思考 Agile Manifesto 及 Scrum 每個 practice 背後所代表的意義：
- 所謂的年度預算（計畫），更應該解釋為可以承受的風險。
- PM ≠ PO，不要再使用「合約」協作，更多的是直接透過參與團隊來進行合作。
- Story 必須依據價值排序。但倘若因為必須搭配硬體，N 個 sprint 之後才能交付到使用者手中，那這「價值」的定義似乎就有點不同。前幾個 sprint 交付的不見得是對使用者價值最高的，或許是風險最大的、需要外部資源的。
- Story 的 template，更大的意義是在作為交流、溝通的一個 format，別只關注在文字撰寫的格式上。
- Story 的 Role，表示的是對應系統的角色，而不是針對目前開發所遇到的「故事」角色，將此角色抽象一層，可以減少不必要的「噪音」。
例如：「企劃人員」可以透過總覽頁面查詢產品資訊。=> 「產品資訊查詢者」可以透過總覽頁面查詢產品資訊。 - Product Backlog 中已交付、完成的 Story，並不會持續被維護，該 Story 在交付前的狀態對於該 sprint 更具意義，不要試圖從茫茫的 Story 遺跡中找出產品目前的「規格」，建構一個 Baseline document 或許更為合適（當然更高招的是建立 Living Document）。
- 除了 Sprint Plan 之外，在產品開發初期，應該進行 Release Plan，並訂定 Goal，讓團隊共享這個認知。
