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

在商務會議中，常見的做法是透過比較平均值來比較數字群組。但這麼做通常會隱藏這些群組中數字分佈的重要資訊。有許多資料視覺化可以清楚呈現這些資訊。這些視覺化包括條形圖、直方圖、密度圖、箱形圖和提琴圖。這些視覺化很容易使用免費軟體製作，適用於小至十幾個、大至數千個的群組。

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

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

技術債是一個非常有用的概念，但它引發了一個問題：你如何衡量它？遺憾的是，技術債務不像財務債務，因此很難判斷你陷入困境的程度（儘管我們最近似乎在衡量財務債務方面遇到了一些麻煩）。

你無法將十磅的糞便放入五磅的袋子中

-- 任何嘗試過的人

當 Kent 和我撰寫《規劃極限編程》時，我們加入了這句異想天開的引言，以幫助了解規劃的本質。

在職業生涯中，我聽聞許多關於函式長度應該多長的爭論。這是一個更重要問題的代理問題 - 我們什麼時候應該將程式碼封裝在自己的函式中？其中一些準則基於長度，例如函式不應大於螢幕上顯示的長度。有些則基於重複使用 - 任何使用超過一次的程式碼都應放入自己的函式中，但僅使用一次的程式碼應保留在內聯中。然而，對我來說最有意義的論點是意圖與實作的分離。如果你必須花費力氣檢視程式碼片段以找出它在做什麼，那麼你應該將它萃取到一個函式中，並將函式命名為那個「什麼」。這樣一來，當你再次閱讀它時，函式的目的就會直接躍然紙上，而且大部分時間你不需要關心函式如何實現其目的 - 也就是函式的本體。

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

我第一次接觸敏捷軟體開發是在極限編程的黎明時期與 Kent Beck 合作。那個專案中讓我印象深刻的一件事就是我們規劃的方式。這包括一種估算方法，既輕量化又比我之前看過的更有效率。現在已經過了十多年，現在有經驗的敏捷主義者之間對於估算是否值得做，甚至是否積極有害，展開了一場論戰。我認為要回答這個問題，我們必須了解估算將用於何種目的。

我常遇到一個抱怨，說敏捷方法沒有嚴謹的定義。抱怨者可能會說這表示你無法判斷一個特定的團隊是否使用敏捷方法。他們也可能會說這使得難以教導人們如何執行敏捷方法，課程是什麼？

在某種程度上，我確實感受到這個抱怨的痛苦，但我接受沒有解藥。這種不嚴謹是敏捷方法定義性質的一部分，也是其核心哲學的一部分。

最近我聽過幾個問題，關於為使用極限編程規劃方法的多個團隊提出一個標準故事點機制。希望是讓多個團隊都使用等效的故事點，因此一個團隊的三個故事點工作量與另一個團隊相同。

我認為嘗試提出這個想法充其量價值有限，最糟的情況是危險的。

時不時我會聽到人們詢問他們應該追求什麼價值的測試涵蓋率（也稱為程式碼涵蓋率），或自豪地陳述他們的涵蓋率。此類陳述錯失了重點。測試涵蓋率是尋找程式碼庫中未測試部分的有用工具。測試涵蓋率作為一個數值陳述，對於評估測試的優劣幾乎沒有用處。

CHAOS 報告指出只有 34% 的專案成功。

Standish Group 的 CHAOS 報告 多年來一直在討論 IT 專案浪費數十億美元。34% 的成功率實際上比 2001 年的 28% 有所改善。但我們真正指的「失敗」是什麼？