今日許多從事軟體開發工作的人員都聽過配對程式設計的實務，但它在業界的採用率仍然不齊。其接受度不一的其中一個原因是它的優點並不明顯，它在中長期更能發揮效益。而且它也不像「兩個人共用一台電腦」這麼簡單，因此當感覺不舒服時，許多人會很快放棄。然而，根據我們的經驗，配對程式設計對於協作團隊合作和高品質軟體至關重要。

遠距與共處工作並非簡單的二分法，而是有幾種團隊分布模式，每種模式都有不同的權衡和適合的有效技巧。雖然無法確定明確的證據，但我認為大多數團隊以共處的方式工作會更有效率。但你可以使用分散式工作模式來建立更有效率的團隊，因為它能讓你接觸到更多的人才庫。

現代原始碼控制系統提供了強大的工具，讓你在原始碼中輕鬆建立分支。但最終這些分支必須合併回主幹，許多團隊花費過多時間應付錯綜複雜的分支叢林。有幾種模式可以讓團隊有效使用分支，重點在於整合多位開發人員的工作，並組織通往生產版本的途徑。總體主題是分支應該頻繁整合，並專注於可以輕鬆部署到生產環境的健康主幹。

發布/展示/詢問是一種分支策略，它結合了拉取請求的功能，同時又能持續發布變更。變更分為發布（合併到主線中，無需審查）、展示（開啟拉取請求進行審查，但立即合併到主線中）或詢問（在合併前開啟拉取請求進行討論）。

平台團隊非常依賴其他團隊來確保其平台的採用——將程式碼變更納入其他團隊的程式碼庫對其成功至關重要。有很多跨團隊協作模式，選擇正確的模式取決於平台採用的階段，以及團隊和程式碼庫接受外部影響的能力。

如果你使用回顧，或任何一種人們應當討論並從討論中學習的會議，你會時不時地遇到效率較低的會議。這不足為奇，而且大多數人都會遇到。本文描述了三種此類不幸情況的解決方案：跳過產生見解、迷失在無法改變的事物中以及被大嗓門的人主導。

良好的技術設計決策在很大程度上取決於背景。定期為共同目標而共同工作的團隊能夠定期溝通並快速協商變更。這些團隊表現出強作用力的一致性，並且可以做出利用這種強作用力的技術和設計決策。當我們在一個更大的組織中縮小範圍時，在獨立工作且協作頻率較低的團隊和部門之間存在越來越弱的作用力。認識到這些強作用力和弱作用力的差異，使我們能夠為每個層級做出更好的決策並提供更好的指導，從而讓團隊更有能力，行動更迅速。

科技不斷變得更聰明、更強大。我經常觀察到，當這些技術被引入時，組織的生產力並未提升，反而降低了。這是因為技術增加了開發人員的複雜性和認知負擔，降低了他們的效率。在本文中，作為一系列文章的第一篇，我介紹了一個最大化開發人員效率的框架。透過研究，我找出關鍵的開發人員回饋迴路，包括開發人員每天執行 200 次的微型回饋迴路。這些迴路應經過最佳化，以便對開發人員來說快速、簡單且有影響力。我將探討一些組織如何使用這些回饋迴路來提升整體效率和生產力。

構思是在專案開始時執行的活動，目的是召集相關人員，並為持續進行的工作設定共同的方向和工作方式。精實構思是構思的一種重點形式，可以在一週內完成。在此期間，我們了解產品的主要功能和客戶，並建立一個畫布來制定最小可行產品的特徵。

加速是指動作更快、速度更快。有效地處理資料是任何想要在現代世界中蓬勃發展的組織的關鍵，而資料網格正在向組織展示如何大規模地從資料中實現價值。資料網格加速工作坊透過了解團隊和組織的現況，並探討下一步將如何進行，來協助團隊和組織加速其資料網格轉型。

傳統的文科學位提供與產品經理高度相關的技能

取得良好的音訊、使用畫廊檢視、未發言時請靜音，並歡迎貓咪。

我們和我們的同事經常被要求為客戶執行架構評估。當我們這樣做時，參與這些系統的架構師會討論這些系統的效能、它們對故障的復原力，以及它們如何設計成能輕鬆支援新功能。然而，很少會提到的「大象」是不同的系統如何為商業價值做出貢獻，以及此價值如何與這些其他架構屬性互動。

結對程式設計的優點已被廣泛接受，但關於配對輪換的建議仍然有爭議。隊友應該何時以及多久輪換配對？而且…如果我們每天輪換配對會怎樣？我們與三個團隊合作，進行每天配對輪換的練習。我們開發了一個輕量級的方法，幫助團隊反思配對的優點和挑戰，以及如何解決這些問題。最初的疑慮已被克服，團隊也發現了頻繁輪換配對的優點。我們了解到，頻繁配對交換極大地增強了配對的優點。在此，我們分享我們開發的方法、我們的觀察，以及參與團隊成員分享的一些常見疑慮和見解。

不久前，我與一位即將踏上學術生涯的博士後聊天。他詢問我關於研究主題，希望我提供意見，因為他覺得我可以告訴他什麼研究具有實際用途。我沒有提供太多幫助，但我確實提到這樣做的最佳方式是在業界花一些時間，以了解軟體開發在實際環境中的運作方式，以及哪些問題可以透過研究工作來解決。他對這個想法的回答非常令人不安。

對齊地圖是組織資訊散熱器，有助於視覺化正在進行的工作與業務成果之間的對齊。這項工作可能是例行的功能新增，或技術工作，例如重新架構、償還技術債務或改善建置和部署管道。團隊成員使用對齊地圖來了解他們日常工作旨在改善哪些業務成果。業務和 IT 贊助者使用它們來了解正在進行的工作如何與他們關心的業務成果相關。

當人們使用「軟體架構師」這個術語時，他們使用建築施工的比喻來幫助人們了解架構師的角色。具有諷刺意味的是，在這樣做的過程中，他們誤解了建築架構師的實際角色。

隨著對資料分析和視覺化的興趣日益濃厚，我們看到更多精力投入到有趣的視覺化中，讓人們可以從組織中流動的資料中汲取見解。這些儀表板大多數都是針對個人使用，但使用它們來實現更共用的目的的趨勢正在增長。

以下是關於敏捷方法的一個常見誤解。它集中在使用者故事的建立方式以及在開發活動中的流動方式。這個誤解是產品負責人（或業務分析師）建立使用者故事，然後將它們放在開發人員面前實作。這個概念是從產品負責人到開發的流程，產品負責人負責確定需要完成的什麼，而開發人員負責如何完成。

敏捷軟體開發打破了需求分析、測試和開發之間的部分隔閡。部署、運作和維護是其他與軟體開發流程的其他部分有類似隔離的活動。DevOps 運動旨在消除這些隔閡，並鼓勵開發和運作之間的協作。

在會議或工作坊期間，不時需要對多項事物進行投票，以便對子集進行排名或選擇。點票是一種快速且不錯的方法。

開放空間是一種方法，可協助您召集自組會議。我最初是在 1997 年由 諾姆·科斯 介紹給我的，從那以後，我已經看過它被使用，並且自己也使用過很多次。它似乎很適合小規模、十幾或二十人的小組，以及一兩百人的大規模小組。我已經看過它使用於一到三天的時段。我將描述我所見過的變化：克雷斯特巴特是一個約有 20 人參加的小型年度工作坊，2002 年敏捷宇宙 在一個軌道上舉辦的會議中約有 100 人參加開放空間（他們從那以後持續這麼做，但我無法參加），foocamp 以兩百多人進行了這項活動。這項技術是由哈里森·歐文開發的，並在他的 書 中有詳細的描述。

配對程式設計是一種軟體開發實務，讓開發人員以兩人為一組進行工作。所有重要的程式碼都是由兩位程式設計師編寫的，通常並肩坐在一台顯示器前，常常共用一個鍵盤。當他們新增程式碼時，會一起討論每一步驟。

關於 配對程式設計 的一些常見迷思。

通訊技術的進步導致越來越多團隊採用 遠距優先 的方式工作，而這股趨勢在新冠肺炎疫情的強制隔離下更是蓬勃發展。但遠距工作的團隊仍可從面對面的聚會中獲益，且應每隔幾個月舉辦一次。

所有敏捷方法都強調系統開發人員與最終受益者（客戶）之間直接互動的重要性。敏捷宣言指出：「業務人員和開發人員必須在整個專案期間每天合作」，這句話強調互動的頻繁性。極限程式設計透過其 駐點客戶 做法強調這一點。

當人們想到程式碼檢閱時，通常會想到開發團隊工作流程中的一個明確步驟。現今，在 Pull Request 上執行的整合前檢閱是最常見的程式碼檢閱機制，以至於許多人愚蠢地認為不使用 Pull Request 就會消除所有進行程式碼檢閱的機會。如此狹隘的程式碼檢閱觀點不僅忽視了許多明確的檢閱機制，更重要的是忽視了可能最強大的程式碼檢閱技術，也就是由整個團隊進行的持續精進。

專案時間軸是於 專案回顧 期間製作的寶貴資料。時間軸應顯示專案期間發生的各種事件，以及它們如何影響專案。

在敏捷專案中常見的情況是，開發團隊坐在單一的開放式團隊室中。這在極限程式設計中很早就被提倡，並在第二版中被稱為主要實務之一。敏捷主義者偏好開放式團隊室，因為它促進團隊成員之間大量的非正式且深入的溝通。

如果您使用 XP 風格的規劃，您需要從開發人員那裡取得快速共識估計。拋出估計讓您快速得知開發人員對估計有相同的類似看法（因此您可以記錄下來並繼續進行）或是有分歧（當您需要更詳細地討論 使用者故事 時）。