功能熱忱

敏捷方法的常見做法（也許是主要做法）是為正在建構的軟體開發功能清單（通常稱為故事）。這些功能會透過索引卡、工作佇列、燃盡圖表、待辦事項清單或任何您選擇的工具來追蹤。

整體而言，我喜歡這種方法。透過將您需要執行的所有事項分解成您可以在一週或幾週內完成的小任務，您可以視覺化進度並了解您可以完成多少工作。我常說，反覆開發的主要好處是透過強制分塊完成軟體，而非瀑布式習慣，將長而難於管理的活動（測試、整合）留到專案後期，來降低風險。

問題發生在這個清單突然長出犄角和尖牙，變成固定價格固定範圍的大型前期專案計畫時。 Craig Larman 曾經開玩笑說，瀑布式流程有強大的抗體，會透過將反覆流程扭曲成某種瀑布式形式來排斥反覆流程。RUP 一直是這些抗體的常見受害者，看到其階段轉變成分析-設計-建構-測試輸送帶的某個變體。

擊敗瀑布式的關鍵是了解，正如 Dan 所說，敏捷主義者重視成果而非功能。功能清單是一個有價值的工具，但它是一種手段，而非目的。真正重要的是整體成果，我認為這是對客戶的價值。

這種思考的一個重要部分是您預期功能清單會隨著專案進行而改變。這會發生在您發現您可以執行的新的事物，以及重新調整舊事物的優先順序時。這是適應性規劃的精髓，它一直是敏捷思考的一個關鍵指標。這會導致人們對計畫的思考方式產生重大轉變。在計畫驅動的專案中，成功與失敗通常用「事情是否按照計畫進行？」來表達。在敏捷專案中，這是個沒有意義的問題，因為計畫常常在變。計畫是一個工具，主要是您用來衡量變更影響的工具：「新增這個功能將如何影響我們的作為」。計畫是一個工具，用來找出什麼應該放入FivePoundBag中。如果您的計畫沒有持續變更，您不太可能在進行適應性規劃，因此不是敏捷的。

功能清單有另一個問題 - 你很容易忽略讓功能有價值的脈絡。這是 Alistair Cockburn 倡導使用案例的原因，因為它們專注於某人如何使用系統的敘述。Marc NcNeil 也在 客戶旅程 中討論過這一點。使用案例在規劃中的缺點是，它們沒有提供明確的單位讓你勾選，因此你無法評估進度並將選擇的後果投射到未來。這讓它們作為規劃工具的用處降低，但這並不會否定它們作為想像良好結果的工具的價值。