對話式故事

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

這種方法的理由是，它可以根據能力區分責任。產品負責人了解業務、軟體的用途，因此了解需要完成什麼。開發人員了解技術並知道如何做事，因此他們可以找出如何實現產品負責人的需求。

產品負責人提出 DecreedStories 的概念，嚴重誤解了敏捷開發應有的運作方式。當我們在 Snowbird 討論名稱時，我記得 Kent 提議「對話式」。這強調了我們思考的核心，是客戶和開發人員之間關於開發專案應如何進行的持續對話。

就提出故事而言，這表示它們總是需要透過對話來精進，而且開發人員應在協助定義中扮演積極的角色。

• 找出故事之間的不一致和差距
• 利用技術知識提出新的故事，這些故事似乎符合產品負責人的願景
• 看到其他故事，在給定的技術環境下會更便宜
• 拆分故事，讓它們更容易規劃或實作

這是 Bill Wake 的 INVEST 故事測試中的可協商原則。敏捷團隊的任何成員都可以建立故事並建議修改。團隊中只有少數成員傾向於撰寫大部分故事。這取決於團隊的自我組織，他們希望如何實現。但每個人都應參與提出和精進故事。（除了開發人員估計故事的責任外，還有這項參與。）

產品負責人確實負有特殊責任。最終，產品負責人對故事有最終決定權，特別是其優先順序。這反映出產品負責人應該是判斷業務價值這種難以捉摸的屬性的最佳人選。但是，擁有最終決策者絕不應該阻止其他人參與，也不應該誤導人們進入故事的既定模式。

於 2015 年 2 月 19 日重新發布