2018-10-26(五) 呂毅 CSPO Day2
以終為始
終於來到這 4 天 CSM + CSPO 課程的最後一天心得+筆記了
現在時間是 2018-10-28(日) 的晚餐時間 - 19:00
距離 Day4 的 CSPO 課程已經過去整整 2 天了…
或許有人在想… 阿不是 承諾 要每天交付？ 拖延無極限？
其實我是想在完成 4 天文章的同時
也交付我在 Day1 就想完成的 Markdown Blog
前情提要：呂毅 CSM Day1
因為這個 目標 …
我其實整整 2 天都在搞 Hugo 的 Blog 架站及研究 (踩雷)
詳細的研究 (踩雷) 經過, 我想就留到之後再撰寫吧…
畢竟這次的 目標內容 還是要以 CSM + CSPO 課程為主
但至少現在看到這個頁面的呈現, 也代表我自己堅持了 目標(Goal)
以終為始, 持續交付, 回饋改善, 品質要定下來
Scope 與 Time 之間的 Trade-off
CSPO 最後一天的課程, 一開始就先放了下面這近 16min 的影片
Agile Product Ownership
其中有幾個重要的點是之前沒有提到過的
No is the most important word for PO
- 這裡說的 No 當然不是要 PO 跟 Team 說 No
- 這裡說的 No 是要 PO 有勇氣跟 不那麼重要的工作 說 No
- 因為這不是一件簡單的事, 所以這件事會是 PO 跟 Team 一起協作
Backlog Grooming
- Estimating the Value of Story, Size, Prority, Split
- 估計工作的 價值, 大小, 排序, 跟拆解
- 其實這個詞就是 Backlog Refinement 的前身, 名詞上的不同而已
- Grooming, Refinement 或稱 精煉 或稱 疏理
- 這個會議的重點, 就我自己來看
- 是分擔 Sprint Planning 的負擔, 避免 Sprint Planning 時間過長
- 是讓 PO 跟 Team 一起對於 目標 的多方發想與聚焦收斂
- 這個會議 PO 可以使用的技巧主要有 2 個
- Impact Mapping 跟 User Story Mapping
- 主要確保 PO 跟 Team 的目標是一致的
- 唯有目標一致, 後續才能在目標一致的前提下專注於細項工作
Business Agility
- 商業… 敏捷？
- Value = Knowledge Value + Customer Value
- 價值 = 知識價值 + 客戶價值
- 兩者間的 Trade-Off
- 一開始先做風險高或是技術不確定性高的工作
- 初期會慢, 但中後期會因為初期的投資而快起來
- 末期如果已經達到大部分的客戶價值, 就切吧！
Burnup Chart
- 黑人問號？？？ 不是 Burndown Chart 嗎？
- 影片結束後問問老師, 老師說只是表達方式的不一樣
- 由上而下, 分別代表不同情境
- 固定範圍： Fixed Scope
- 固定時間： Fixed Time
- 固定範圍+時間：Fixed Scope & Fixed Time
Burnup
Burndown
其實不管 Burnup 或是 Burndown
都是基於 經驗法則 來因應被問時程或是範圍上的 可完成度 時
能夠大略給出來的一個 初步預估 與 雙方協調
如何先少投入一點, 但卻可以驗證效果？
其實這個答案很簡單： 收集 Feedback
收集 Feedback 的方式可以有很多種方法
老師簡單用一個例子說明
就像我今天打算開 CSM 跟 CSPO 的課程
但是其實我在 2 個多月前只將課程的 Agenda 擬定出來
但我就將開課資訊給了出去, 這 2 個月之中再慢慢的將課程內容完善
我這種先放消息的方式, 就是想要先收到 Feedback 看看報名的情況
如果我將課程完全準備好才放出開課的課程, 結果到了那時候都沒有人報名
這樣我這些埋頭苦幹準備內容不就是白費了嗎？
那們你們做產品也是一樣
為什麼一定要做到那麼完善才要放到市場上運行呢？
如果你準備了一整大包的功能
最後才發現你花了大部分時間做出來的功能都沒有人在用
你不是會很挫敗嗎？
User Story 強調的是 溝通
這個階段, 老師主要用一個 10 分鐘的小活動
就完全讓我們了解到 溝通 的重要性！
Specification Game
一張紙上有簡單的圖案
只能用寫字的方式 3 人合作, 將描述寫下
另外 2 人看著描述的內容, 要將簡單圖案畫出來～
That’s All～ 感覺跟你工作中的 Spec 有 87% 像吧～
真正身體力行用身體感受, 你才會知道這件事情有多麽荒謬阿～
如果能夠直接面對面溝通？ 你為什麼不呢？
所以說, 那些什麼 User Story Template 也是這樣
這些 Template 只是給你一個基本規章比較好撰寫
但不代表你就只需要照著 Template 寫, 一切問題就解決了啊啊啊～～～
As a …
I Want To…
So That I can…
身為一個 …
我想要 …
因此我可以 …
看著下面的語句, 你照著它寫出你的一個個需求, 然後全部事情都迎刃而解？？？
Impact Mapping & User Story Mapping
這 2 個都是給 PO 在 PBR (Product Backlog Refinement) 的好工具
其實這 2 個工具方法並沒有一個一定要什麼特定情境使用特定工具
但如果真的要整理一些大原則, 我初步的認識是這樣
Impact Mapping
針對 特定目標(Goal) 的發想與聚焦
User Story Mapping
針對 某次發佈(Release) 的發想與聚焦
然而有一點是需要特別注意的！
這些過程都是 PO + Team 一起發想與收斂的
不是叫 PO 自己一人埋頭苦幹生出這些東西
這就是為什麼上面說到 PBR 是 PO 跟 Team 共同參與
並且經由這個過程大家才能更凝聚更目標一致的努力
參考文章： 1. Impact Mapping 2. User Story Mapping
Spec By Example (SBE)
不是問, 而是講！
大部分人看到 SBE 直覺上可能馬上會聯想到 GIVEN WHEN THEN
但其實老師有說到
這不是一個, 而是一組的 Spec
什麼意思？
意思是內容沒有對錯, 主要是讓大家達成共識
還是不懂？ 那就看看下面這個沒有明確達成共識的例子
請問一下我出去玩, 週二入住, 週五退房
都幾？
所以 SBE 的目的就是利用 一組的 Spec
來讓溝通雙方的不確定性與變動性降低
進而讓 溝通 上是更有效率且明確的！
Quality, 為了快, 卻越走越慢
最後的最後, 老師則是講述對於 PO 來說, 最重要的是什麼？
品質！ 品質絕對是最後的防線！
這邊就講述到先前的 DoD (Definition of Done)
在 Day1 時, 老師對於 DoD 的定義是
這是 Team 與 PO 之間的約定
所以到底是約定什麼？ 跟 AC (Acceptance Criteria) 驗收標準又有何不同？
最簡單的差別, DoD 每個 Story 應該都要相同
然而 AC 則是每個 Story 都會不同
阿鬼... 你可以說中文嗎？
再更深入的說, DoD 就是為了品質絕對不能放棄的基本
比如說
* 單元測試
* 驗收測試
* 代碼審查 (Code Review)
* ~~禁止~~ 這邊剪下那邊貼上
* ~~禁止~~ 硬幹 Hardcode 寫在裡面
* ...
有時候會因為 Scope, Time, Cost 的限制
往往為了 快 而讓我們犧牲了 品質
為了 快 我們留下了一堆 技術債
當 債留子孫 的時候….. 你覺得還快的起來嗎？
Scrum PO 看見全貌
最後, 來到了尾聲
我嘗試將這 4 天對於 Scrum 的重新認識
並且加上使用 PO 的角度, 來看見 Scrum 的全貌
以下是我整理完後的可行性版本：
專案之初, 使用 Impact Mapping 找到 有價值 的使用者情境
再透過 User Story Mapping 發想情境細節, 並選出第一個 MVP 版本試行
利用 User Story Split 細探 Story 的 細節 並 拆分 Story
Planning #1 說明 Story 給予初步 估點 並了解 驗收標準
Planning #2 Team 拆解 Task 並讓每個 Task 都是細到一天可完成的範圍
Daily Scrum 時 Team 更新 Task 的 進度, 並盡力 交付 一個個 Story
Timebox 限制, Sprint 衝刺目標 完成 Task 跟 交付 Story 甚至是 Value
Review Meeting 時針對 目標 Review, 並 檢視 Story
Retro Meeting 時針對 團隊 過去一個 Sprint 的好壞討論, 並提出 改善
最後執行一或是多個 Sprint, 交付 Release 目標, 最終 達到價值 ！
專案結束後, 帶著更強大的 Scrum Team, 迎接下一個挑戰～
連上 4 天課真的是累到一個不行
但是重要的是將學習到的東西帶回實戰應用
待之後有更多的經驗與案例可以再分享出來後
再來持續的更新這個部落格吧～
收工！
