[N社筆記]敏捷路上跌倒站起來 2018/11/18

工程人員一定要分析後才能投點嗎 ?(有關 Planning 會議很長)

記得設定 Timebox。
Scurm 是經驗法則,可以拿已經作過投點的 Item 作為比較基準。
如果有未知與風險,當下不要過度鑽入細節。
你可以

  • 開一個小的 Task 用來作調研與評估
  • 開一個很大 Task 之後再用來 BreakDown
  • 如果它是高價值又高風險,就優先作它吧

如何加速會議進行?

決議與會議之外。先讓人看見問題與目標,與可能的方向。
SM 應該更關注決定的過程,而非決定的本身。

焦點討論法(如何問問題)

O↓ 事實(每個人看到的都不一樣)
↑R 感受(相同的事實不同的人不同的感受) → 往複 OR ,取得共識(有共識才透明)
Interpretive 意義與價值觀
Decisional 決定

Bussiness DevOps


迭代與增量真的有幫助嗎 ? (Agile 之前我們怎麼工作的?/Scrum 真的好嗎 ?)

看情境

Agile 適合應付變化,而目前的世界變化很大。
不要為了 Scurm 而 Scurm 。
那樣會變成盲從,看見你的需要,務實的變革。

用一個問題打敗一個問題(Ruddy老師引導法)

找到核心的問題,然後問 「怎麼作 ?」
學員回答後,老師常常會說「這是一個方法」,然後給予回饋。

這句話的潛台詞是「還有其它的方法」。

團隊成員恐懼端到端的開發(新手SM與新手團隊)

  • 讓 1 個 Sprint 先完成 1個最高優先級的Item (初期導入 Scurm 怎麼作?)

Scurm 對團隊的要求其實蠻高的,
但是我們不需要端到端的工程師,而是團隊。
巴士因子可以是個判斷指標。
另外限制理論[求補充]告訴我們瓶頸會跑來跑去,所以要持續觀注與改善。

團隊估點從 100 → 200 (Data Team 從沒有信心 Commit 到 $#@…)

這個點數的增長不合理,而且還是以時數點數,
沒有任何東西可以讓一天變成 48 小時(喔…有人說,加班可以讓8小時變16小時)
持續觀注,如果失敗了就讓它失敗吧…
但是要失敗的有意義。

後續

11/23 團隊作的工作量實際上達到 254/3xx (Commit 3xx,完成254。),
sprint 是成功的,但是 Velocity 是失準的。

小心得:

  1. 所謂的 Commit 如果不是對自已 Commit 起不了激勵作用,
    如果 Team 與 PO 不認為「我們是一個Team」,而還是分 PMO 與 R&D
    那麼 Commit 就會變成畫押背鍋的儀式。
  2. 氣象報告失準怎麼辦,颱風沒來大家都開心嗎?(從 100→254,是效率大爆發,還是浮報點數了?)

Scrum 的神奇魔力

當老闆就是 PO (PO 與 Scrum Master 出現了階級關係)

  • 找一個小 PO (作 PO 真正該作的事)

正視真正的問題是「你沒有 PO」

當 Team 在兩個作法兩難的時候

  • 作一個 Check Point,保留可以回來重新審視的機會

現實中有遇到類似的狀況,
執行的當下會列出所有的優缺點,再作選擇。
作完之後問自已,再作一次你會怎麼選擇 ?

成員本來會多作優化,跑 Scurm 之後沒在 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指數?)

業務單位的務實

業務/老闆會說,我才不管什麼開發方法,
作出來就好了(黑貓白貓能抓老鼠就是好貓…)
很務實,但是很傷害團隊…,不要有機會讓團隊聽到這種話

結束就結束了。

參考

(fin)

Please enable JavaScript to view the LikeCoin.