AI 時代新敏捷宣言 - waterfall 重生 ?

 

從 Vibe 浮濫到 Context Engineering：AI 時代的敏捷再思考

最近我有一種既熟悉又陌生的感覺——我們好像在重新快速走一遍軟體工程開發史，但這次是「反著走」。一切先從大 Vibe 時代談起，AI 讓我們可以極快地驗證創意、做出原型（POC）。但過於依賴靈感驅動與即時生成，也讓過程容易浮濫、缺乏工程上的紮實基礎。於是我在各處看到兩派不同的聲音開始碰撞。

POC 與 Operation 的視角差

在 AI 驅動的快速原型（POC）時代，老闆與 PM 往往希望「先做出來、先 demo、先驗證市場」。而資深工程師則會思考「這東西能不能穩定上線運行？架構是否可靠？可維護性與長期成本如何？」

AI 雖然可以幫忙快速產出原型，但同時：

• AI 可能生成品質不穩定的程式碼
• 需要更多 review 與設計確認時間
• 有時候資深工程師自己寫反而更快、更準確

而從 Engineering Manager 的角度我也看到新問題的產生，團隊協作的問題，團隊和 AI 協作的問題，開發環境一致性的問題…等，此外我覺得現實更殘酷：真正頂尖的工程師不多，的確高手工程師一定能做得比 AI 更好更扎實，他可能不需要 Vibe & Agent，他只需要 copilot 就夠，但其實市場上更多數團隊成員是中階或初階，如何在「速度」與「品質」之間找到平衡，成為新的管理課題。

會議太多浪費時間？寫文件浪費時間？當一切都 Mob & AI 化後這些都不是藉口了....

 

前陣子在整理 Agile at Tesla 中常常看到 Mob 的字樣，其中在『究竟什麼是真的敏捷』篇中也有提到： 

所以現在我稱它為『Mob - 群體協作式敏捷』，因為它很短，而且我認為人們能理解它。而這就是它的內容。你有這些小組在議程上工作，開放空間，他們是開放空間的會議，小組正在運行 mob。就像學校教的那樣。這是直接的 mob。

說實在也想不出來什麼比較好的翻譯? 團抱式敏捷？暴徒式敏捷？所以我把 Mob 翻譯成『群體協作式敏捷』。

大規模敏捷開發？ 讓我們先來談談跨國大型軟體開發的日常挑戰

 

在『敏捷思考的高績效工作術』裡面提到了五力

• 構想力（構思屬於自己的未來）
• 靈敏力（快速產出結果）
• 適應力（靈活地適應環境
• 協調力（與不同質的人合作）
• 共創力（透過合作產生價值）

之所以會需要這五力，主要是因為工作趨勢的改變就是越來越多 專案化工作 

根據全球策略顧問貝恩公司（Bain & Company）的報告，在2027年前，大多數的工作內容都會以「專案」為基礎。這一轉變的主要原因是數位革命的加速，許多工作將被自動化或改由外包人力執行。留在公司內部的核心角色將是那些能夠整合內外資源、接住新商機和客戶需求的專案管理好手。
「日常工作只佔我們60％的績效，剩下40％都是創新的專案。」

跨國軟體企業中的專案化工作

這種現象在跨國軟體企業中尤為明顯。這些企業內部通常有許多部門負責不同的功能，而各個部門的任務都是由公司大方向（OKR/KPI) 細部拆解下來。雖然高層對整體狀況有大致的了解，但他們也無法了解更多第一線的工作細節，更不用說各部門之間的相依更難以理解。如果僅依靠上層的問詢和溝通，所得到的信息往往片面且簡化。如果需要更細部的資訊和解決方案，最常用的方法就是跨部門溝通和協商。

你是一個 VUCA Master 嘛? VUCA Masters: Developing Leadership Agility Fitness for the New World of Work

 

Source: leadership agility development guide

前幾天參加了 Bay Area Business Agility Meetup 舉辦的一場分享 

The “VUCA Masters – Developing Leadership Agility Fitness for the New World of Work” event with Dr. Nick Horney

主要分享的內容在於面對 VUCA 的世界，所有的工作方式都在改變，而 Dr. Nick Horney 認為領導力就像肌肉一樣是可以透過鍛鍊習得的。其中覺得有幾張投影片的內容蠻有趣的，特別分享出來。

Joe Justice 專訪 Episode 11 究竟什麼是真的敏捷？對會議的新定義

 

本篇重點：

接續上一篇 - Episode 10 究竟什麼是真的敏捷？本篇繼續探討 Agile at Scale 的議題，首先 Joe 又暫時發明了一個新的名詞『團體敏捷』（Group Agile），透過一個巨大的看板，把所有小型看板聚集在更容易觀看？

另外本篇的另一個重點就在對於會議的定義，傳統的公司會議可能是為了交換訊息，為了取得共識，甚至為了得到批准，以這種定義來看，Tesla 幾乎沒有會議，但是取而代之的是有大量的 Mob＆ Lean Coffee，也就是一群人在一起協做和共創，重點是在這個會議上能得到有效產出，並沒有人只是盯著電腦不做事或是等著別人給結論。

套句 Joe 說的：

我認為，Mob 是對現今社會來說最有生產力的會議，或是以精益咖啡的形式舉辦。而這一直在發生。事實上，這就是你的正常工作。事實上，除了這個，幾乎沒有其他事情。因此，如果這被稱為會議，那麽 Tesla 都是這樣的會議。但是，如果會議是在別人說話時看著你的筆記本電腦，我從未見過。一次也沒有。

最後總結，要達到 Tesla 這樣瘋狂的敏捷，大概也得要有像 Elon 這樣瘋狂的工作狂老闆才有可能~XD

Joe Justice 專訪 Episode 10 究竟什麼是真的敏捷？

 

本篇重點：

當許多人談到敏捷，第一個可能會想到 Scrum & Kanban，當談到大公司實行敏捷，可能會想到 Scrum at Scale, LeSS, SAFe...等，但是 Joe 繼續以計畫和發佈的時間長度這個角度來探討為什麼傳統的敏捷方法可能不夠用，所以 Tesla 才會自己繼續演進出更快速的方法。

Joe 認為實行敏捷的方法可以變，但是某些基礎能力和心態卻是不會改變，如硬底子的技術 XP/XM，結合群眾的智慧：Mob，開放空間技術...等。

另外在這邊也探討了傳統敏捷都倡導穩定的團隊，但是為什麼 Tesla卻是隨時在重組團隊，因為他們為了要解決問題，鼓勵成年人心態的雙腳法則 - 隨時移動到最需要自己和自己最能貢獻價值的地方。

最後也提到許多傳統敏捷覺得重要的會議和事件為什麼到頭來反而會傷害或拖慢敏捷？Tesla 透過什麼方法來搭配改善？如大量收集資量分析，並且透過 AI 的快速 feedback，破除一般思維的第一性原理...等。

最後 Joe 也舉了一個 Tesla 面對晶片短缺如何做出快速反應的例子，這才是所謂的『敏捷』，因應變化做出改變。

警語：Tesla 的敏捷不是大家都能輕易嘗試的，沒有對應的基礎和思維輔助，貿然抓幾個點來學習是危險的。

Joe Justice 專訪 Episode 7 開發篇（一）

本篇重點：

• 要做到 3 Hour 一個 Sprint，需要搭配許多硬功夫：
• 透過機器輔助大量試錯（要有嚴格的 Auto Test）
• Growth mindset & Cross function 的小 Team，不會就學
• 詳盡的 DOR & DOD，每個 Sprint 完都要產出交接文件，給下一班的人使用
• 透過 AI & ML  輔助學習，做決策，甚至給員工 Feedback 

Mun-Wai Chung：我對於我們將要討論的議題感到興奮，關於產品的生產，產品的開發。你之前提到敏捷衝刺（Sprint）的定義是你在每個衝刺後都要產品都要能發行，對嗎？我知道有些公司會作弊，所以我的問題是，你能不能舉出一些例子，說明在三小時的沖刺過程中實際能交付的東西的類型？

Joe Justice：還有很多題目我希望可以多說一點，不過有些先之前已經分享了，所以我想盡量把能想到的都想分享一下。

其中一個是更快的充電系統。電池組的充電效率（每小時千瓦數或千瓦時），是電動汽車制造商行銷的重點和指標。保時捷宣布他們可以進入350千瓦，但後來做了一次召回，改變限制。現在他們不確定電池組的壽命，這還有待確定。但我想說的是，這真的很重要嗎？人們追求的是越的高數字嗎？因此，你也不需要 Elon 說：『讓我們增加千瓦時的數量，一小時內可以充電完畢，並且電池組壽命至少 10年以上。』 因此，任何人都知道， 只要有想法，就應該立即去執行。

Joe Justice 專訪 - Agile @ Tesla 計畫管理篇

這集的內容真的還蠻難翻譯的，有些東西也不太好理解，不過總結大概幾個重點：

• 大量使用 AI & ML 來輔助公司做決策
• 特斯拉以符合 B Corp 的認證方式在治理公司
• 透過 AI & ML 快速回饋才能達到敏捷的自組織，甚至許多管理階層的工作都可以委託給 AI

還真的蠻難想像的?

Joe Justice 專訪 - Agile @ Tesla Management -1

 

本篇長度 25 分鐘，內容包括特斯拉如何透過 AI 輔助管理和績效的改善，更聊到了馬斯克龐大的事業以及他的野心。

Joe Justice 專訪 - Agile @ Tesla Finance 篇逐字稿 3-3

接續上ㄧ篇，這篇有兩個重點關於如何財務自動化，以及為什麼會投資數位資產，並且尋找有志之士一起來推廣敏捷。

Joe Justice 專訪 - Agile @ Tesla Finance 篇逐字稿 3-2

 

接續 Joe Justice 專訪 - Agile @ Tesla Finance 篇逐字稿 3-1 ，我們可以從這邊學到所謂的 Being Agile 連工廠的建造都可以非常的敏捷，充滿彈性，也終於有聽到關於 Scrum 流程相關的內容。

Joe Justice 專訪 - Agile @ Tesla Finance 篇逐字稿 3-1

 

source: agile-tesla 

在 Tesla 股價又創新高的同時，大家一定對於 Tesla 的財務運作非常好奇，讓我們繼續深入了解 Tesla 如何在財務上如何敏捷與創新。

特別感謝 Kelly 幫忙校對！

Joe Justice 專訪 - Agile @ Tesla HR 篇逐字稿 - 2

Source: agile@tesla

敏慧：實在太讓人嫉妒了！我也想進到這個玩具店。接下來我們來談另一個議題：階層，因為你說特斯拉幾乎是『完全扁平化組織』，幾乎沒有階層的概念？就算職稱是經理，也可能跟其他公司想像的不一樣。他們只是另一種職位，因為這邊沒有部門？你可以針對這部分再多說一點嗎？我知道這邊也沒有職涯發展成長之類的事，但是總會有某種類似獎勵和認可的制度嗎？這邊有任何類似績效考核的概念嗎？比如說如何決定績效好？或者是任何激勵制度和獎金？如果有，那是如何決定？

Joe Justice：這邊有兩種有效的方法，一個是我們找出類似於績效考核的概念，特斯拉如何運作我們一般人所熟知的獎勵及認可機制，用類似階層組織架構和爬職業階梯的方式類比。另一種是透過人性的角度，爬職業階梯的目的是為了什麼？你還有什麼其他方法來達成這些目的？

讓我們先從第二個方法來講，如果你有一隻柴犬，如果你有一隻狗，你想要教這隻柴犬一個新的技能，你想幫助牠學習，揮手，在他房子前折返跑，跳或一些可愛的事？你會希望有一個直接的反饋迴路，讓它從提示和獎勵中做出我們要牠學習的行為。你會想要快速地見到到牠做了一些有用的事情。

Joe Justice 專訪 - Agile @ Tesla HR 篇逐字稿 -1

source: agile-tesla 

  

敏慧：Hi Joe，非常感謝你來上我們的 podcast。我們準備了超多問題要問你，希望你做好心理準備不要被嚇到。

Joe Justice：敏慧 / JF 放馬過來！感謝兩位今天一起來玩。

敏慧：讓我們馬上開始，Elon Musk 想要快速創新，而最終他也的確在 Tesla 建立了一個非常敏捷的組織，並且以這個流程撼動了整個汽車產業。所以在特斯拉人力資源部門是什麼樣子？是怎麼運作的？我甚至懷疑 Tesla 有人力資源部門嗎？

Joe Justice：好的。首先我要對形塑許多公司、了解敏捷人力營運的人們致敬，例如「Agile HR（敏捷人力資源部門）」一書其中一位作者 Riina 。我曾經與她共事過，她非常的傑出，並且對於這個領域有很深的見解。如果想要更加深入了解這個主題， Agile HR 無疑是一本好書，當然我很樂意在這邊分享 Tesla 內部運作的情形。沒錯， Telsa 有 人力資源部門，而且還不止一種。有生產 人力資源部門和一般的人力資源部門，至少就有這樣的區分。當我在 Telsa 加州 Fremont 總部推廣敏捷時就有與這些部門合作。
讓我介紹一下自己，我是個敏捷硬體推廣者，我從 2006年就開始使用敏捷方法製造車子。最終我加入了特斯拉，並且在裡面推廣敏捷。我在 2020年 成立了那個計畫，那時正經歷股票市場很有名的事件，也就是特斯拉將1股股票分割為5股，我在那段期間必須用敏捷的角度來推行這個重要的任務，也因此經歷了一段令人驚豔的旅程。在這邊想跟大家分享，沒錯，特斯拉有人力資源部門，而且不只一種。

Agile Coaching Retreat 2021 活動雜記

面對 COVID-19 的衝擊，我們每個人的日常生活都被強迫改變，不管是出於自願還是被迫，許多人開始了遠端工作（WFH/RW），因為無法實體聚會許多活動都改成線上舉辦，因為無法去學校上課/授課，老師與學生都開始嘗試新的學習/教學模式，看著過去的照片，心想下一次可以出國旅遊不知道是什麼時候....

這時候可以問問自己，在心態上真的有準備好接受這一切嗎？還是在心裡，我們仍然這樣告訴自己，再撐一陣子就好了，再來就可以恢復正常了？殊不知這個世界真的不一樣了，很可能再也回不去了？就算疫情過去，可能面對我們的已經是完全不同的世界。

有些人等待恢復過往的生活，有些人已經開始嘗試新的生活與工作形態，而今年的  Agile Coaching Retreat 2021 就是一群敏捷教練在線上嘗試新的生活與工作型態。

 

推薦序 - 敏捷管理生存指南 by 敏捷黑手阿伊

 

收到 Yves 請我寫推薦序的當下，感到非常榮幸也非常惶恐，因此遲遲無法動筆，正當我還在苦惱不知道該怎麼下筆時，馬上又收到 Change request ，希望我改成貢獻一篇學習敏捷的心路歷程，而且離 Deadline 只剩下幾天了！阿這不就是在敏捷路上一直遇到的狀況嗎~計畫永遠趕不上變化，需求總是來得又急又趕。 

不過藉著這次機會，讓我再次回溯了這幾年來學習敏捷的經過和文章，發現自己的核心的價值觀用一句話總結就是『沒有最好只有更好，一定還會有更好的方法可以持續改善』。 

敏捷深夜食堂：什麼是 Long Live Team

最近有朋友問我 Scrum 裡有一條 Long live team 的定義，到底要把一群人放在一起多久才算 Long live team ? 一週？一個月？一季？一年？ 還是就是說不清楚反正  As long as possible？我們來公司又不是來交朋友的，當『階段性』任務完成就應該重新調整，讓公司資源分配最有效率最大化啊？我的認知是用多長的時間來衡量 Long Live Team 是一個假命題，重點這一群人是否一起『走過完整產品生命周期』

 

Team Topologies - 團隊優先思考模式

Source: Team Topologies Chapter 3

 

距離上一次聽到作者的演講，並且寫了一篇：微服務架構或單體式架構?先從團隊認知負擔談起，也經過了一年多了，一直都沒時間靜下心來好好讀這本書。

直到最近漸漸開始感受到切身之痛，是時候該好好把這本書讀完（臨時抱佛腳的概念），隨著組織業務增長，團隊也越長越大，團隊之間需要更有效的橫向溝通與協做模式，此外組織為了要在業界佔有一席之地，也必須不斷的加強 domain knowledge 與技術深度，團隊成員都有種要爆的感覺，但是卻又無法具體的描述具體原因出在哪裡？因為人力資源不夠？這是每間公司都會遇到的問題阿，有哪間公司會說自己人太充足的？是因為團隊成員能力不足？其實團隊成員的能力也都是一時之選，那究竟問題出在哪裡呢？很有可能就是在於組織架構和協做溝通的方法。

成功為成功之母，如何從 near miss 中找出致勝關鍵

source: near miss

在 Scrum retrospective meeting 通常會有幾種問題：覺得的好的和不好的，要繼續做的和該停止的這種討論，不過通常對於做的好的，大多會流於感謝和整能量時刻，而很少會好好去討論為什麼的成功，和關鍵指標是什麼，以及這次成功會不會真的就只是運氣好？有聽過專案驗屍會議，但是很少聽過專案成功檢討會議？

我們都知道要敢於面對失敗，因為我們更容易從失敗中學習。但是其實最常被忽略的就是從成功中學習，尤其是那種被運氣影像，『差一點就會失敗』的成功，英文稱為『near miss』。

[書摘] 傳奇億萬美元級教練比爾·坎貝爾 Trillon dollar coach

Trillion Dollar Coach - The Leadership playbook of silicon valleys

之所以會對這本書感到興趣一來是好奇這本居然敢自稱『 leadership playbook 』書的內容，而另外一個主因是想瞭解一個『美式足球教練』如何轉型變成商務人士，最後甚至變成矽谷一堆高科技獨角獸公司老闆的教練和朋友( 如 Apple - Steve Jobs， Google - Eric Schmidt ...）。 

這本書基於對八十多人的採訪，並透過許多名人和獨角獸公司的故事整理與解釋了這些管理的原理。目標是為企業領導人和經理提供了一個藍圖，以創建績效更高，速度更快的文化，團隊和公司。前半段主要在描述比爾·坎貝爾的生平，接著就是穿插在許多公司時的案例，透過這本書可以讓我們瞭解這些獨角獸公司還小的時候遇到的挑戰，以及怎麼解決的，有別於市面上一堆管理的書籍講的都是這些獨角獸公司壯大以後的制度。