「敏捷」這概念，台灣很晚才起步。

儘管敏捷宣言 (The Agile Manifesto) 早在 2001 年就問世，可是在台灣，如果以 David Ko 在 2014 年首次舉辦的 Agile Tour Taipei 活動作為開端，「敏捷」開始成為台灣業界的話題，大概也不過十年。

於是，在國外早已經百家爭鳴的「大規模敏捷」流派（連 SAFe 都出到 6.0 版了呢），在台灣，直到近年才零零星星有人談到這議題。

大規模敏捷的各家流派，多半是從 Scrum 之類的原型出發。但 LeSS 與眾不同的是，它非常謹慎自制，避免在規模化過程中引進無謂的複雜。

就如同《多團隊高效協作密技》所說：「規模化，不是角色變多、流程變複雜，而是協作方式的改變。LeSS 的導入，難處都不在 LeSS 的流程，而是在環境與人的不配合。」因此，想學習 LeSS，重點不要只放在流程上，應該更留意探討這些協作、環境、人的議題。這才是形塑 LeSS 的關鍵驅力。

全球都在享用 Google 首屈一指的線上服務群，但直到他們在 2016 年出版了 Site Reliability Engineering 一書，世人才第一次全面認識到該如何支持這種深度廣度的系統維運。

全球性線上服務系統，規模與複雜度遽增，只靠傳統的人力或獸力是無法長久維運下去的。面對這問題，擁有第一流軟體研發能量的 Google，大膽拋開傳統作法，改從一個獨特的提問出發：「如果我們賦予軟體研發工程師一個任務，讓他們有機會從頭去設計維運系統，那會是什麼模樣？」

更進一步的提問是：「如果我們限制他們最多只能投入 50% 的時間在維運上，那會是怎麼樣的工作方式？」

從這角度出發，便是目前我們現在看到的 SRE。

今天在 DevOpsDays Taipei 2024 給了一場 Keynote Speech：【從系統思考角度談 DevOps 三步工作法】。 ​ 事情的緣由是這樣的。

艦長想在 DevOpsDays Taipei 2024 繼續開設廣受好評的新手村、入門班系列。經過討論，我決定仿照之前在 DevOpsDays Taipei 2018 & 2021 的路線，繼續以「系統思考」角度去剖析 DevOps 相關的組織文化與管理議題。

我自己有一個關於演講的內規天條：演講，不只是輸出，也希望每次都有新的挑戰。因此，對於這次的演講主題【從系統思考角度談 DevOps 三步工作法】，我給自己下的挑戰是：我不要用較為人知曉的 CLD (causal loop diagram)，我要挑戰更難的 SFD (stock and flow diagram)。

改用 SFD 倒不是為了量化塑模，而是因為它能夠更嚴謹的思考「變數」。正好這幾年台灣也開始流行起存量、增量的詞彙 ¹，我想，不妨跟風蹭一點熱度。

不管是專案管理領域還是目標管理領域，「階段性的預期成果設定」都是很重要的基本動作。

不過，多年下來，我常常看到怪怪的，但又說不上來哪裡不對勁的例子。因此，我想找找是否有建議的寫法，甚至句型，作為團隊的共同語言。

此文針對 ① 專案管理領域的 milestone 與 ② 目標管理領域的 key result 兩方面來探討。

屢次教改，課綱演進至今，許多人認為補習班與私校是受益者。

補習班的說法可能不易判斷真偽，而私校畢竟受到教育當局的監管程度較高，說法應較可信。譬如說，私校定期呈報教育當局的「學校課程計畫」報告書，就可看出從教師角度出發的論述。

我選了兩份報告：〈臺北市靜心國民中學 112 學年度學校課程計畫〉（以下簡稱「靜」）與〈臺北市私立復興實驗高級中學國中部 112 學年度學校課程計畫〉（以下簡稱「復」），一窺私校眼中新課綱時代的教與學。

看完之後，只能用這幅 ChatGPT 生成的圖來形容自己的所見：

以下是一些重點摘要。