軟體開發專案中常見的爭論，在於花時間改善軟體品質，還是專注於釋出更有價值的功能。通常交付功能的壓力主導討論，導致許多開發人員抱怨沒有時間處理架構和程式碼品質。這場爭論基於一個假設，即提高品質也會增加成本，這是我們常見的經驗。但反直覺的現實是，內部軟體品質消除了減緩開發新功能的累贅，從而降低了增強軟體的成本。

遠距與共處工作並非簡單的二分法，而是有幾種團隊分配模式，每種模式都有不同的取捨和適合的有效技術。雖然無法確定確鑿的證據，但我認為大多數團隊以共處的方式工作會更有生產力。但你可以透過使用分散式工作模式來建立一個更有生產力的團隊，因為它讓你能夠接觸到更廣泛的人才庫。

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

管理階層熱愛他們的指標。思考過程大致如下：「我們需要一個數字來衡量我們的表現。數字能讓人專注，並幫助我們衡量成功。」儘管用意良善，但數字管理卻會直覺地導致有問題的行為，並最終損害更廣泛的專案和組織目標。指標本身並非壞事，只是經常被不當使用。本文說明了管理階層傳統使用指標所造成的許多問題，並提供了解決這些功能障礙的替代方案。

衡量開發人員生產力是一項艱難的挑戰。專注於開發週期時間和產出的傳統指標有限，而且對於其他可尋求的指標也沒有顯而易見的答案。定性指標提供了一種強大的方式，可使用從開發人員自身衍生的資料來衡量和了解開發人員生產力。組織應優先使用來自人類的資料來衡量開發人員生產力，而不是來自系統的資料。

如何提高軟體開發人員的生產力？

我們看到許多關於軟體流程、設計實務等的情緒化討論。其中許多論點無法解決，因為軟體產業缺乏衡量軟體開發效能某些基本要素的能力。特別是，我們沒有合理衡量生產力的方法。

在軟體世界中，一個普遍接受的信念是，有天賦的程式設計師較有生產力。由於我們無法衡量生產力，這是一個無法證明的信念，但這似乎是合理的。畢竟，幾乎每個人類的努力都顯示出有些人比其他人更好，通常明顯地好。程式設計師自己也普遍觀察到這一點，儘管似乎總是那些自認為屬於較有天賦類別的人才會提出這樣的評論。

設計良好的軟體是否值得付出努力？

許多人相信，你無法在敏捷專案中進行固定價格合約。由於敏捷流程的重點在於你無法預測未來，這並非不合理的假設。然而，這並不表示你無法提出一個敏捷的固定價格合約，這實際上表示你無法提出一個固定範圍的合約。

我最喜歡的格言之一是：如果感到疼痛，就更常做。它的表面看起來很荒謬，但深入探討後會發現一些有價值的意義

想像一個為購物網站編寫軟體的團隊。如果我們查看團隊的產出，我們可能會考慮他們在上一季製作了多少新功能，或跨職能指標，例如減少頁面載入時間。然而，成果指標會考慮增加銷售收入或減少產品支援電話的數量。專注於成果而非產出，有利於建構更多功能來提升軟體使用者和客戶的效能。

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

DevOps 報告現況是一份年度報告，使用調查資料的統計分析來確定軟體交付組織的有效實務。其主要作者為 Nicole Forsgren、Jez Humble 和 Gene Kim。

我常常遇到感到沮喪的開發人員，因為「管理階層想要更多功能，他們不在乎品質」。當我聽到這句話時，我總是感到難過，因為當我聽到這句話時，我知道開發人員、管理階層和他們的客戶已經輸了。他們的失敗是由於以可交易品質假說來構思情況。