作者 | Shane Hastie, Charity Majors

譯者 | 張衛(wèi)濱

策劃 | 丁曉昀

主要內(nèi)容

• AI 工具大大提升了開發(fā)速度，但是也帶來了質(zhì)量問題，因此需要新的測試和質(zhì)量方法。

• 盡管 AI 在不斷進步，團隊協(xié)作依然非常重要，有一種風險在于，工程師有可能會轉(zhuǎn)向 AI 而不是同事來尋求解決方案，這可能會破壞高效的協(xié)作文化。

• 初級工程師對整個行業(yè)依然至關重要，如今的初級工程師再向資深的同事提出具體的問題之前，可以利用 AI 作為學習的加速器，從而實現(xiàn)快速適應。

• 心理安全感依然是高績效團隊的基本要素，不過它正在遭受新冠大流行后的組織文化和經(jīng)濟壓力所面臨的挑戰(zhàn)。

• 可觀測性的成本在不斷上漲，組織需要將可觀測性作為一項戰(zhàn)略投資，而不是將其視為成本中心。

• 敏捷和 DevOps 實踐已經(jīng)融入行業(yè)標準，成為“我們呼吸所需的空氣”，平臺工程會成為下一個發(fā)展方向，它會將產(chǎn)品和設計理念引入開發(fā)人員的工具。

1 AI 加速、工程卓越和不斷發(fā)展的團隊動態(tài)化

在年度的 文化與趨勢報告播客 中，InfoQ 的文化與方法編輯團隊與特邀嘉賓 Charity Majors 一起探討了軟件開發(fā)文化、工具和實踐的變遷。從 AI 工具對開發(fā)實踐的深遠影響，到團隊績效和可觀測性觀點的演變，他們的廣泛討論揭示了影響軟件團隊 2025 年工作方式的幾個關鍵趨勢。

你可以通過播客收聽完整的文化與趨勢的報告討論，并查閱相關的文字記錄。

為了幫助 InfoQ 的讀者以及 QCon 和 DevSummit 國際軟件開發(fā)會議的觀眾把握現(xiàn)在和未來的趨勢，我們使用了 Geoffrey Moore 在其同名著作中首先提出的“跨越鴻溝（crossing the chasm）”技術成功心理模型。我們努力識別符合 Moore 所說的早期市場的創(chuàng)意，在早期市場領域，“客戶群是由技術愛好者和有遠見的人組成的，他們希望能夠抓住機遇或解決迫在敏捷的問題”。

與 2024 年、2023 年、2022 年、2021 年、2020 年、2019 年、2018 年 和 2017 年 的文化與方法趨勢報告類似，我們提供了 2025 年的主題圖：

作為互相參考的背景知識，如下是 2024 年的主題圖：

2 AI 對開發(fā)的雙重影響

最重要的趨勢就是 AI 對開發(fā)實踐的變革性影響。雖然 AI 工具極大地提高了生產(chǎn)效率，但是它們也帶來了重大的 質(zhì)量問題，團隊依然在學習如何解決這些問題。

AI 的應用已經(jīng)從謹慎的實驗階段發(fā)展為開發(fā)實踐中不可或缺的一部分。最近的一些報告，比如 DevOps 狀態(tài)報告，Copilot 等 AI 輔助工具已經(jīng)成為現(xiàn)代開發(fā)工作流程中的重要組成部分。但是，這些報告也揭示令人擔憂的變更失敗率在不斷上升。

“我們現(xiàn)在的構(gòu)建塊（chunk）正變得越來越大。多年以來，我們一直在致力于縮小構(gòu)建塊。現(xiàn)在，你只需要說‘機器人，給我一個解決方案’，就會得到好幾頁你甚至根本讀不懂的東西。”

團隊發(fā)現(xiàn)，AI 工具能讓他們在不犧牲工作范圍的情況下完成更多的任務，尤其是在黑客馬拉松這樣環(huán)境中。在一家企業(yè)的 AI 黑客周上，團隊完成了從實現(xiàn)暗模式到創(chuàng)建解釋數(shù)據(jù)庫查詢的工具或從其他供應商導入儀表盤的所有工作。各團隊在短時間內(nèi)完成工作的范圍和深度均令人嘆為觀止。

不過，小組成員也強調(diào)了關于 AI 生成的代碼在生產(chǎn)中失敗率增加的統(tǒng)計數(shù)據(jù)。最近的一項研究顯示，“據(jù)他們所知，發(fā)布的代碼數(shù)量增加了 300%，但錯誤數(shù)量增加了 400%”，這似乎是一點不祥的預兆。這與 2024 年 DevOps 狀態(tài)報告 不謀而合，該報告警告說，AI 的速度可能會導致變更列表變大，違反 DevOps 研究與評估（DORA）的小批量原則，從而增加不穩(wěn)定性：

“根據(jù)前幾年的研究結(jié)果，我們假設，AI 在受訪者的生產(chǎn)力和代碼生成速度方面帶來了根本性的模式轉(zhuǎn)變，這可能導致該領域忘記了 DORA 最基本的原則之一，即小批量的重要性。也就是說，由于 AI 允許受訪者在相同的時間內(nèi)生成更多的代碼，因此變更列表的規(guī)模有可能，甚至很可能在不斷擴大。DORA 一直表明，較大的變更會導致速度更慢，也更容易造成不穩(wěn)定。 綜合來看，我們的數(shù)據(jù)表明，改進開發(fā)流程并不能自動改善軟件交付 -- 至少在沒有恰當遵守成功交付軟件的基本原則（如小批量和強大的測試機制）的情況下是這樣的。

這一現(xiàn)實提出了新的挑戰(zhàn)：團隊習慣于通過找到編寫或深入理解一段代碼的專家來進行調(diào)試，但隨著 AI 所帶來的代碼生成，特定的專家可能不復存在。業(yè)界剛剛開始制定如何處理和維護 AI 生成代碼的方法。

3 技術應用中的“富人”與“窮人”

已經(jīng)采用新技術的組織與仍在猶豫不決的組織之間出現(xiàn)了明顯的鴻溝。這種技術采用上的差距表明，前沿團隊正在使用各種可用的 AI 技術，而較為保守的組織則限制使用微軟 Copilot 等有限的工具，兩者之間形成了鮮明對比。

雖然一些更成熟的組織正在突破界限，但許多其他組織才剛剛摸索出如何以敏捷的方式來開展工作。如果沒有堅實的既有實踐作為基礎，增加新技術和新方法的風險就會越來越大。

這種分歧可能會繼續(xù)擴大。隨著早期采用者不斷完善 AI 工具的使用方法并開發(fā)出防止質(zhì)量問題的防護欄，限制使用這些工具的組織可能會在能力和專業(yè)知識方面進一步落后。

4 在 AI 強化的世界中如何實現(xiàn)團隊協(xié)作

雖然 AI 可以提高個人的生產(chǎn)力，但專家小組擔憂 AI 對團隊協(xié)作所帶來的潛在影響。高效的軟件開發(fā)從根本上取決于有效的團隊合作。軟件開發(fā)是協(xié)同性的工作。高績效軟件開發(fā)團隊的關鍵在于協(xié)作，而 AI 可能會抑制協(xié)作。

工程師們越來越多地向 AI 尋求答案，而不是咨詢同事，這可能會破壞高績效協(xié)作文化的推進。

“人們在 AI 上問了更多的問題，然后看著 AI 產(chǎn)生的結(jié)果，會覺得‘好吧，我們現(xiàn)在已經(jīng)得到了答案，所以不需要再去找組織里的其他人了’”。

小組成員一致認為，在急于采用 AI 的過程中，團隊必須保留人類協(xié)作、反思和學習的空間。可觀測性、漸進式部署策略和生產(chǎn)驗證等賦能性功能的重要性仍然需要人類的監(jiān)督和協(xié)作。

5 初級工程師在 AI 增強型行業(yè)中的價值

盡管有人擔心 AI 可能會削弱初級工程師的作用，但專家小組還是極力主張初級工程師 依然非常重要。業(yè)界認為不再需要初級工程師的聲音受到了質(zhì)疑：

“我看到很多人在說‘哦，我再也不會雇用初級工程師了’之類的話，我認為這種說法太短視了。這是一個學徒制的行業(yè)。我們都是通過向其他人學習而學會的。”

今天的初級工程師遠沒有被 AI 取代，他們正在迅速適應，將 AI 作為學習的加速器。初級工程師在與資深同事接觸之前，會利用 AI 來完善自己的問題，從而使他們的互動更加高效、更有針對性。

建立重視學習和持續(xù)改進文化的團隊為初級工程師提供了一個天然的家園，他們可以對團隊的知識共享能力進行壓力測試。組織如果解雇初級工程師，就有可能失去團隊長期彈性的重要組成部分。

6 高績效團隊：心理安全感與反思

在討論 2025 年如何打造高績效團隊時，專家小組強調(diào)了幾項持久性的原則和新興的實踐。

心理安全感 仍然是基礎：

“如果你想建立高績效團隊，那就需要讓每個人都真正參與到團隊中來，每個人都貢獻出他們個人所能做的最好的東西...... 如果你想實現(xiàn)這一點，關鍵的一點是團隊中應該有心理安全感。

新冠大流行后的組織文化，再加上經(jīng)濟方面的壓力，對許多團隊的心理安全感提出了挑戰(zhàn)。許多組織正在削減團隊輔導和賦能相關的角色，讓經(jīng)理或新晉升的工程師在沒有充分培訓或準備的情況下填補這些空白。

從技術角度看，緊湊的反饋回路至關重要。縮短員工編寫代碼與代碼投入生產(chǎn)之間的時間。盡可能縮短反饋周期，并使其盡可能緊湊。

高績效團隊要求系統(tǒng)有一定的松弛度。任何以 100% 使用率運行的團隊都會停滯不前。

“如果你的團隊一直以 90% 的速度運轉(zhuǎn)，就會讓人 疲于奔命，而這需要很長時間才能恢復過來。”

7 度量指標和改進周期

工程度量指標 已經(jīng)成為一個越來越重要的團隊改進工具。當工程師因構(gòu)建失敗、需求不明確或其他障礙而損耗時間時，跟蹤精益浪費的工具就會用來收集各種數(shù)據(jù)。

高績效團隊并不懼怕衡量標準，但衡量標準應該是對話的開端，而不是對話的終結(jié)，更不是評估工具。不要用指標來 評判人，而是要用指標來幫助識別系統(tǒng)中的瓶頸，然后解決這些瓶頸。

對成本、周期時間、吞吐量、事故次數(shù)和恢復時間指標，以及產(chǎn)品指標要進行定期的審查，為持續(xù)改進提供必要的反饋。這些審查并不需要耗費大量時間，即使是簡短的定期檢查也能帶來價值。

僅抽出時間進行改進這一行為就有很重要的意義。關注績效、關注指標告訴了我們什么內(nèi)容、保持好奇心、嘗試真正了解團隊中發(fā)生的事情，這都是實現(xiàn)改進的關鍵。

8 可觀測性的成本危機

最引人注目的趨勢之一是 可觀測性成本的迅速攀升。Gartner 的統(tǒng)計數(shù)據(jù)顯示，一家客戶的可觀測性成本從 2009 年的每年 5 萬美元增長到 2024 年的 1400 萬美元，在 15 年間每年增長 40%。

一位小組成員警告說：“如果不解決這個問題，我們都會被淘汰。”

企業(yè)必須要確定，可觀測性是一項需要確保最小化的成本，還是一項能帶來紅利的投資。使用 10-20 種可觀測性工具的企業(yè)，其可觀測性成本與業(yè)務增長之間的乘數(shù)實際上是 10-20 倍。

然而，可觀測性成本的增長在一定程度上反映了系統(tǒng)復雜性的增加。系統(tǒng)的復雜性在呈爆炸式增長，上升速度越來越快。現(xiàn)代系統(tǒng)如此復雜，變化如此之快，以至于工程師無法依賴心智模型，認知負荷往往過高，他們需要強大的可觀測性工具來了解系統(tǒng)的行為。

一種可能的解決方案是采用 數(shù)據(jù)湖 的方法，一次性存儲所有可觀測性數(shù)據(jù)，并通過 AI 界面進行訪問。購買可觀測性決策應該被視為投資，而不僅僅是成本。

9 超越“敏捷”和“DevOps”：下一步是什么？

討論中幾乎沒有提到“敏捷”和“DevOps”這樣的術語，這表明這些方法已經(jīng)融入到行業(yè)實踐中，不再需要明確標注。

“InfoQ 的文化和方法領域曾經(jīng)全是關于敏捷類的東西，而現(xiàn)在我們正處于后敏捷時期。有趣的是，在整個播客中，它一次也沒有被提及過，這就是對相關領域的總結(jié)。”

另一項觀察結(jié)果在于，“我對 DevOps 有這種感覺。我覺得我們正處于 DevOps 運動的黃昏時期，這并不是因為 DevOps 已經(jīng)不再重要，而是因為它現(xiàn)在已經(jīng)成為我們呼吸的空氣。”

展望未來，不斷改善 開發(fā)人員的體驗 非常重要。平臺工程 被認為是一個很有前景的方向，它被描述為“將產(chǎn)品思維和設計思維引入到為工程體驗而構(gòu)建的工具中”。“工程師也是人，好的設計可能會提高開發(fā)人員的工作效率”，這一認識代表了行業(yè)思維的重要演變。

Gene Kim 的“三種方法（Three Ways）” 原則側(cè)重于流程、反饋和持續(xù)學習，為超越傳統(tǒng)的敏捷方法提供了一個有用的思維框架。這些原則與目前討論的許多趨勢相吻合，從加速開發(fā)流程到改進可觀測性反饋和創(chuàng)建學習環(huán)境。

10 結(jié)論：分布不均的未來

在小組討論結(jié)束時，與會者對 William Gibson 的著名觀點進行了反思，即“未來已來，只是分布不均”。這句話完美地概括了行業(yè)的現(xiàn)狀，一些團隊在利用最先進的工具和實踐，而另一些團隊仍在苦苦掙扎。

我們注意到了行業(yè)的一些積極發(fā)展，包括平臺工程的出現(xiàn)和 Staff Plus 工程職業(yè)道路的建立，這些道路提供了超越管理層的晉升機會。資深的個人貢獻者往往是那些制定計劃來招募和指導初級工程師的人，他們認識到 “沒有具有建設者信譽的人來談論建設者需要什么”。

對于希望在快速發(fā)展的環(huán)境中茁壯成長的團隊來說，主要經(jīng)驗包括：

• 擁抱 AI 工具，但要圍繞其使用制定防護措施和質(zhì)量規(guī)范

• 保持并加強團隊協(xié)作

• 為初級工程師投資并創(chuàng)造學習環(huán)境

• 在代碼創(chuàng)建和生產(chǎn)之間建立緊密的反饋回路

• 將可觀測性作為一項戰(zhàn)略投資，同時管理其不斷增長的成本

• 為實驗、反思和改進保持系統(tǒng)的寬松度

• 認識到 DevOps 和敏捷等實踐已成為基礎，而非差異化的因素

通過專注于這些領域，開發(fā)團隊可以應對 2025 年的復雜挑戰(zhàn)，同時建立更有彈性和更高效的組織，能夠交付日益復雜的軟件系統(tǒng)。

InfoQ Culture and Methods Trends Report - 2025(https://www.infoq.com/articles/culture-trends-2025/)

聲明：本文由 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。