工程人員一定要分析後才能投點嗎 ?(有關 Planning 會議很長)
記得設定 TimeBox
Scrum 是經驗法則，可以拿已經作過投點的 Item 作為比較基準。
如果有未知與風險，當下不要過度鑽入細節。
你可以
- 開一個小的 Task 用來作調研與評估
- 開一個很大 Task 之後再用來 BreakDown
- 如果它是高價值又高風險，就優先作它吧
如何加速會議進行?
決議與會議之外。先讓人看見問題與目標，與可能的方向。
SM 應該更關注決定的過程，而非決定的本身。
焦點討論法(如何問問題)
O↓ 事實(每個人看到的都不一樣)
↑R 感受(相同的事實不同的人不同的感受) → 往複 OR ，取得共識(有共識才透明)
Interpretive 意義與價值觀
Decisional 決定
Business DevOps
迭代與增量真的有幫助嗎 ? (Agile 之前我們怎麼工作的?/Scrum 真的好嗎 ?)
看情境
Agile 適合應付變化，而目前的世界變化很大。
不要為了 Scrum 而 Scrum 。
那樣會變成盲從，看見你的需要，務實的變革。
用一個問題打敗一個問題(Ruddy 老師引導法)
找到核心的問題，然後問 「怎麼作 ?」
學員回答後，老師常常會說「這是一個方法」，然後給予回饋。
這句話的潛台詞是「還有其它的方法」。
團隊成員恐懼端到端的開發(新手 SM 與新手團隊)
- 讓 1 個 Sprint 先完成 1 個最高優先級的 Item (初期導入 Scrum 怎麼作?)
Scrum 對團隊的要求其實蠻高的，
但是我們不需要端到端的工程師，而是團隊。
巴士因子可以是個判斷指標。
另外限制理論[求補充]告訴我們瓶頸會跑來跑去，所以要持續觀注與改善。
團隊估點從 100 → 200 (Data Team 從沒有信心 Commit 到 $#@…)
這個點數的增長不合理，而且還是以時數點數，
沒有任何東西可以讓一天變成 48 小時(喔…有人說，加班可以讓 8 小時變 16 小時)
持續觀注，如果失敗了就讓它失敗吧…
但是要失敗的有意義。
後續
11/23 團隊作的工作量實際上達到 254/3xx (Commit 3xx，完成 254。)，
sprint 是成功的，但是 Velocity 是失準的。
小心得:
- 所謂的 Commit 如果不是對自已 Commit 起不了激勵作用,
如果 Team 與 PO 不認為「我們是一個 Team」，而還是分 PMO 與 R&D
那麼 Commit 就會變成畫押背鍋的儀式。- 氣象報告失準怎麼辦，颱風沒來大家都開心嗎？(從 100→254，是效率大爆發，還是浮報點數了？)
Scrum 的神奇魔力
當老闆就是 PO (PO 與 Scrum Master 出現了階級關係)
- 找一個小 PO (作 PO 真正該作的事)
正視真正的問題是「你沒有 PO」
當 Team 在兩個作法兩難的時候
- 作一個 Check Point，保留可以回來重新審視的機會
現實中有遇到類似的狀況，
執行的當下會列出所有的優缺點，再作選擇。
作完之後問自已，再作一次你會怎麼選擇 ?
成員本來會多作優化，跑 Scrum 之後沒在 Task 之上的事不作了。ex:重構、優化…)
在 DoD 應該可以解決這個問題，如果現況不會有問題，為什麼要作?
先作 Task 有列出來東西我覺得基本上是對的。
SM 的問題是「認為該作，但是沒有技術 Know How 所以不知道該列什麼?」
那還沒有跑 Scrum 前如何評量這個項目的效果呢?
至少在 Scrum 中我認為可以透過 Velocity 作為指標。
也可以透過 DoD 決定品質的程度(ex:)。
另外，重構不是重作，
重構應該是時時發生的，寫測試可以讓這件事被量化，
難以測試的代碼本身就有一定的壞味道(工程實踐與遇到的困難就以後再寫了…)。
Team 不該 Challenge Item Value 嗎 ?(這樣跟以前需求來就作有什麼不同?)
在 Scrum 中,
PO 觀注 Why ,觀注產品價值 ,觀注市場與策略
Team 可以決定怎麼作，與 PO 討論理解為什麼要這麼作，
並不是所謂的「需求來就作」，而把 PMO 的角色拿掉，
是為了減少隔閤，讓團隊更接近商務端。
聽起來這個情境，Team 與 PO 仍有抗拒心理…
身兼開發的 Scrum Master
Team(1+1+1+1…) x SM (0.9 or 1.1) = 生產力
讓 SM 成為乘數，而不要成為加數
小地雷:如果乘數小於 1(如何評量 SM 指數?)
業務單位的務實
業務/老闆會說，我才不管什麼開發方法，
作出來就好了(黑貓白貓能抓老鼠就是好貓…)
很務實，但是很傷害團隊…，不要有機會讓團隊聽到這種話
結束就結束了
參考
- [心得] ScrumMaster 自我突破訓練營
- ScrumMaster 自我突破訓練營 in 91APP ：ScrumMaster 的生存之道
- ORID 簡報- By 茶米
- Scrum Master 自我突破訓練營 — 心得分享
(fin)