大規模敏捷軟體開發方式的健康指標

Published in

Words

Nov 5, 2023

這是 LeSS Conference 的十五分鐘短講，上週 Terry Yi 在台北的聚會也講了一次（內容應該是 Odd-e 成員討論出來的）。目的其一是用比較不痛的方式應付一些管理評鑑要求 XD… 還真是入世啊不是嗎？

記錄一下摘要，以下的詞彙如果沒特別說明都是用 LeSS 的定義。

停在 Sprint backlog 裡的時間超過一個 Sprint 的 item 數量

在 LeSS 的狀況最好只有 1，但要根據自己實踐敏捷的方式判斷這個「一個 Sprint」的標準，比方說如果是在 Refinement 建立 Backlog，那當然就一定會超過一整個 Sprint，便不會如此定義。

理想狀態下不超過團隊總數（所以不是跑 LeSS 的話，單算一個 SCRUM team 就是 1）

越高越好，代表更可能是以使用者為出發點。太低的話可能其實是在寫（內部實作要用的）tasks，請多關注使用者。

高一點好，跟開發人員切分 increments 的能力有關。不過這是在每個 commit 夠 atom, self contained 的前提下，只是作弊要衝高沒意義。

越高可能表示團隊更有信心不會弄壞別人的東西（也許自動化測試做得夠好）。Terry 補充認為 branch 機制是在彼此（對程式碼品質等）信任度不佳時需要，比方說 open source 志工協作的模式下就要這麼用，但日日一起工作，若環境妥善到能直接 commit 進 trunk 才能快。

另外這可不代表每個團隊都有自己的 trunk – 每個產品只該有一個 trunk。LeSS 是在討論一個產品多團隊共同實作時的狀況，因此要強調這點。

過低可能表示團隊其實在跑 fixed scope 的偽敏捷瀑布流（沒有迭代、沒有從 feedback 裡獲取修改想法）；老是 100% 可能也不太對。我當場的意見是這個團隊可能處在過於短視的狀態。

有個延伸版是「在 refinement 中處理的 items 裡，在前次 review 以前尚未建立的 items。想看的東西意義應該相同。

理想狀態是零，嚴格控制 WIP 狀況是當代的主流。不代表只能把 backlog 的東西全做完（那是另一個問題），而是強調若都知道在這個 sprint 結束時無法提供價值取得回饋的東西，就別動工了。

這邊我直接改周遭比較常看到的 Epic這個詞彙吧。

不應太高或太低，但不應直接等同於團隊數量。這點我沒有多聽到什麼解釋，但聽來合理，畢竟強調了多個小隊在同一段時間內實際上是為同一個目標服務，如果變成每個小隊都在做自己的就… 不太一樣。

Terry 也提到相依性高的工作更寧願是讓多個小隊同時合作開發（隔天 David Ko 也有一樣的說明），我想這應該是個不太容易說服開發夥伴的 practice。

Well。我是承認單看短時間點生產力以及設備異常等要素來說，在辦公室共同工作比較有效率啦。

這邊是用 LeSS 的定義。嚴格說來我可能還沒有參透，但我想 LeSS 本來就期待團隊逐步向著「滿足完整的 DoD」前進，因此這個地方的完成度、有沒有逐步前進等等，是本來就要關注的。

但再度：我想我可能沒參透。

我研究 LeSS 的感想是這套推下去要伴隨劇烈的組織改造，我孬我先退。一直覺得各種開發的規則其實就是在描述某些管理方法，相關的健康指標也都在表達一些抽象的管理哲學。一以貫之。