研發團隊，常會被問到一個問題：

「請問一下，這個Ａ功能，大概要多久才能完成？」

這個問題，不會因為你跑的是敏捷，就自動免疫。那麼，身為經過敏捷思維洗禮的人，該如何做出合宜的應對？

我在 Agile Tour Kaohsiung 2018 開辦一場 2.5 小時的工作坊，帶領大家親自體驗這個議題。

不過，這個題材的背後，其實還有三段故事。

故事，要從一年半前講起。

改革，很不容易；摧毀改革，卻很簡單。知名的改革框架，莫不注重改革的整合與固化。

敏捷亦然。像這篇文章〈慢慢的，公司内敏捷的热度就退了…..〉就訴說一則可悲的故事：

我並沒有告訴他們具體要怎樣做，只給了他們一些理論上的指導，然後他們就開始集思廣益，動手佈置。這其中展現出來的主動思考能力、自組織能力和執行力，讓我不由得暗地裡豎起大拇指。基於這樣良好的基礎，他們的敏捷過程推進的也非常順利，我輔導了他們 3 個月左右，他們已經熟練的掌握了一些實踐方法，加上本身已經具備的自組織能力和執行力，似乎繼續做下去，就可以達到不錯的成熟度。

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

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

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

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

在一篇 Terry & Ruddy 對話紀錄中，看到一系列有趣的 LeSS vs. SAFe 討論：

「為什麼 LeSS 這麼迷人，可是總是輸給 SAFe？」

「SAFe 是敏捷跟辦公室政治作出了完美的妥協（應該吧？），所以大家比較 Buy-in 吧。」

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

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

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

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