对话式故事

关于敏捷方法，有一个常见的误解。它集中在用户故事的创建方式以及它们在开发活动中的流动方式。这种误解是，产品负责人（或业务分析师）创建用户故事，然后将它们交给开发人员去实现。这种概念认为，这是一个从产品负责人到开发人员的流程，产品负责人负责确定做什么，而开发人员负责如何做。

这种方法的理由是，它根据能力划分了责任。产品负责人了解业务、软件的用途，因此也知道需要做什么。开发人员了解技术，知道如何做事，因此他们可以弄清楚如何实现产品负责人的要求。

这种产品负责人提出规定故事的概念是对敏捷开发工作方式的严重误解。当我们在雪鸟会议上集思广益地为其命名时，我记得Kent建议使用“对话式”。这强调了这样一个事实，即我们思考的核心是客户和开发人员之间关于开发项目应该如何进行的持续对话。

就提出故事而言，这意味着它们始终是需要通过对话来完善的东西，而且开发人员应该在帮助定义方面发挥积极作用。

• 发现故事之间的不一致和差距
• 利用技术知识想出似乎符合产品负责人愿景的新故事
• 看到考虑到技术环境可以更低成本构建的替代故事
• 拆分故事，使其更容易计划或实施

这是Bill Wake对故事进行INVEST测试中的“可协商”原则。敏捷团队的任何成员都可以创建故事并建议修改。可能只有团队中的少数成员倾向于编写大部分故事。这取决于团队的自我组织，以及他们希望如何实现。但每个人都应该参与到提出和完善故事的过程中。（这种参与是开发人员评估故事的责任之外的。）

产品负责人确实负有特殊责任。最终，产品负责人是故事的最终决策者，尤其是它们的优先级。这反映了这样一个事实，即产品负责人应该是判断商业价值这一难以捉摸的属性的最佳人选。但拥有最终决策者绝不应该阻止其他人参与，也不应该让人们误入歧途，陷入规定的故事模式。

转载于2015年2月19日