通过故事而不是任务进行交流

通过故事而不是任务进行交流

上一次我谈论代码段之间的接口 。 今天，我想讨论参与开发软件的人群之间的接口。 有两个基本组：开发软件的人和协调开发的人。 用敏捷术语来说，这些小组一方面是开发团队，另一方面是产品所有者和其他利益相关者。

说相同的语言

这两个小组需要沟通，因此当每个人都讲相同的语言时，他们会做到最好。

首先要说相同的“自然”语言，例如英语。 对于将要给定的大多数团队，但是分布在不同国家/地区中多个位置的团队需要谨慎一点。

确定语言后，团队应查看他们将使用的专业术语。

由于开发团队需要了解他们必须构建的内容，因此他们需要知道业务术语。

但是，产品负责人和利益相关者不一定需要了解技术术语。

因此， 无所不在的语言是企业的语言是有道理的。

谈论工作：故事和任务

但是，这两个小组需要讨论的不仅仅是要解决的业务问题。 对于任何不重要的工作，他们还需要讨论如何组织这项工作。

在大多数敏捷方法中，工作被组织为Sprint或迭代。 这些有时间限制的开发时间是产品所有者和开发团队之间的明确接口。

产品负责人是指导开发团队的人：她决定将在给定的迭代中构建哪些用户故事 。

开发团队在迭代期间实施请求的故事。 他们通过将故事分解为任务，让人们注册任务并实施它们来实现。

任务描述开发时间的组织方式，而故事描述功能。 因此，“任务”可能引用诸如关系数据库之类的技术术语，而“故事”应该只谈论诸如数据持久性之类的功能。

故事就是界面

由于我们重视工作软件 ，因此我们大部分时间都在谈论故事。 仅存在使“故事”的实现变得容易的任务。 它们在开发团队内部，而不是开发团队与产品所有者共享的界面的一部分。

实际上，许多开发团队确实向其产品所有者和其他利益相关者公开任务。

有时他们这样做是为了解释为什么一个故事的估算值比产品负责人的预期要高。

或者，他们让产品负责人参加讨论任务的站立会议。

只要双方都了解Task由开发团队拥有，就像Stories由产品所有者拥有一样，就可以了。

开发团队可以提出Stories ，但产品负责人决定将哪些内容添加到待办事项列表中，以及哪些内容在迭代中安排。

同样，产品负责人可能会建议，质疑或询问任务，但是开发团队会决定哪些任务组成了一个故事，以什么顺序排列以及由谁实施。

始终尊重界面

产品负责人和开发团队之间的明确定义的界面使双方都能做好工作。

重要的是要了解这对软件开发过程的组织方式有影响。

例如，我们报告的指标应根据故事而非任务进行定义。

在开发团队之外，人们不必关心开发时间的分配方式，而只关心结果是什么。

如果我们坚持使用界面，则双方将脱钩，因此可以自由创新和优化自己的流程，而不会损害整体。

这是任何定义明确的界面的主要优点，也是成功的分而治之策略的基础。

你怎么看？

您在两组之间的沟通中看到了什么问题？

您是在有意识地将交流仅限于故事，还是在让任务拖延时间？

参考： 安全软件开发博客上的JCG合作伙伴 Remon Sinnema讲故事而不是任务 。

翻译自: https://www.javacodegeeks.com/2013/09/communicate-through-stories-rather-than-tasks.html