改革，很不容易；摧毀改革，卻很簡單。知名的改革框架，莫不注重改革的整合與固化。 敏捷亦然。像這篇文章〈慢慢的，公司内敏捷的热度就退了&hell

Scrum 的官方白皮書 The Scrum Guide 非常輕薄短小（像 Nov 2017 版只有 19 頁），它的理念是：只制定最核心的原則、價值、角色、活動、產出物，其餘的則交給團隊根據經驗主義 ¹ 去調適出最適合自己的細節。

想當然爾，有很多事，Scrum 並沒有明說。

那麼，沒有明說的事，就不需要做、就不能做了嗎？做了，就違反 Scrum 嗎？

這是許多奉 The Scrum Guide 為圭臬的人，常有的盲點。

在一篇 Terry & Ruddy 對話紀錄中，看到一系列有趣的 LeSS vs. SAFe 討論： 「為什麼 LeSS 這麼迷人，可是總是輸給 SAFe？」 「SAFe 是敏捷跟辦公室政治作出了完美的妥協

在台灣（或許在其他地方也是），DevOps 的話語權，很大幅度都被 Dev 一方把持。我們很少聽到 Ops 一方的說法。

成功的改革，需要兼顧各方利益者的需求及痛點。隨著 DevOps 守備範圍日益擴大，這種失衡狀態必須改變。

今晚參加 DevOps Taiwan 社群舉辦的講座：【從 Ops 角度看 DevOps】，聽聽胡士亮 (Robert Hu) 從正統 Ops 角度來詮釋 DevOps，甚至 OpsDev，收穫頗大。

聽知識，聽心得，也聽熱情與願景。

看完〈敏捷的價值與指標〉之後，很自然的會進一步追問：「那麼，什麼才是 DevOps 圈子所認定的價值，以及對應的指標，尤其是領先指標？」 這問題其實比較容易