界定上下文是領域驅動設計中的核心模式。它是 DDD 戰略設計區塊的重點，而該區塊完全在於處理大型模型和團隊。DDD 透過將大型模型分割成不同的界定上下文，並明確其相互關係，來處理大型模型。

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

當有人在檢視頂尖企業軟體開發人員的組成時，對話通常會轉向框架和語言的知識，或可能是理解複雜演算法和資料結構的能力。對我來說，程式設計人員，或甚至開發團隊最重要的特質之一，是我稱之為「客戶親和力」的東西。這是開發人員對軟體所要解決的業務問題，以及生活在該業務世界中的人們的興趣和親近感。

一種由產品負責人或分析師撰寫故事並傳遞給開發人員建置的方法。我認為這對敏捷思維有深刻的誤解，因此非常偏好 對話式故事。

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

許多公司喜歡撰寫固定範圍和價格的合約，因為他們認為這能降低風險。這種幻象表示，他們的財務義務固定在合約價格上。如果他們沒有得到滿意的軟體，就不會造成他們的損失。

歷史或多或少都是無稽之談

-- 亨利·福特

我最近收到一封來自 UML Distilled 讀者的不滿意電子郵件。當一個憤怒的讀者後悔購買，更別說閱讀我偶爾的智慧之語時，這對我來說永遠不是美好的一天開始。但這個讀者的抱怨特別有趣。他具體的抱怨是我的「不必要的歷史」。

需求是您在開始建置產品之前應該發現的事物。在建置過程中發現需求，或更糟的是，當您的客戶開始使用您的產品時，代價如此昂貴且效率如此低下，我們將假設沒有人會這麼做，也不會再提到它。

-- 蘇珊娜和詹姆斯·羅伯遜

敏捷方法違反了這個基本假設，打算在建置和交付期間發現「需求」。但即使這種傲慢地忽視上述明智建議，也比不上許多領先網站現在所做的。這些網站透過觀察使用者在其網站上的行為來探討需求，並使用這些資訊來產生新功能的想法，如下所示

現場客戶是極端程式設計的實務之一，是 白皮書 中提到的十二項之一。它表示，客戶應與開發人員坐在其開放的工作區域中，以便隨時回答問題並與開發團隊互動。他們確實是開發團隊的一份子，並且承認團隊的成功與他們和開發人員一樣重要。他們不必放棄定期工作來執行此任務，但他們必須親自到場。

敏捷開發的一項關鍵特性是找出如何讓系統使用少數功能上線。我們為其提供的商業價值建構軟體，我們上線越快，我們就能越快取得至少部分的商業價值。

敏捷開發的基本原則之一是需求變更不僅是預期的，而且是受到歡迎的。當外部公司（例如 Thoughtworks）為客戶執行工作時，這會帶來特殊的挑戰。許多客戶想要一個固定價格安排，這實際上是固定範圍，因為他們看到了固定範圍的幻覺。但是固定範圍合約與敏捷開發完全不符，那麼像我們這樣的公司該怎麼辦？

2002 年我在 XP/Agile Universe 參加研討會時，「範例規格」這個詞句讓我想到用來描述XP中測試角色的方法之一。

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

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

行動應用程式在過去幾年一直是軟體開發的熱門項目。如同許多軟體交付公司，Thoughtworks 收到許多客戶要求我們為他們建置行動應用程式。然而，大部分時候，當一家公司要求我們（或任何人）建置行動應用程式時，他們一開始就走錯方向。我想爭論的是，在大部分情況下，即使你希望使用者與行動裝置互動，你都絕不應該考慮建置行動應用程式。相反地，你需要考慮建置一個單一應用程式，可以在多種裝置上呈現：行動裝置、桌上型電腦、平板電腦，或你的使用者可能會使用的任何裝置。

使用案例是組織和引發需求的一種技術。它們最初是由 Ivar Jacobson 在 80 年代末期和 90 年代初期推廣的。

使用案例 和 XP 的 使用者故事 有什麼不同？

使用者故事是軟體系統所需行為的區塊。它們廣泛用於敏捷軟體方法，將大量的功能劃分為較小的部分，以利於規劃。你也可以聽到相同的概念稱為功能，但「故事」或「使用者故事」這個術語在現今的敏捷圈中已變得普遍。